Pull Request Policy

The following should be done for any new Pull Request(PR) made to this repository,

1. The PR should be labelled with appropriate labels, can be done only by those who have write access.
2. Provide reviews - Make sure that the PR doesn't break any existing tests, coding style.
3. Wait period - Wait for the author to respond to the reviews. If they don't respond for continuously two weeks then attach a Please take over label to that PR.
4. If the PR is passing CI tests, the API reports are satisfactory and there are no pending reviews then merge the PR, again only for those who have write/triage permissions.

When to create a new PR?

A contributor can only create a new PR for an open issue, not closed ones. However, if an issue is having more than one open PRs, then the best one is kept opened and the rest are closed in its favour. The following are the criteria for determining the best PR,

• Activity - If the author of the PR is active in maintaining the PR then it will be kept above other PRs.
• Test Status - If the tests are passing for a PR then that PR will be considered better.
• Coding Style - If the coding style is along the lines of the current master, then that PR will have higher chances of being kept opened.
• Recency - The more recent the PR is, the better it is.

When to close a PR?

If the reviewers feel that a PR doesn't has any scope of improvements and couldn't be merged even after providing reviews then they can either ask the maintainers to close the PR or they can close such PRs themselves if they have the access to do so.

Some examples of the PRs that can be closed,

1. The code is in a language other than Python.
2. No reference to any issues or empty description in the PR.
3. Having things like driver code in the patch and looks like the contributor is spamming the pull request list.
4. Having irrelevant commits in the history from some other PR/branch.
5. Having data structure/algorithm which is already there in the master.