-
Notifications
You must be signed in to change notification settings - Fork 232
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
update ROLES.md to more accurately reflect reality #1343
Conversation
This is a first pass at rewriting the ROLES.md document to more accurately reflect the reality of the roles and responsibilities in the knative and knative-sandbox GitHub organizations. I have based these changes, in part, on the CNCF Ladder template found here: https://github.com/cncf/project-template/blob/main/CONTRIBUTOR_LADDER.md Major changes include the addition of a Contributor role, which grants no explicit privileges, combination of the Technical and Execution lead roles for Working Groups into a single Working Group Lead role, and the removal of the Scribe role, which appears to be more aspirational than anything else. I have removed the Requirements, Privileges, and Scope sections from the summary table so that it reflects simply the Responsiblities of each role, with details spelled out in the subsequent text. The Responsibilities sections in the text could be further refined. I also found it quite difficult to map the peribolos groups that are reflected in `OWNERS` files to the Member and Approver Roles and would appreciate a review of these items specifically. It is not clear, based on what I can see in `./peribolos/knative.yaml`, what groups actually allow for reviews and which allow for approvals and write permissions on the repositories. Signed-off-by: Lance Ball <[email protected]>
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lance The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: Lance Ball <[email protected]>
For this PR I focused exclusively on the ascension ladder, but not on removal or stepping down. Those should be added in a subsequent PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this! Left a few comments.
ROLES.md
Outdated
|
||
## Member | ||
|
||
Established community members are expected to demonstrate their adherence to the | ||
A Member is an established Contributor who regularly participates in the | ||
project. Members have privileges in both project repositories and elections, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought that elections were specifically limited to people who had 50 contributions in the last year, not to a "member level" (though it would be odd to have 50 contributions and not be an org member).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wondered about this. The wording comes from the CNCF template referenced in the PR description. I think being a Member should allow a contributor to participate in elections, and we should eliminate the 50 contribution requirement. "Contributions" are hard to quantify outside of actual GitHub activity, and we define "contributions" as including other activities, such as @nainaz being a presence at KubeCon and representing the project in a large public setting. How many "contributions" does that account for? In my opinion, being a Member should be enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our current elections rules also allow individuals to request an exception if they have non-GitHub contributions. Note that contributions include issue and PR comments in addition to commits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May be we can lower the limit from 50 to 25? to increase the pool?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we open an issue (feel free to assign it to me) to separate the conversation around who should be eligible to vote from this PR? I think it's better not to hold this PR up for that discussion, since we'd need to make that change elsewhere anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done: #1350
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have removed this wording from the PR so that this one can land, and we can follow up with voting responsibilities (if needed) in this document after #1350 is resolved.
/cc @nainaz @csantanapr
Co-authored-by: Evan Anderson <[email protected]>
Signed-off-by: Lance Ball <[email protected]>
Signed-off-by: Lance Ball <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much for doing this! Overall, it looks great. I know I've made a ton of suggestions, but most of them are relatively minor and along a few common themes (like making the language more inclusive for non-code contributions) :)
ROLES.md
Outdated
|
||
## Member | ||
|
||
Established community members are expected to demonstrate their adherence to the | ||
A Member is an established Contributor who regularly participates in the | ||
project. Members have privileges in both project repositories and elections, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we open an issue (feel free to assign it to me) to separate the conversation around who should be eligible to vote from this PR? I think it's better not to hold this PR up for that discussion, since we'd need to make that change elsewhere anyway.
Co-authored-by: Dawn Foster <[email protected]>
Signed-off-by: Lance Ball <[email protected]>
@knative/steering-committee can someone ptal and lgtm this? |
/lgtm |
This is a first pass at rewriting the ROLES.md document to more accurately reflect the reality of the roles and responsibilities in the knative and knative-sandbox GitHub organizations. I have based these changes, in part, on the CNCF Ladder template found here:
https://github.com/cncf/project-template/blob/main/CONTRIBUTOR_LADDER.md
Major changes include the addition of a Contributor role, which grants no explicit privileges, combination of the Technical and Execution lead roles for Working Groups into a single Working Group Lead role, and the removal of the Scribe role, which appears to be more aspirational than anything else.
I have removed the Requirements, Privileges, and Scope sections from the summary table so that it reflects simply the Responsiblities of each role, with details spelled out in the subsequent text.
The Responsibilities sections in the text could be further refined.
I also found it quite difficult to map the peribolos groups that are reflected in
OWNERS
files to the Member and Approver Roles and would appreciate a review of these items specifically. It is not clear, based on what I can see in./peribolos/knative.yaml
, what groups actually allow for reviews and which allow for approvals and write permissions on the repositories.Preview: https://github.com/lance/community/blob/update-roles-md/ROLES.md
Fixes: #1049
/cc @evankanderson @geekygirldawn @knative/steering-committee