Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MAINTAINERS_GUIDE: introduce guidance on maintainer expectations #935

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

vbatts
Copy link
Member

@vbatts vbatts commented Aug 9, 2022

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 [email protected]

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:

MAINTAINERS_GUIDE.md Outdated Show resolved Hide resolved
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**.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@vbatts vbatts Aug 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

@cyphar cyphar Aug 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

MAINTAINERS_GUIDE.md Outdated Show resolved Hide resolved
MAINTAINERS_GUIDE.md Outdated Show resolved Hide resolved
MAINTAINERS_GUIDE.md Outdated Show resolved Hide resolved
MAINTAINERS_GUIDE.md Outdated Show resolved Hide resolved
MAINTAINERS_GUIDE.md Outdated Show resolved Hide resolved
MAINTAINERS_GUIDE.md Outdated Show resolved Hide resolved
MAINTAINERS_GUIDE.md Outdated Show resolved Hide resolved
MAINTAINERS_GUIDE.md Outdated Show resolved Hide resolved
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**.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 <[email protected]>
@vbatts
Copy link
Member Author

vbatts commented Aug 10, 2022

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**.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way in the github approval process to reduce the LGTM is the PR is from a maintainer?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good question. Seems like a typo would be silly to have 2/3 LGTM, but otherwise it is like a governance doc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants