Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Copy Markdown
Contributor

@rschlussel rschlussel Jun 3, 2024

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

  1. should we require actually being codeowner of two areas or demonstrating that you could be codeowner of two areas. It would be nice to be able to condense some of the beaurocracy if you know you plan to nominate someone as a committer after the second codeowner nomination. If prefered it could be submitted as a two part nomination (e.g. I'd like to nominate <person> to be codeowner of <second area>. I'd also like to nominate them to be a global committer), and then people could vote on both aspects
  2. Could there be a way to add people as committers who don't have a specific second area that they could obviously codeowners for, but maybe they have a core area and scattered contributions in many different areas? For example, in any particular second area they may only have one or two contributions, but they've made contributions in a variety of areas, and in that way have demonstrated strong skills/knowledge in the Presto code base.

Copy link
Copy Markdown
Collaborator

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

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).
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The 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
Expand Down