Pull Request Policy - sympy/sympy GitHub Wiki

The following is a draft of the PR policy. Please give your suggestions at https://github.com/sympy/sympy/issues/17683 to improve it.

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

  1. The PR should be labelled with appropriate labels, for those with appropriate access(for example people with triage permissions).
  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 within two weeks of the last review comments then attach a Please take over label to that PR.
  4. If the PR is passing tests, there are no pending reviews and the commit history looks good then merge the PR, again only for those who have push access.

When to create a new PR?

A contributor should create a new pull request for open issues, not closed ones. However, if an issue has more than one associated open pull request, then the best one is kept opened and the rest are closed in its favor. 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. This includes appropriate new tests.
  • Coding Style - If the coding style follows that of the associated modules, then that PR will have higher chances of being kept opened.
  • Recency - The more recent the PR is, the better it is.

When to add Could Close to a PR?

If the reviewers determine that a pull request should not be merged in its current state, then they can either ask the maintainers to add a "Could Close" label to the PR or they can do so by themselves if they have the access. For closing PRs, the policy at https://github.com/sympy/sympy/wiki/Closing-pull-requests should be followed.

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 features which are already there in the master.
  6. Copied code without credits.