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 TVM Community Guidelines 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. The Apache way of development requires 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 discuss 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 thread).

Independent Project Management

Everyone is presumed to be wearing their Apache committer hat when participating in the project. That is, committers should act - in the context of the project activities - in the best interests of the project. Separating your hat between committer and any other roles you may have is important in all aspects.

In the context of project participation, it can be helpful to state which hat you are wearing in cases where that can cause confusion, especially in cases where you are not wearing committer hat. Two examples:

  • “Wearing [foo] hat: [message when serving as foo’s role and not as committer]”.

  • “Wearing Apache TVM hat: [messages when serving as committer]”.

Shepherd a Pull Request

Here are some tips to shepherd a pull request. You can also take a look at the Code Reviews.

  • 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 an RFC needs to be sent.

  • 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 :)

Broad Collaboration

Sometimes, we tend to only interact with people we know. However, broad collaborations are necessary to the success of the project. Try to keep that in mind, shepherd PRs for, and request code reviews from community members who you do not interact physically.