-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Add updated guidelines for committers and code owners #19803
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -137,6 +137,12 @@ Presto committers are defined as [code owners](https://docs.github.com/en/reposi | |
|
|
||
| New committers are approved by majority vote of the TSC ([see TSC charter](https://github.com/prestodb/tsc/blob/master/CHARTER.md)). To become a committer, reach out to an [existing TSC member](https://github.com/prestodb/tsc#members) and ask for their feedback on your eligibility (see: [How to become a Presto Committer?](https://github.com/prestodb/presto/wiki/How-to-become-a-Presto-committer%3F)). Note: to expedite the process, consider creating a document that outlines your Github stats, such as the number of reviews, lines of code added, number of PRs, and outlines particularly outstanding code and review contributions. If the TSC member believes you are eligible, they will submit your nomination to a vote by the TSC, typically in the form of a PR that adds your handle to the `CODEOWNERS` file. The process is complete once the PR is merged. | ||
|
|
||
| Committers are responsible for providing final approval of pull requests in a timely manner. If the committer is unable to provide timely review, they should assign the pull request to another committer. | ||
|
|
||
| The [CODEOWNERS](CODEOWNERS) file should list the backup committers, called the [committers](https://github.com/orgs/prestodb/teams/committers) team, alongside any file grouping, and as a general | ||
| fallback for file groupings that don't exist. The TSC may add additional backup committers as needed. The requirement for addition to the backup committers group is two or more code owners responsibilities in the Presto repository | ||
| and approval from the TSC. To nominate someone (including yourself) to be included in the backup committers team, send an email requesting this to [operations@prestodb.io](mailto:operations@prestodb.io). | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. curious why this is done by email to operations rather than being the same process as for codeownership (i do think it's nice to allow people to nominate themselves in general, so I like that that's an additional option if you don't want to go directly through a tsc member). Also, the codeowner guidelines need to be updated codeowner nominations are voted on in the tsc-private mailing list and then submitted as a PR just to update the file, but the voting is not done by PR submission. |
||
|
|
||
| ## Pull Request Checklist | ||
|
|
||
| - Branch from the master branch and, if needed, rebase to the current master | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
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 think having people with broad committership rights is valuable, so I think we should encourage growing the list of backup committers (while maintaining high expectations of anyone nominated). 2 things I'm thinking about
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.
+1. Codeowners of two or more areas is definitely good. Deep in one area with contributions in a variety of areas is also good.
Not sure if we need to explicitly make two or more code owners as a pre-requisite