Triaging Issues

Issue tracker doubles as the message board. Therefore, it can have two types of issues:

  • Change Requests: Regular issues requiring changes to the software. e.g. bug reports, feature requests

  • Misc. Posts: i.e. all other issues announcements, questions, support requests from contributors, self-intros etc.

When an issue comes in,

  • any one can respond to it. Faster responses are an indicator of project health.

  • any one with sufficient privileges can add labels based on the project’s definition of each label.

    • However, Project Manager (PM) should be the one applying the priority (i.e. p.) label for change requests (misc. posts do not need priority labels). This is to ensure that all issues get prioritized using a uniform scale.

Requesting reviews for PRs

  • A PR should have 1 or more reviewers. See Reviewing PRs. The assignees field can be left empty.

  • PRs created by core members:

    • Author may request a review from a core member. Else, team lead will assign reviewers for the PR.

      Tip

      GitHub’s blame feature (or a third-party service such as mentionbot) can help to find suitable reviewers.

      Currently active developers who have touched the same code before and leads of the areas touched by the PR are potential reviewers.

  • PRs created by non-core members:

    • Team lead should request reviews based on the members' areas of expertise.

    • Core members can volunteer as reviewers by requesting a review from self.

  • After a PR has been approved by all reviewers, the last reviewer to approve should request a review from the PM.

  • After the PM has approved the PR, it can be merged. See Merging PRs.