Committer Guide

This is an evolving document to provide some helpful tips for committers. Most of them are lessons learned during development. We welcome every committer to contribute to this document. See the TiDB Community Guideline for an overview of the committership and the general development process.

Community First

The collective effort of the community moves the project forward and makes the project awesome for everyone. When we make a decision, it is always helpful to keep the community in mind. Here are some example questions that we can ask:

  • How can I encourage new contributors to get more involved in the project?
  • Can I help to save my fellow committers' time?
  • Have I enabled the rest of the community to participate the design proposals?

Public Archive Principle

While private channels such as face to face discussion are useful for development, they also create barriers for the broader community's participation. An open way of development suggests all decisions to be made in public channels, which are archived and accessible to everyone. As a result, any contributor can keep up with the development by watching the archives and join the development anytime.

While this principle applies to every contributor, it is especially important for committers. Here are some example applications of this principle:

  • When getting a project-related question from a personal channel, encourage the person to open a public thread in the TiDB Internals forum, so others in the community can benefit from the answer.
  • After an in-person discussion, send a summary to public channels (as an RFC or a discuss topic).

Shepherd a Pull Request

Here are some tips to shepherd a pull request. You can also take a look at Review a Pull Request.

  • Assign the PR to yourself, so that other committers know that the PR has already been tended to.
  • Make use of the status label to indicate the current status.
  • Check if a design document needs to be present.
  • If the contributor has not requested a reviewer, kindly ask the contributor to do so. If the PR comes from a new contributor, help the contributor to request reviewers and ask the contributor to do so next time.
  • Moderate the reviews, ask reviewers to approve explicitly.
  • Mark the PR as accepted and acknowledge the contributor/reviewers.
  • Merge the PR :)

Time Management

There are many things that a committer can do, such as moderating discussions, pull request reviews and code contributions.

Working on an open source project can be rewarding, but also be a bit overwhelming sometimes. A little bit of time management might be helpful to alleviate the problem. For example, some committers have a "community day" in a week when they actively manage outstanding PRs, but watch the community less frequently in the rest of the time.

Remember that your merit will never go away, so please take your time and pace when contributing to the project:)