MAINTAINERS_GUIDE: introduce guidance on maintainer expectations #935
Conversation
vbatts
requested review from
jonjohnsonjr,
jonboulle,
stevvooe and
cyphar
as code owners
| Maintainers are expected to be able to respond in a timely manner if their help is required on specific issues where they are pinged. | ||
| Being a maintainer is a time consuming commitment and should not be taken lightly. | ||
|
|
||
| When a maintainer is unable to perform the required duties they can be removed with a vote by **66% (2/3) of the current maintainers**. |
There was a problem hiding this comment.
Consider changing this from "current" to "voting" so that if maintainers do not vote within the 10 day period, they are not counted in the 2/3 majority threshold. This would better prepare the project if several maintainers go inactive and we cannot get 2/3 of all maintainers to respond to a vote.
We should also allow a maintainer to step down themselves, without a vote.
There was a problem hiding this comment.
hmm, I could see that getting tricky. I'm not favor of that strict of change regarding those that voted or abstained.
But yes to folks can step down without the 2/3 vote. Maybe in that case, it's just the 2 LGTM to approve a maintainer's resignation?
There was a problem hiding this comment.
The quorum problem is a weird one to solve generically... but maybe to mitigate the "multiple inactive maintainers" scenario we could introduce some requirement around activity/responsiveness? if someone doesn't respond for 6 months they're removed as a maintainer? not sure
There was a problem hiding this comment.
right. "Active" is PR review, issue comments or creation, slack/mailing-list participation, joining calls?
Seems tricksy to track without a bot.
so if a maintainer is deemed inactive, then their vote counts for less? or they can be remove with less than 2/3 quorum?
There was a problem hiding this comment.
My personal view is that the quorum rules should be the same for all governance votes because otherwise you may end up with weird cases where we could rule-lawyer ourselves into weird situations.
The rest of the OCI (both projects and the TOB) use qualified super-majority votes (2/3 of all seats, with abstaining seats counted as being against the motion) so I don't feel particularly comfortable with changing the rules for this one governance procedure in one project. A project with healthy maintainership that has a single maintainer they wish to remove should not have any issues getting a 2/3 vote if that is what the will of the project is. I'm also not sure that a maintainer being on vacation for a few weeks (as I am now) is reasonable grounds to reduce the level of review necessary for what is effectively a governance change.
If we are continuing to have inactive maintainer issues such that such a mechanism cannot work, then we should solve it by removing inactive maintainers (I am aware that I would probably be included under that label as I haven't been involved in the more recent image signing and related work) and being more assertive about it than last time.
But that's just my 2 cents.
There was a problem hiding this comment.
Would it be useful to have a state between active and removed? Allow a maintainer to be marked as inactive if they aren't responding for X months, so that 2/3rd majorities aren't impossible to achieve. But those inactive maintainers could be easily reactivated if they later returned. Perhaps a 2 active maintainer vote to move someone between active and inactive, but 2/3rds of active maintainers to remove a maintainer or perform other large changes.
I think a policy to handle these situations would be useful in lots of open source governance docs, not just in image-spec. People change jobs or have major life changes that result in us going quiet. And if routine updates still happen with the existing moderators, no one notices until a major change is needed.
vbatts
force-pushed
the
maintainer_guide
branch
from
1e6b5e0
to
6b9b7d2
Compare
| Maintainers are expected to be able to respond in a timely manner if their help is required on specific issues where they are pinged. | ||
| Being a maintainer is a time consuming commitment and should not be taken lightly. | ||
|
|
||
| When a maintainer is unable to perform the required duties they can be removed with a vote by **66% (2/3) of the current maintainers**. |
There was a problem hiding this comment.
The quorum problem is a weird one to solve generically... but maybe to mitigate the "multiple inactive maintainers" scenario we could introduce some requirement around activity/responsiveness? if someone doesn't respond for 6 months they're removed as a maintainer? not sure
This is adopted from https://github.com/opencontainers/runc/blob/602c85fdc6c73d614213fc1759f8e710e54047ca/MAINTAINERS_GUIDE.md Notably: - making the "runc" into a more generic "this project" - dropping the concept of "chief maintainer" - formatting to a sentence per line Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
vbatts
force-pushed
the
maintainer_guide
branch
from
6b9b7d2
to
2de07a5
Compare
|
good comments. Updated. |
|
|
||
| All decisions are pull requests, and the relevant maintainers make decisions by accepting or refusing the pull request. | ||
| Review and acceptance by anyone is denoted by adding a comment in the pull request: `LGTM` (or using the "Approve" feature in GitHub PR reviews). | ||
| However, only currently listed `MAINTAINERS` are counted towards the required **two LGTMs**. |
There was a problem hiding this comment.
We often run into situations where it's a maintainer who's opened a PR and it's unclear whether their "self-LGTM" counts towards the two or not -- should we continue to handle these case-by-case, or do any maintainers think it's worth explicitly calling out one way or the other directly in the guide?
Similarly, should we call out "trivial URL fix" exceptions like opencontainers/runtime-spec#1157 explicitly, or continue to handle those case-by-case as well?
(I don't have any strong opinions on either of these one way or another, just things that come to mind while I'm reading the doc.)
There was a problem hiding this comment.
Is there a way in the github approval process to reduce the LGTM is the PR is from a maintainer?
There was a problem hiding this comment.
You cannot self-LGTM with GitHub reviews, so if we require GitHub reviews then maintainers already cannot self-LGTM. But we should have an explicit statement whether self-LGTMs are allowed (I've gone back and forth on the issue over the years, but there should be a statement of what the rule is so we're all on the same page).
| This document is a manual for maintainers old and new. | ||
| It explains what is expected of maintainers, how they should work, and what tools are available to them. | ||
|
|
||
| This is a living document - if you see something out of date or missing, please submit a change! |
There was a problem hiding this comment.
Is this document a governance document or just an informational document? If it's the former we should mention that changes require a 2/3rd LGTM.
There was a problem hiding this comment.
good question. Seems like a typo would be silly to have 2/3 LGTM, but otherwise it is like a governance doc.
This is adopted from https://github.com/opencontainers/runc/blob/602c85fdc6c73d614213fc1759f8e710e54047ca/MAINTAINERS_GUIDE.md
Notably:
Signed-off-by: Vincent Batts vbatts@hashbangbash.com
As this effectively is putting into effect expectations for current maintainers, I would expect this PR to get review from maintainers and only merge with a 2/3 majority quorum , rather than the simple 2 LGTM
cc @opencontainers/image-spec-maintainers: