[DOCS][COMMUNITY] Committer guide and tips

docs/contribute/code_review.rst

@@ -1,3 +1,5 @@
+.. _code_review_guide:
+
 Perform Code Reviews
 ====================
 

docs/contribute/committer_guide.rst

@@ -0,0 +1,86 @@
+.. _committer_guide:
+
+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 :ref:`community_guide` 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).
+
+
+Shepherd a Pull Request
+----------------------
+
+Here are some tips to shepherd a pull request.
+You can also take a look at the :ref:`code_review_guide`.
+
+- 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.

docs/contribute/community.rst

@@ -1,9 +1,12 @@
+.. _community_guide:
+
 TVM Community Guideline
 =======================
 
 TVM adopts the Apache style model and governs by merit. We believe that it is important to create an inclusive community where everyone can use, contribute to, and influence the direction of the project. See `CONTRIBUTORS.md <https://github.com/dmlc/tvm/blob/master/CONTRIBUTORS.md>`_ for the current list of contributors.
 
 
+
 General Development Process
 ---------------------------
 Everyone in the community is welcomed to send patches, documents, and propose new directions to the project. The key guideline here is to enable everyone in the community to get involved and participate the decision and development.  When major changes are proposed, an RFC should be sent to allow discussion by the community. We encourage public discussion, archivable channels such as issues, discuss forum and mailing-list, so that everyone in the community can participate and review the process later.

docs/contribute/index.rst

@@ -25,6 +25,7 @@ Here are guidelines for contributing to various aspect of the project:
 
    community
    code_review
+   committer_guide
    document
    code_guide
    pull_request