How to renew Core Committer terms

So far people seem to like this idea of renewable terms, including myself. However, we haven't yet figured out how to actually renew these terms and that is an important part of the discussion.

I've been thinking about finding a democratic approach to handle term renewals, and specifically for the Core Committers. A democratic approach has pros and cons, hence it's an important part of the overall proposal to consider.

Because the mechanics of such a renewal process can be complex, I created a child-issue for it at #3374499: Renewing Core Committer terms → .

Step 1: Up to three months before a Core Committer's term ends, another Core Committer must nominate them for renewal. A second Core Committer must second the nomination.

It has recently taken us several months to invite people to be provisional core committers after there was consensus on doing so, and also several months to promote someone from provisional to core committer. This is not because of any concerns with those people, it's because balls kept getting dropped during the process multiple times.

The default situation here if no-one remembers to nominate and second people in time for the deadline, is that all of the core committers fail to renew over a 24 months period, and there's no core committers left to nominate any new ones. I don't think that's a good default, especially since it's also taken us months to resurrect the Technical Working Group from only having one member and no way to add new ones.

So I think the default needs to be flipped to renewal, and then some process of confirming that and/or asking people to step down - I don't know what that looks like but hard deadlines reliant on multiple people doing different steps do not have a good track record with the core committer team.

quietone, xjm, catch and longwave chatted about this and this is our current thoughts.

First we want to thank Dries for creating this issue to discuss how to manage renewal of committer positions. We do need to keep this moving.

@catch makes a very good point that adding a time-sensitive process is not practical for a team that does not have any paid admin support. Tasks such as unblocking issues, core commits and making a release will nearly always take precedence. Therefore, we need to keep the process as simple as possible.

Also, an objective of the original proposal is for all maintainer roles, including core committers, to have a graceful and low-overhead opportunity to step down without the difficulty of coming forward to resign. This should help reduce burnout or a sense of pressure to continue beyond what is best for the individual maintainer. So, maybe we can adjust the proposal to address that goal.

What currently happens when adding a committer:

• A core committer approaches someone to discuss becoming a core committer.
• If the person agrees, an issue is opened to add them to MAINTAINERS.txt, however they are already in the role by that point
• Discussion ensues and it is either approved or not

We suggest a simple modification to this existing process so it can be used for renewal.

• The committer team facilitator approaches committers whose terms are ending (with term end dates distributed either quarterly or semi-annually). They have a private conversation about continuing as a core committer.
• If the person wants to step down, an issue is opened to remove them from MAINTAINERS.txt.
• At the next core committer meeting, the result of the conversation is documented. That is, the person has decided to step down or stay on. And the renewal date is updated.

Now the trick is to complete the renewal process in a timely fashion. We use the existing core committer meeting schedule to keep track. And just like the first process, the committer is still active until the issue is Fixed.

Thanks for that feedback. The two proposals are quite different in complexity, but also in scope:

• The initial proposal covers (1) renewals and forced departures, focusing on (2) choices made by both the individual and the team.
• The alternative in comment #5 solves for (1) renewals only and (2) only considers the individual's decision.

When we think about self-governance, it's important to have the option to renew or extend terms, but it can also be important to be able to move out people, if needed.

Imagine there is a Core Committer who creates issues, doesn't collaborate effectively, or doesn't align with the project's current needs. Now, when it's time to renew their term, many team members might not want them to renew. With the proposal in comment #5, that person can decide to stay even if others are worried about it.

I agree that my proposal does add some complexity and demands more time and effort. However, this added complexity also helps mature our governance model, and moves us closer to self-governance.

Perhaps it would have been better to start by asking: what do we want to solve for? Is addressing forced departures and improving team dynamics something we want to build into our process at this point in time? I'd be ok with reducing the scope, if that is what the team prefers.

Imagine there is a Core Committer who creates issues, doesn't collaborate effectively, or doesn't align with the project's current needs. Now, when it's time to renew their term, many team members might not want them to renew.

That could potentially be a problem 23 months before their current term ends, so I think it should be its own, separate process independent of term renewals.

It's also not clear to me what the overlap is between a removals process and the CWG.

You make a good point about the difference between the Community Working Group (CWG) and the Core Committer proposal.

