add project contributor role to contributor ladder

[hone]

Based on discussions from the community WG, I'm proposing adding a project contributor role to the contributor ladder mirror other CNCF projects. This provides a path: Contributor -> Maintainer/Community Manager.

I have some open questions:

• Where should we list contributors? For now I put it in MAINTAINERS.md, but this feels wrong b/c Project Contributors aren't maintainers. Importantly, they shouldn't be included in the CNCF maintainers list. Should we rename MAINTAINERS.md to something like TEAM.md or create a new file?
• In the MAINTAINERS.md table, there's a Responsibilities column, for Project Contributors what would that be?
• For admitting a new Project Contributor to match what we did with maintainers: majority to accept and super majority (2/3rds) to remove. I wasn't sure if you just wanted majority for both since the impact is lower.
• There was mention of adding a reviewing role to the ladder, but I don't know if we need that much structure yet.

[nimbinatus]

I think this makes sense. I have a couple thoughts on changes, but I won't make suggestions just yet as I want to respond to your questions.

• Where should we list contributors? For now I put it in MAINTAINERS.md, but this feels wrong b/c Project Contributors aren't maintainers. Importantly, they shouldn't be included in the CNCF maintainers list. Should we rename MAINTAINERS.md to something like TEAM.md or create a new file?

I've usually found this kind of role (typically something more like "member") to be defined by org membership, tbh. Examples:

• https://github.com/argoproj/argoproj/blob/main/community/membership.md
• https://github.com/openkruise/community/blob/master/community-membership.md
• https://github.com/volcano-sh/community/blob/master/community-membership.md
• https://github.com/crossplane/crossplane/blob/main/GOVERNANCE.md#organization-members
• and, of course, https://github.com/kubernetes/community/blob/main/community-membership.md

• In the MAINTAINERS.md table, there's a Responsibilities column, for Project Contributors what would that be?

Based on examples like the above, I'd just say "active contributions" as use the inactive categorization you've already laid out as the definition.

• For admitting a new Project Contributor to match what we did with maintainers: majority to accept and super majority (2/3rds) to remove. I wasn't sure if you just wanted majority for both since the impact is lower.

Personally, I like the lightweight option of (1) open an issue here with details on your contributions (i.e., how do you meet the activity criteria), (2) get two plus-ones from reviewer+ (so maintainer here) from any subproject, then (3) get added to the org with the person doing the work welcoming you to the org and closing the issue as completed. I'm open to suggestions, though.

• There was mention of adding a reviewing role to the ladder, but I don't know if we need that much structure yet.
  Probably not, especially if contributors can help review with Triage access.

Probably not? But something we'll likely want in the future...

[nimbinatus]

Adding the maintainers for review.

[nimbinatus]

Following my prior comment, here's the suggestions I'd make.

[nimbinatus]

Suggested change

A new Project Contributor can be proposed by an existing Maintainer or by the candidate themselves by opening a PR against [MAINTAINERS.md](./MAINTAINERS.md). The nomination will be approved via lazy consensus or a simple majority vote of the Maintainers.

A new Project Contributor can be proposed by an existing Maintainer or by the candidate themselves by [opening an issue in the community repo](https://github.com/bootc-dev/community/issues/new/choose). After detailing their activity that meets the criteria above, two or more Maintainers who have worked with the candidate on the project in the named activities must sponsor the candidate by commenting on the issue. Then the new contributor can be added to the org and welcomed on the issue before closing it as completed.

Not sure I exactly like this wording, but this is the vague version. There's a number of examples I linked to in the other comment if you want to reword this :)

[hone]

@nimbinatus what's interesting here is contributors have a lower criteria bar, but there's a requirement that a candidate has to show their activity which is not true for maintainers.

[nimbinatus]

Usually with this kind of wording, the expectation is that a maintainer must maintain the same level of expectation as the rungs lower on the ladder (i.e., in addition, not independent rungs). We could word that more explicitly?

[cgwalters]

This is a pretty low permission level. I'd personally like to add a finer grain here in the future; like one thing I can imagine here is for "low risk PRs" a project contributor could approve/merge too e.g.

[cgwalters]

(Nonblocking for here, just brainstorming)

[hone]

How do you determine if something is "low risk"? Is it just a "trust" thing?

[cgwalters]

I'm kind of just making things up here but I think it's a combination of basic things like CODEOWNERS plus LLM risk analysis

[cgwalters]

Or to say it a different way, I would personally like to also require "large" PRs to be reviewed by two maintainers say (or at least 1 maintainer and 1 contributor) etc.