Development - Roles


Everyone is encouraged to participate in the Presto 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 Presto 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.


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 Presto better for everyone.

Expectations and duties:


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

Expectations and duties:


A reviewer reads a proposed change to Presto, and assesses how well the change aligns with the Presto 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 committer for that.

Expectations and duties:


In Presto, committership is an active job. A committer is responsible for checking in code only after ensuring it has been reviewed thoroughly and aligns with the Presto vision and guidelines. In addition to merging code, a committer actively participates in discussions and reviews. Being a committer 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 committer is expected to bring these to the project participants as needed to gain consensus. Committership is for an individual, so if a committer changes employers, the committership is retained. However, if a committer is no longer actively involved in the project, their committer status will be reviewed.

Expectations and duties:

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

Path to Becoming a Committer

  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 Presto.
  2. Contribute: This will help 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 Presto, start reviewing proposed changes to that part. A committer will do an additional final review, and this will help 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. Committer: 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 committers, since no one person is familiar with all of Presto. We are also looking for an understanding of the project values and technical vision. Being a committer means reviewing and merging code in your areas of expertise from all contributors. Committership is retained while being active in the project.