I see them operating at two different levels. The CWG's main focus is to uphold the Drupal Code of Conduct (CoC), while the Core Committer proposal in this issue aims to give the Core Committer Team more control in creating an effective team.

The proposal in this issue allows the Core Committer Team to have more say in how they manage themselves. They could remove members for various reasons, not just for violating the CoC. These reasons include things like not sharing the team's vision, causing negative dynamics within the team, personal conflicts between team members, and more. These example reasons are outside of the CWG's scope as they are not violations of the CoC.

I also believe that the CWG holds a higher authority than the Core Committer team for issues that are in their scope. So, if the CWG removes someone from the Drupal community for Code of Conduct violations, the Core Committer team would follow their decision and also remove that person from the Core Committer or Core Contributor Team.

While it might be easier to introduce a separate evaluation process for all this, many non-profit organizations usually include this evaluation as part of the term renewal process. It's common to bundle them.

However, as I wrote before, I'm open-minded about this. I mainly wanted to respond to your comment and explain how I see the relationship between the CWG and the Core Committer Team. I'd would love to hear what others have to say on the matter as well.

I agree that if an active core committer were to breach trust so badly as to indicate their removal (rather than privately working with them to resolve the issue) and the committer does not want to step down, the CWG should probably be involved (certainly at least informed). I would also want such a situation to be addressed quickly and involve full consensus from the rest of the committers. If there wasn't full consensus among the other members of the group and trust was that badly breached, I would definitely want to get the help of the CWG and handle the issue privately. Not by voting.

There is one example I know of where this would have come into play during my tenure (and possibly a second from a very long time ago, which I know of tangentially). Even in the situation that I do have direct knowledge of, we chose to wait until the committer lapsed into inactivity rather than inflaming an ongoing situation at the time.

So, maybe we should also add a similar "inactivity" clause as that we have proposed for the other roles: If the committer has been wholly inactive for the past term, that is the only situation under which the term does not auto-renew. And serious breaches of trust/forced removals are a separate process.

Also, the auto-renewal only applies only to full committers. The team can still choose not to promote provisional committers and let their provisional membership lapse if it's not working out.

Reading the above it seems that the existing CWG policies and practices can be used for conflict and removals. Or at, least, it can be for now. Since that exists, I think that any discussion of changes to that or a unique process for core committers can be done in a separate issue.

I've added a sentence to the proposal in the IS to clarify that provisional committers are excluded from the process.

I agree that my proposal does add some complexity and demands more time and effort. However, this added complexity also helps mature our governance model, and moves us closer to self-governance.

I agree the governance practice needs improvement. However, we must remember that this is adding more tasks and responsibilities to the core committer team with no added support to make it happen, financially or otherwise.

This is also introducing a quorum of 60%. Why 60%? If we are establishing a quorum here, I expect it is likely to be used in other situations so can you provide more information as to why this number was chosen.

Any ideas on the point catch raised that the default is that "there's no core committers left to nominate any new ones".

Personally, I would prefer that the process in the Issue Summary was tied directly to the regular, now monthly, core committer meetings. For example, the voting would happen during the 24 hours of a meeting with the result announced at the end of the meeting. This is what I have experienced in other organizations.

Whatever the proposal decided on it should be done with a followup issue to review it in 1 years time, followed by reviews every two years after that.

I am also a bit confused about the 'knowledge base'. Step 1, point 2 says, "this helps create a public record or knowledge base." If this is to build a knowledge base, which to me implies about being a core committer, than it should not be tied to an issue about an individual's renewal. If we did that the knowledge base would be scattered over many issues.

Finally, I am changing this to Critical. This needs to be done asap so we can complete #2974514: Adopt renewable terms for core governance roles → .

I have read the proposal and all comments, together with the parent issue.

I agree with @catch, @quietone and others, that the proposal is adding more complexity and new tasks to the whole process. The committer roles are still driven by volunteers (it is not directly paid work, although some committers could be/are sponsored by companies), so it is a bit different than on some commercial projects (or companies).

