begin adopting CNCF-style documentation for our org structure #15
Conversation
Signed-off-by: Ian Rudie <[email protected]>
ilrudie
force-pushed
the
cncf-style-roles
branch
from
584d118
to
b43348a
Compare
|
|
||
| Each of the contributor roles below is organized into lists of three types of things. "Responsibilities" are things that a contributor is expected to do. "Requirements" are qualifications a person needs to meet to be in that role, and "Privileges" are things contributors on that level are entitled to. | ||
|
|
||
| ### Contributor |
There was a problem hiding this comment.
It probably makes sense to have an entry point which does not automatically grant having CI run against your PR and has no capability to interact with CI just to save on scarce resources.
| * Responsibilities include: | ||
| * Continues to contribute regularly, as demonstrated by having at least [TODO: Number] [TODO: Metric] a year, as demonstrated by [TODO: contributor metrics source]. <!-- Example: "as demonstrated by having at least 50 GitHub contributions per year, as shown by Devstats"--> | ||
| * Requirements: | ||
| * Must have successful contributions to the project, including at least one of the following: | ||
| * [TODO: Number] accepted PRs, | ||
| * Reviewed [TODO: Number] PRs, | ||
| * Resolved and closed [TODO: Number] Issues, | ||
| * Become responsible for a key project management area, | ||
| * Or some equivalent combination or contribution | ||
| * Must have been contributing for at least [TODO: Number] months |
There was a problem hiding this comment.
This role will likely be able to use scarce project resources and so the level of trust with the project likely needs to be a little higher.
I am wondering about setting the threshold to 5-10 PRs/Reviews/Issue and 3-6 months of activity as a contributor?
| <!-- the process of becoming an organization member is going to depend strongly on how your project manages its infrastructure. TODO: Project leads to fill in exact details of how a contributor becomes an organization member--> | ||
| 1. | ||
| 2. | ||
| 3. |
There was a problem hiding this comment.
Someone (user? existing maintainer?) files a PR against /some/ file.
- a single approver?
- simple majority of maintainers in the area?
| 2. | ||
| 3. | ||
|
|
||
| ### Reviewer |
There was a problem hiding this comment.
We can use this as essentially a maintainer who won't have a binding vote in the maintainer council but when they review code in their area it is able to merge. We could also just elide this ?rung? on the ladder and have 2 classes of maintainers (voting/non-voting) or maybe just work out a system where all maintainers get a vote which is normalized against their affiliation to prohibit vendor dominance.
| * Inactivity is measured by: | ||
| * Periods of no contributions for longer than [TODO: Number] months | ||
| * Periods of no communication for longer than [TODO: Number] months | ||
| * Consequences of being inactive include: | ||
| * Involuntary removal or demotion | ||
| * Being asked to move to Emeritus status |
There was a problem hiding this comment.
Pretty generous? 1 year?
|
|
||
| ## Contact | ||
| * For inquiries, please reach out to: | ||
| * <!-- TODO: fill in contact info for appropriate group or person for contributor mentorship--> |
There was a problem hiding this comment.
Slack channel I suppose. This might be a good reason to have a contributor slack channel.
No description provided.