Contribution process

This is the process we suggest for contributions. This process is designed to reduce the burden on project reviewers, impact on other contributors, and to keep the amount of rework from the contributor to a minimum.

1. Sign the contributor license agreement.

2. Start a discussion by creating a GitHub issue, or asking on Slack (unless the change is trivial, for example a spelling fix in the documentation).

   1. This step helps you identify possible collaborators and reviewers.
   2. Does the change align with technical vision and project values?
   3. Will the change conflict with another change in progress? If so, work with others to minimize impact.
   4. Is this change large? If so, work with others to break into smaller steps.

3. Implement the change

   1. If the change is large, post a draft GitHub pull request with the title prefixed with [WIP], and share with collaborators.
   2. Include tests and documentation as necessary.

4. Create a GitHub pull request (PR).

   1. Make sure the pull request passes the tests in CI.
   2. If known, request a review from an expert in the area changed. If unknown, ask for help on Slack.

   There are some tests that use external services, like Google BigQuery, and require additional credentials. The Trino project cannot share these credentials with contributors, so it runs these tests in its CI workflows only on branches in the Trino repository, not in contributor forks.

   Trino maintainers can schedule additional workflow runs after reviewing a PR by adding a comment starting with this line:

    /test-with-secrets sha=<all-40-characters>
   

   The SHA value should be the full 40 character git SHA of a commit of the feature branch, usually the head commit.

5. Review is performed by one or more reviewers.

   1. This normally happens within a few days, but may take longer if the change is large, complex, or if a critical reviewer is unavailable. (feel free to ping the reviewer or DevRel team on the pull request).

6. Address concerns and update the pull request.

   1. Comments are addressed to each individual commit in the pull request, and changes should be addressed in a new fixup! commit placed after each commit. This is to make it easier for the reviewer to see what was updated.
   2. After pushing the changes, add a comment to the pull-request, mentioning the reviewers by name, stating that the review comments have been addressed. This is the only way that a reviewer is notified that you are ready for the code to be reviewed again.
   3. Go to step 5.

7. Maintainer merges the pull request after final changes are accepted.

   • Approval of a reviewing maintainer is required before a pull request can be merged. If a maintainer authors a pull request, another maintainer must approve it.
   • Approvals and input from other reviewers are helpful for the decision of the maintainers, but not required.
   • In the event that the maintainer team is divided on whether a particular contribution should be merged, the final decision is made by the BDFLs of the project.

8. Maintainers organize a release to ship the next Trino version with your improvements.

   • All maintainers and the DevRel team collaborate to include your change in the release notes.
   • Roughly every week, the maintainers initiate a new release build. Exact timing depends on any release blocker issues and availability to run the release build.
   • After the release all binaries are available and the documentation and the website are updated.
   • Finally the release is announced.