The committer team is carefully picked up based on other committers suggestions and Dries approval (currently), so the chances that we will end up with someone totally on a different "wave" are small I think. @xjm probably confirmed this when mentioned two problematic cases during that long period. Therefore I think that we do not need to adapt the whole process primarily to this use-case, if it can happen only rarely, but we should adapt the new process to the current needs (so how to renew the terms most effectively). In case there will be any problems with a committer, CWG can assist here I think.

If this is going to change anytime soon, it should probably apply to D7 committer team as well. We are three committers (@mcdruid, @Fabianx, me) + Dries. Yes, we can add a temporary exception for D7 team, taking into consideration the EOL date, but if not, the process can be a bit tricky with such a small number of committers. Anyway, we should at least add a note, so that we do not forget to handle the D7 part of this.

Personally, I prefer the auto-renewal process, instead of auto-expiration (see the suggestions in #4 and #5). If we use the auto-renewal, it would still have the effect of showing to the community, that the roles have terms, that nobody must be here forever and that everyone has a right to step out. On the other hand, auto-renewal will not introduce additional "bureaucracy" (do not take this literally) and core committers would be able to focus on more important tasks. Because doing all the steps needed from the original proposal each year for each of the 12+ D10 core committers would be a high workload (one year is not as long as it might seem :) ).

That said, I support the proposal from #5, where the committer team facilitator would be responsible for getting in touch with committers, having a conversation and documenting / presenting the results. If someone would like to step down, an issue should be created and handled as usual.

I think it would be a sensible change from the current situation, where there are no terms, to a situation, where we put terms in place. In case this auto-renewal process turns out to be not suitable after some time, we can change that later, but we will avoid "drastic" changes from the beginning.

------

I see that there was one additional interesting idea proposed together with the original proposal, which might not be discarded if we use auto-renewal process:

The Core Committer whose term is ending is encouraged to share a self-assessment in the issue. They can talk about their achievements, challenges faced, lessons learned, and their willingness to continue for another term. This helps create a public record or knowledge base, and allows the group to understand the Core Committer's perspective on their role and their decision to continue or not.

I think that this is an interesting idea, that a committer would have a separate issue (a.k.a. knowledge base) and will share thoughts and some kind of self-assesment each year. This could help to provide some insight to the community. Such self-assesment is a common method used in many companies. But this should only be as a sumplementary "activity", not something, that the term renewal process should depend on. And it should be one place with all information provided during all years, not a separate issue each year (so it does not get lost between general issues).

------

There is one additional thing that came to my mind and that is about provisional committers - I think there is not a strict limit on how long a person can be a provisional committer right now. The parent issue is suggesting to set the limit for 6-12 months. Is this a strict limit? What if someone (for whatever reason) would need a bit more time? Would it be possible to extend that or the person's term will be ended (as the promotion would not happen in the term limits) and would need to start again? Should we address this scenario as well? This question would probably better suit to the parent issue, but I am putting it here too to have a complex image of the whole process.

Changing text format to filtered HTML to allow more discussion from the community.

I read the proposal and all the comments. Some thoughts:

1. I think the goal of introducing terms was to give maintainers/committers a checkpoint and an "easy way out". To paraphrase, think "my term was up so I am gone" vs. "I suck". I don't think auto-renewing by default gives that same option. It still gives resigning to the hand of the person which we previously considered to not be happening (eg. among the maintainers but also core committers) because its a psycholigical challenge.

2. I agree that using time-coordinated processes has been a challenge with the core comitter team, other than timely releases of course :) Therefore I especially don't think that @quietone's proposal about using the core meetings with 24h time limit on discussion/voting is a good idea. That would not let folks that go on vacation or are sick, etc. to participate.

3. The proposal outlines the drawbacks of the voting being a "secret" within the team. I would even go one step further actually. I think our team is comprised of considerate individuals and we default to working with people even when its hard or difficult. Openly voting within the core committer team would erode that in case the results of the vote turned the other way then you voted. So I don't think the proposed process is very likely to remove anyone at the end. The only way to build that potential in if we want to IMHO is to make the voting even more closed and even only share the results within the team in case the result is not extending the term. If the result is extending the term, having a list of people that voted against you could be quite demoralizing and would make it hard to work together. At least it would be for me. Maybe that's a feature not a bug: "if 3 people voted against me, maybe I need to change a few things", but I am not sure I could take it that positivitely :)

