Adopt renewable terms for core governance roles

Created on 22 May 2018, about 6 years ago
Updated 25 June 2024, 3 days ago

About

At DrupalCon Vienna, the Drupal 8 core committers discussed the idea of having renewable terms for core committers. At DrupalCon Nashville, wider community governance discussions also included discussions about how adding terms to the governance could help scale the community and make it more inclusive.

Reasons to have terms

  • Reduce burnout as well as pressure when stepping back.
  • Make it easier to gracefully remove team members who are inactive or haven't been able to contribute effectively in the role.
  • Encourage more diversity on the committer team by providing a more regular checkpoint to change or expand the current team.
  • Make the need for maintainers (and the need to support them) more visible to the community.

Proposal

See the Drupal core governance overview β†’ for information on the different roles.

Note that the "committer team facilitator" and "core initiative facilitator" roles are a separate proposal that has not been finalized/adopted. See #2974016: Add "committer team facilitator" and "core initiative facilitator" roles to core governance β†’ .

Product, framework, and release managers

  • The product, framework, and release manager roles have an initial term of two years. The initial term includes 6-12 months as a provisional committer followed by 12-18 months as a full committer.
  • After the initial two-year term, the term can be renewed annually, with the signoff of both the individual and the BDFL or full committer team. *This item is being discussed in #3374499: How to renew Core Committer terms β†’ *
  • Committer terms are staggered by quarter over the calendar year, so that there is not too much turnover at any one time.
  • It is also possible (and sometimes even recommended) for a committer to take a term off. In this case their term is renewed at a later date (again with the signoff of both the individual and the BDFL or full committer team.
  • There is currently no limit on the number of consecutive terms a product, framework, or release manager can serve, for several reasons:
    • There is no fixed limit on the number of product, framework, or release managers. Having a given individual in the role for many years does not prevent other contributors from being appointed.
    • The skillset for product, framework, and release managers is specialized. The needed training and ramp-up time is more significant compared to other maintainer roles.
    • The current committer team is not yet sufficient to fully meet the demands of Drupal development and maintenance. Forcing current team members to step down without any reason other than terms would not be in the best interests of the project. This is especially true for committers that are funded in their roles and securing such funding is difficult.

Committer team facilitators and core initiative facilitators

  • Facilitators have a one-year term. The initial term includes 6 months as a provisional facilitator followed by 6 months as the lead facilitator.
  • A new facilitator ideally starts each minor release. That means, that any given time, there is at least one provisional facilitator and one lead facilitator.
  • Facilitators can serve multiple terms with the signoff of both the individual and the BDFL or full committer team.

Topic maintainers, subsystem maintainers, and initiative coordinators

  • Subsystem maintainer, topic maintainer, and initiative coordinator roles do not have fixed terms.
  • All maintainers are contacted once per year and asked to submit a patch removing themselves from MAINTAINERS.txt if they are not currently active (i.e., have not at least contributed in the role in the past year). Maintainers that do not respond to this contact are automatically removed from the role. Maintainers who have low activity may be contacted as well on a case-by-case basis.

Potential risks

Discuss!

Remaining tasks

  1. Has #24 -> #26. been resolved?
  2. The signoff process. That is being done in child issue #3374499: How to renew Core Committer terms β†’

Followup, non-blocking, issues for

  1. Add term limits. #28
  2. Add sabbaticals. #31/#34
  3. Review scope of subsystem maintainer role and promote and recruit at events. #7
✨ Feature request
Status

Needs work

Component

Policies

Created by

πŸ‡ΊπŸ‡ΈUnited States xjm

Live updates comments and jobs are added and updated live.
  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Status changed to Needs review over 1 year ago
  • Status changed to Needs work over 1 year ago
  • πŸ‡³πŸ‡ΏNew Zealand quietone New Zealand

    I have been re-reading the proposal while I was working to convert it to plain English. I found some things I want to mention.

    1. In the table where it says 'None currently' for the term length. That should just be 'None'.
    2. The table could make it clearer that all terms are 1 year. The title 'Initial term' can be 'Term' and a phrase added to the manager cell such as 'initial term is 2 yrs'.
    3. The word 'renew' is used throughout and it isn't stated what is done to initiate a renewal, except perhaps for topic maintainers and subsystem maintainers.
    4. Are Initiative coordinators included in the final paragraph, the one that begins 'All maintainers are contacted...?
  • πŸ‡§πŸ‡ͺBelgium Dries

    In general, I'm a big fan of introducing terms.

    I also think it is a great idea to try and stagger terms. Based on experience with other teams, the staggering can be difficult to accomplish in practice. That is ok though; it doesn't have to be perfect.

    I'm ok with the proposed term lengths. They seem sensible, and they can be easily adjusted latter.

    Term limits is something worth discussing, later. If you are not familiar: term limits force people to take a break after x terms. Usually, people are forced to take a 1-term break, before they can rejoin the team. In this model, managing backfills and continuity becomes be really hard, but it is also very healthy. It forces you to build a pipeline of viable candidates, it encourages succession planning, it discourages 'single points of failure', and it forces people to take a break.

    I don't recommend we introduce term limits at this point. I like the simplicity and continuity of the current proposal. It puts us on a good path forward, with the flexibility to make adjustments later.

    My main concern is that not many core committers / maintainers have chimed in on this issue. At a minimum, I recommend we discuss this some more within the core committer team. I'd like to see some more +1s before finalizing this proposal.

  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    +1 from me on this

  • πŸ‡«πŸ‡·France nod_ Lille

    Very much +1 to this

  • πŸ‡¬πŸ‡§United Kingdom catch

    Renewable but non-limited terms is good.

    One thing that appears to be completely missing from the proposal is the ability for people to take sabbaticals - i.e. someone should be able to take 3 or 12 months off, then re-enter their role, without having to re-apply, whether it's just because they need a break or they need specific time off for whatever reason.

    Somewhat related to that, I think this requirement in the issue summary is a bit tricky:

    After the initial two-year term, the term can be renewed annually, with the signoff of both the individual and the BDFL or full committer team.

    We shouldn't rely on every single member of the committer team + Dries to pro-actively sign off on a term being renewed, that's a recipe for someone being essentially ejected by default or more likely being in limbo for months with unclear status. For example it has in recent history taken months to add provisional committers (or make provision committers permanent) for similar reasons. This doesn't need much of a change just something like 'a quorum of the committer team', or just let people renew themselves and have a completely separate mechanism for removing someone unrelated to terms. Some aspects of this are already being addressed elsewhere in the governance documentation but we also shouldn't re-introduce similar hurdles here.

  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    We shouldn't rely on every single member of the committer team + Dries to
    pro-actively sign off on a term being renewed, that's a recipe for someone
    being essentially ejected by default or more likely being in limbo for months
    with unclear status. For example it has in recent history taken months to add
    provisional committers (or make provision committers permanent) for similar
    reasons. This doesn't need much of a change just something like 'a quorum of
    the committer team', or just let people renew themselves and have a
    completely separate mechanism for removing someone unrelated to terms. Some
    aspects of this are already being addressed elsewhere in the governance
    documentation but we also shouldn't re-introduce similar hurdles here.

    Agree πŸ’―

  • πŸ‡¦πŸ‡ΊAustralia pameeela

    This sounds sensible to me.

  • πŸ‡§πŸ‡ͺBelgium Dries

    I'm also in favor of incorporating a system that enables smooth sabbaticals. Here is a first proposal to flush out that idea a bit more:

    1. Sabbaticals can be taken between two terms, lasting up to 9 months.
    2. Alternatively, individuals can take sabbaticals during a 2-year term, with a maximum duration of 9 months. To eliminate administration and avoid tracking or calculating term expiration dates, a sabbatical does not extend the term limit.

    We could consider extending it to 12 months. After a certain period, it may be more appropriate to re-apply. To me, 9 months seems reasonable, but I'm very much open to suggestions on that!

  • πŸ‡§πŸ‡ͺBelgium Dries

    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: How to renew Core Committer terms β†’ .

  • πŸ‡³πŸ‡ΏNew Zealand quietone New Zealand

    I have updated the IS with any remaining tasks I have found.

    For #27. This is mine and minor, there is no need for any action.

    @catch, you tagged this for an IS update. Can you clarify what needs updating?

  • πŸ‡³πŸ‡ΏNew Zealand quietone New Zealand

    I changed the proposal to use plain English. No other changes were done so this can be easily be reverted if needed.

  • πŸ‡­πŸ‡ΊHungary GΓ‘bor Hojtsy Hungary

    The new roles have been in place for a while.

Production build 0.69.0 2024