Add an issue template for maintainer onboarding #1924
Conversation
svrnm
requested review from
alolita,
austinlparker,
danielgblanco,
dyladan,
jpkrohling,
mtwo,
tedsuo and
trask
as code owners
| type: checkboxes | ||
| attributes: | ||
| label: Maintainer Onboarding Tasks | ||
| description: | |
There was a problem hiding this comment.
Should this mention that these are to be done by a current maintainer?
There was a problem hiding this comment.
Yeah, this needs to be clearer
| type: checkboxes | ||
| attributes: | ||
| label: Maintainer Election | ||
| description: | |
There was a problem hiding this comment.
Should this point back to the Becoming a Maintainer part of the docs rather than repeating the election process?
There was a problem hiding this comment.
good point! Let me fix that.
| approval, the pull request should stay open for a minimum of 5 days before merging. | ||
|
|
||
| The nominee is considered a maintainer after the pull request is merged. | ||
| a new maintainer is elected by vote of thee existing maintainers of the SIG. |
There was a problem hiding this comment.
| a new maintainer is elected by vote of thee existing maintainers of the SIG. | |
| a new maintainer is elected by vote of the existing maintainers of the SIG. |
| issue can be closed and the nominee has not been elected. | ||
|
|
||
| In the case that no majority in favour or against the nominee can be accomplished | ||
| within 5 days, a minority vote sufficies. |
There was a problem hiding this comment.
| within 5 days, a minority vote sufficies. | |
| within 5 days, a minority vote suffices. |
|
|
||
| - If the majority have voted in favour of the nominee, the candidate accepts | ||
| (or declines) the vote by commenting "I accept" or "I decline". The nominee is | ||
| considered a maintainer immediatly after they accepted. |
There was a problem hiding this comment.
| considered a maintainer immediatly after they accepted. | |
| considered a maintainer immediately after they accepted. |
| label: Maintainer Election | ||
| description: | | ||
| Unless stated otherwise in a SIG charter ratified by the Technical Committee, all existing maintainers are asked to vote, | ||
| if the candidate should be added to their group of maintainers. They vote by commenting "I support" or "I do not support" on this issue. |
There was a problem hiding this comment.
The way we typically do this on the Collector SIG is to first have some discussion happen privately and then we make this public on a PR. Should we explicitly recognize this?
|
Closing this for now, although I still think we need that, but we have to revisit is as part of SIG ContribEx |
This PR introduces a dedicated issue template to elect and onboard a new maintainer.
Preview: https://github.com/svrnm/community/issues/new?assignees=&labels=area%2Fgithub-membership&projects=&template=maintainer-onboarding.yml&title=Onboard+%3CGitHub+handle%3E+as+%3CSIG%2FWG+FOO%3E+maintainer
Problem
the current process to elect maintainers has never(?) been applied, and since the list of maintainers & approvers lives mainly in the SIG repos now ("The list of active members (both "approvers" and "maintainers") for the can be found in the README file") it also does not match the requirements anymore.
Unfortunately, by only updating those files in the repo (or updating the github teams) the community does not hear about new maintainers stepping up. This makes it hard for cross-functional SIGS (Comms, EUWG, security, demo) to know who the maintainers are and also the TC&GC has no full visiblity into that, making it hard to judge from the outside if a SIG has a healthy set of maintainers. Finally, we (the OpenTelemetry community) should treat an individual stepping up as a maintainer as a highlight, that should be visible and recognized.
Solution
By introducing an onboarding issue for maintainers we can address all those needs, and at the same time also accomplish a few additional things, like having checklists for existing maintainers and new maintainers, or being able to introduce same additional rituals (e.g. introducing an informal chat between a new maintainer and a GC member to welcome them)
Please, take a look at this PR. I added a lot of additional features, that may not be wanted, so I expect this file to shrink, and there may be things I missed, so it might grow.
Other details