While reading the Foreman handbook, I came across the following section on committer status:
“If you are inactive in the community for one year, we will remove you from the committers list and revoke your permission, but we will make a mention of you in theforeman.org list of previous committers.”
I was curious about how this policy is applied in practice today.
Specifically:
Is this policy still actively followed?
Is there a periodic review (for example, annually) to identify inactive committers?
Has the community applied this policy in recent years, or is it mainly intended as guidance?
Before removing someone, is there typically a discussion or outreach to confirm whether they still wish to remain an active committer?
I’m asking mainly to better understand the current practice, since the handbook describes the policy but doesn’t mention how frequently it is exercised in practice.
I did “kick” people out in the past (usually with a mail “hey, I removed your permissions, tell me if you want them back” if I still had a working contact for them), but not very regularly. Certainly not “after a year”.
I still think removing people after some prolonged inactivity period is a good thing, as long as we allow quick re-entry if they show interest again.
I agree that removing long-inactive permissions while keeping re-entry easy makes sense.
Perhaps we could update the handbook to reflect the actual practice — something lightweight around a prolonged inactivity period, reaching out where possible, removing permissions, and making re-entry straightforward. Or could be some automation in place to start giving such a reminder in advance without a manual effort …
Would be good to hear what others think, and what would be considered a reasonable inactivity period.
That’s a good read. My thoughts come somewhat from the same background specially when we think about AI and security risks..
So defining the clear meaning of what is meant by “Inactive“ and following active once in a 6 months looks more reasonable, with placing automation to give a timely reminder to avoid surprises for a community member.
I think the full write up would be a good start. We should aproach it from the very first moment as a process for all projects in the ecosystem. It would be great to unify and capture “get permissions” and “lose permissions” in one go. We don’t have to spend too much time on where to put down such definition, for now it can live in md file on github, our website or even here. If you make that RFC post a wiki, you can update it based on suggestions in the thread.
Speaking of rules for losing or pausing merge permissions, I’d be more extreme and would say that 3 months is enough. We expect active maintainers. 1 month inactivity is understandable (PTOs, unexpected unavailability). If there’s no single comment from a person for 3 months, the permissions should be removed, indeed with ability to re-add without a hassle if the person asks. If we’re not sure, we could calculate the average/median for the current group. I guess I’ll be the first candidate to be removed.
The linked article recommneded 6-12 months, but I feel like in the era of supply chain attacks, we may want to be more conservative. The most important will be the definition of what activity means.
