Status

Current state: Done

Discussion thread: N/A

JIRA: N/A

Released: N/A

Problem

Community have voted and decided to start using Github issues/pull requests for issue tracking for 3 months.
however, It needs some Github permissions and some simple/basic rules to follow.

Always create an issue for a pull request.
We can use Issue/Pull Request templates (https://github.com/blog/2111-issue-and-pull-request-template )to give user instructions on what should be described in issues and pull requests. Here are two attached templates.

Release - We can use “milestone” for managing releases.
We can start with minimal labels, iterate and add more if the labels are really needed.

Type/Kind: {bug, feature, task}.
Component/Area: {protocol, client, bookie, tests, documentation}.
Priority: {blocker}. If it is a blocker, mark it a blocker. Otherwise leaves it unmarked.

Ask INFRA if we have the permission to merge directly in Github.
If we have, enable “allow squash merging”, disable “allow merge commits” and “allow rebase merging” to make a clean commit history.
If we don’t have the permission, improving the merge-script to close both issue and PR.

Currently the script closes the PR using commit messages (https://help.github.com/articles/closing-issues-via-commit-messages/), we need to improve the script to be able to find its corresponding issue, if there is one.

Work Flow
- If a change is in-progress but you want an early feedback, you can send out a pull request with "WIP - Issue xxxx".
- If a change is done and you want to review, you can send out a pull request with "Issue xxxx".
- If people reviewed a pull request and the change needs to be improved, people should "request changes" through the github review button.
  - The merge script should only merge changes approved by committers and no pending 'request changes'.