- Status changed to Needs review
almost 2 years ago 3:03am 17 January 2023 - Status changed to Needs work
almost 2 years ago 7:47pm 17 January 2023 - π³πΏNew Zealand quietone
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.
- In the table where it says 'None currently' for the term length. That should just be 'None'.
- 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'.
- 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.
- 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.
- π¬π§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 π―
- π§πͺ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:
- Sabbaticals can be taken between two terms, lasting up to 9 months.
- 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
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
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.
- π³πΏNew Zealand quietone
Work for subsystem and topic maintainers is now in #3458223: Adopt renewable terms for subsystem and topic maintainers β . Updated the IS accordingly.