Presto SQL is now Trino Read why »

Development

Roles

Overview

Everyone is encouraged to participate in the Trino project. Anyone can influence the project by simply being involved in the discussions about new features, the roadmap, architecture, and even problems they are facing. The various roles described here do not carry more weight in these discussions, and instead we try to always work towards consensus. The Trino project has a strong vision and development philosophy which helps to guide discussions and normally allows us to reach consensus. When we can’t come to consensus, we work to figure out what we agree on, and what we don’t. Then we move forward by building what we agree on, which helps everyone better understand the parts we don’t agree on, and hopefully builds empathy at the same time.

The following describes the expectations and duties of the various roles.

Participants

This is the most important role. Very simply put, participants are those who show up and join in discussions about the project. Users, developers, and administrators can all be participants, as can literally anyone who has the time, energy, and passion to become involved. Participants suggest improvements and new features. They report bugs, regressions, performance issues, and so on. They work to make Trino better for everyone.

Expectations and duties:

  • Be involved in discussions about features, roadmaps, architecture, and long-term plans.
  • Help other users on the mailing list, on GitHub issues, and on Slack.
  • Propose and discuss new features and improvements.
  • Help raise the project’s quality bar.
  • Let everyone else know what isn’t working or is confusing.
  • Report bugs and performance regressions.
  • Suggest improvements to infrastructure and testing.
  • Recommend improvements to documentation and the website.
  • Understand that although English is the language of this project, English is not the first language of many participants. Assume positive intent from others and realize that negative sounding comments are often unintentional due to language barriers.

Contributors

A contributor submits changes to Trino. The full contribution process is described here.

Expectations and duties:

  • Be empathetic to the reviewers. Reviewing a change can be hard work and time consuming.
  • Keep commits small when possible and provide reasoning and context when submitting changes. Reviews go smoother if you make the reviewer’s job easier.
  • Be responsive when changes are requested by the reviewer. It is easier to re-review the modified changes if they are completed shortly after original review.
  • Ask for clarification if you are confused by a suggested change.
  • Speak up if your contribution appears to be stuck.
  • Read the project vision and development philosophy.
  • Follow the style guidelines and more importantly, follow the Trino coding conventions by matching your code to the existing code. Keep in mind the Trino development philosophy is to have all code appear as if it were written by a single person.
  • Sign the contributor license agreement (CLA).

Reviewers

A reviewer reads a proposed change to Trino, and assesses how well the change aligns with the Trino vision and guidelines. This includes everything from high level project vision to low level code style. Everyone is invited and encouraged to review others’ contributions – you don’t need to be a maintainer for that.

Expectations and duties:

  • Be empathetic to contributors. They may have put a lot of effort into the proposed change and may not be familiar with the codebase, the process, or the history of the project.
  • Be responsive to questions.
  • Re-review after suggested changes have been applied.
  • Be clear about which changes are only suggestions, and which changes are necessary.
  • Let the contributor know what is going on, so reviews don’t appear to be stuck.
  • Raise a discussion when a change does not seem to align with the vision or development philosophy.
  • Point out deviations from the code conventions and style guidelines.
  • Ask for help reviewing areas you don’t understand.

Maintainer

In Trino, maintainer is an active job. A maintainer is responsible for checking in code only after ensuring it has been reviewed thoroughly and aligns with the Trino vision and guidelines. In addition to merging code, a maintainer actively participates in discussions and reviews. Being a maintainer does not grant additional rights in the project to make changes, set direction, or anything else that does not align with the direction of the project. Instead, a maintainer is expected to bring these to the project participants as needed to gain consensus. The maintainer role is for an individual, so if a maintainer changes employers, the role is retained. However, if a maintainer is no longer actively involved in the project, their maintainer status will be reviewed.

Expectations and duties:

  • Be an active reviewer and participant.
  • Know which changes are likely to be controversial, and work to resolve the controversy as early as possible.
  • Know when a change needs more reviewers involved.
  • Ensure the review of a proposed change is thorough.
  • Point out when a contribution appears to be stuck.
  • Update release notes when committing changes.
  • Follow the CLA and IP policies.

An Apache Hive committer did an excellent write up on their process and much of this aligns with our philosophy on maintainers. Read about it.

Path to becoming a maintainer

  1. Read: Understand the project values and scope, the development philosophy and guidelines, and the change process. These contain necessary background information to be successful in Trino.
  2. Contribute: This helps you learn the codebase, and understand the development process. Start with something small to become familiar with the process.
  3. Review: Once you become familiar with a part of Trino, start reviewing proposed changes to that part. A maintainer does an additional final review, and this helps you understand what you are missing in your reviews. At some point, your first pass reviews will not require additional changes during the final review.
  4. Maintainer: The next step is to demonstrate an understanding of what you know and don’t know. It is common for changes to require reviews from multiple people, since no one person is familiar with all of Trino. We are also looking for an understanding of the project values and technical vision. Being a maintainer means reviewing and merging code in your areas of expertise from all contributors. The maintainer role is retained while being active in the project.