Add committer, maintainer lifecycle criteria to graduation requirements

[mrbobbytables]

I wanted to start a discussion on expanding requirements for project graduation for their committer and maintainer policies to take into account the full contributor lifecycle. While many projects have some broad guidance, these roles tend to be a for-life type situation or requires a group to take a large public action to remove someone if they're not actively involved in a project. e.g. a person who has not been active within a project for a year or longer should not be listed as a maintainer and able to represent the project when interacting with the CNCF (submitting service desk tickets, kubecon maintainer track sessions etc).

Things like the maintainer list are also used as external signal that a project is healthy, and it can be way off base if the listed maintainers are all inactive. -_-

I'm not married to any particular language, but IMO it is something that projects should consider and codify.

It might also be more appropriate for graduated projects and listed as a requirement under graduation state in the graduation criteria doc.

cc @dims @parispittman @jberkus

[caniszczyk]

Good idea for clarity I consider this implied in current wording tbh so I don't think it requires a full @cncf/toc vote.

Also the words committer == maintainer

[jberkus]

@caniszczyk committer != maintainer. That is, a committer is someone who has merge rights (a better term might be "approver"), whereas a "maintainer" is someone who has the rights to, among other things, communicate with the CNCF on behalf of the project. Those are overlapping groups, but not identical. For example, several projects have a non-coding community manager on their maintainer list.

[mrbobbytables]

Alternate language if we want to call out maintainers explicitly as separate from committers:

7. Explicitly define a project governance and committer process. The committer process should cover the full
committer lifecycle including onboarding and offboarding or emeritus criteria. This preferably is laid out in a
GOVERNANCE.md file and references an OWNERS.md file showing the current and emeritus committers.
8. Explicitly define the criteria, process and offboarding or emeritus conditions for project maintainers; or
those who may interact with the CNCF on behalf of the project. The list of maintainers should be preferably be
stored in a MAINTAINERS.md file and audited at a minimum of an annual cadence.

[jberkus]

Are we sure we want to use the term "committer" rather than "approver"?

[mrbobbytables]

Are we sure we want to use the term "committer" rather than "approver"?

I think so, that mirrors the CNCF foundation charter language

[dims]

@jberkus if this looks ok to you, i am happy to 🚢 this!

[jberkus]

/lgtm

[dims]

@amye @caniszczyk this is ready to be merged.

[dims]

Let's start the clock for a 2 week comment period on this!

[mrbobbytables]

Any preference on the language? Do you think committer and maintainer should be called out separately?
There are a few other places where the language should be updated - if the verbage there is good enough I can update the PR to touch the other places.

[amye]

Let's start the clock for a 2 week comment period on this!

2 weeks from submission gets us July 29th, which is fine

[cathyhongzhang]

@mrbobbytables Yes, it is better to call out the committer and maintainer separately.

[sdake]

I am really happy to see the Emeritus off boarding to be a priority. No other foundation that I am aware of sets requirements to record in writing the prior developers and leadership that led to the success of the project!

Cheers
steve

[mrbobbytables]

I've updated the PR with breaking out committers and maintainers into separate items in addition to updating all the different locations with the new language.

SIDENOTE: There is a lot of duplication of these items across the repo, It'd be great to consolidate these down to one or two authoritative places.

[dims]

Past the 2 week dead line and no new comments after the public TOC meeting as well. Merging now.

[caniszczyk]

I think for all intensive purposes, committer has been well defined in open source foundation parlance for awhile, basically someone who has the commit bit https://infra.apache.org/committers.html https://www.eclipse.org/projects/handbook/#contributing-committers etc I use maintainer and committer interchangeably tbh as I don't really see there is no distinction. We can just state that somewhere imho

…

On Wed, Jul 27, 2022 at 1:21 PM Bob Killen ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In .github/ISSUE_TEMPLATE/graduation.md <#876 (comment)>: > @@ -2,7 +2,8 @@ - [ ] Have committers from at least two organizations. - [ ] Have achieved and maintained a Core Infrastructure Initiative Best Practices Badge. - [ ] Have completed an independent and third party security audit with results published of similar scope and quality as this example which includes all critical vulnerabilities and all critical vulnerabilities need to be addressed before graduation. -- [ ] Explicitly define a project governance and committer process. This preferably is laid out in a GOVERNANCE.md file and references an OWNERS.md file showing the current and emeritus committers. +- [ ] Explicitly define a project governance and committer process. The committer process should cover the full committer lifecycle including onboarding and offboarding or emeritus criteria. This preferably is laid out in a GOVERNANCE.md file and references an OWNERS.md file showing the current and emeritus committers. Committer was the language used in the CNCF Foundation charter which I think is what lead to it being used in the various other docs. FWIW it is defined as: "A committer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project." in the main graduation process readme: https://github.com/cncf/toc/blob/c936591a9c17eac011b890387fcd4b8a653184b0/process/README.md?plain=1#L65 I do think that surfacing these terms in a more discoverable fashion would be good. I do think that most folk don't use that language these days, but changing it might have other ramifications unless the foundation charter is also updated :x — Reply to this email directly, view it on GitHub <#876 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAPSILILMLDXQOKUHGIUYLVWFV2PANCNFSM5353IAZA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Cheers, Chris Aniszczyk https://aniszczyk.org