@Gabor's comment gives me another thought. I think the proposal in the issue summary would be very vulnerable to a 'schism'/caucusing in the core committer team, like a 60/40 split on something extremely controversial. If two people in the '40%' were up for renewal, then it would be easy to boot them off and make it an 80/20 split, especially with completely sealed ballots. If things got to that point, there would be much bigger problems than the renewal process, but also it doesn't seem like a good idea to build it in.

That would not let folks that go on vacation or are sick, etc. to participate.

I do agree that we need to have a system that allows people who are away to participate. I suggest that we allow someone to select another core committer as their proxy.

And I was just thinking about the 21 day proposal. I was just away for 5 weeks so even that was not long enough. However, if I knew a renewal discussion was coming before I left, and proxies were allowed, I would had the option to leave my instructions with a designated proxy.

I think our team is comprised of considerate individuals and we default to working with people even when its hard or difficult.

@Gábor Hojtsy, thank you. You are right, we need to protect and nurture the way we work together.

A volunteer organization I was involved used voting for some national volunteer positions. We all voted at the same time (national meeting) and the counting was done immediately after by one of the few paid employees. The results were announced that same day as just an approved or not approved. Not counts for or against, or unanimous was given. For myself, I am glad I never knew the number of votes for/against me or others. If we had that knowledge, I do think it could have caused us to second guess our decisions or to be too bold. Either way, it would not have helped us work together.

Thanks for the points @Gábor Hojtsy. I just want to react to some parts, to have fully clarified the main goals of the terms itself.

When there is a potential issue with one of the committers, would not be better to reach out to the person directly, have a conversation and sort things out? Do we need to "solve" such things with the voting, to give the person a message, "you should not continue"? Or do I understand this wrong?

It still gives resigning to the hand of the person which we previously considered to not be happening

Yes, but we will still introduce terms, so it will be easier to step-down and say, I am not going to continue the next term. Why the most important thing is "be able to delegate my step-down decision to others"? Would it feel better if nobody nominated me than if I had to announce it personally? And what about the community? Imagine a committer does not get nominated for renewal, but instead of a clear statement, people would be confused if it was a decision of the person or of the team, etc... I think at least the equally important outcome from these terms should be to give the community a message, that nobody is here forever, positions are open and everybody has right to step down. But this is, in my opinion, preserved also with the auto-renewal option.

Please note that I am not talking about inactive committers - it would be OK to remove them (and it should be somehow incorporated into the proposal). But my points are for regular committers contributing during the year.

A volunteer organization I was involved used voting for some national volunteer positions.

I can not say for sure, but I think this is a bit different from the situation when organizations vote to fill a specific position(s). In that case, you often select from X possible candidates and give one of them your "LIKE" vote. But here, we suggest to vote "LIKE/DISLIKE" for the specific person. Generally, I would not be comfortable with my work/motivation (everywhere, not just in Drupal), if I knew, that one or more persons "voted" against me (my renewal / ...). Because that person(s) gave a clear signal that they did not want me. What is a benefit of such an outcome here (and even if we did not know who voted that way)?

I think that for the team to work the best, everyone should trust each other. If not, sort things out (one way, or another), so that in the end no "DISLIKE" vote would be needed (yeah, in the ideal world :) ).

Why the most important thing is "be able to delegate my step-down decision to others"?

I believe that is where the discussion started that many people feel they betray their community by saying they are not doing something anymore, so many people have a psychological block to stepping down. By introducing this checkpoint when their term is up for renewal, its an easy way out. In an ideal world people would be entirely rational and not consider setting boundaries as betraying the Drupal community but they do.

Re the "just sort things out", I think we did that before, but there were as @xjm mentions situations that are not as easy/simple. Again a natural checkpoint I think helps here since we otherwise default to working together even if its hard or difficult.

The committer team facilitator approaches committers whose terms are ending (with term end dates distributed either quarterly or semi-annually). They have a private conversation about continuing as a core committer.

Sorry to complicate things but any reliance on the committer facilitator is not advisable. There as only ever been one person (me) to hold this role for more than a few months despite several attempts to recruit. I think we would need at least two people actively doing the role before we can make it a key part of the team governance.