Merge pull request RDFLib#1767 from aucampia/iwana-20220315T2240-pr_g…

…uidelines

Add pull request guidelines and template.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,61 @@
+<!--
+Thank you for your contribution to this project. This project has no formal
+funding or full-time maintainers and relies entirely on independent
+contributors to keep it alive and relevant.
+
+This pull request template includes some guidelines intended to help
+contributors, not to deter contributions. While we prefer that PRs follow our
+guidelines, we will not reject PRs solely on the basis that they do not, though
+we may take longer to process them as in most cases the remaining work will
+have to be done by someone else.
+
+If you have any questions regarding our guidelines, submit the PR as is
+and ask.
+
+More detailed guidelines for pull requests are provided in our [developers
+guide](https://github.com/RDFLib/rdflib/blob/master/docs/developers.rst).
+
+As a reminder, PRs that are smaller in size and scope will be reviewed and
+merged quicker, so please consider if your PR could be split up into more than
+one independent part before submitting it, no PR is too small. The maintainers
+of this project may also split up larger PRs into smaller more manageable PRs
+if they deem it necessary.
+
+PRs should be reviewed and approved by at least two people other than the
+author using GitHub's review system before being merged. Reviews are open to
+anyone, so please consider reviewing other open pull requests as this will also
+free up the capacity required for your PR to be reviewed.
+-->
+
+# Summary of changes
+
+<!--
+Briefly explain what changes the pull request is making and why. Ideally this
+should cover all changes in the pull request as the changes will be reviewed
+against this summary to ensure that the PR does not include unintended changes.
+
+Please also explicitly state if the PR makes any changes that are not backwards
+compatible.
+-->
+
+# Checklist
+
+<!--
+If an item on this list doesn't apply to your pull request, just remove it.
+
+If, for some reason, you can't check some items on the checklist, or you are
+unsure about them, submit your PR as is and ask for help.
+-->
+
+- [ ] Checked that there aren't other open pull requests for
+  the same change.
+- [ ] Added tests for any changes that have a runtime impact.
+- [ ] Checked that all tests and type checking passes.
+- For changes that have a potential impact on users of this project:
+  - [ ] Updated relevant documentation to avoid inaccuracies.
+  - [ ] Considered adding additional documentation.
+  - [ ] Considered adding an example in `./examples` for new features.
+  - [ ] Considered updating our changelog (`CHANGELOG.md`).
+- [ ] Considered granting [push permissions to the PR branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork),
+  so maintainers can fix minor issues and keep your PR up to date.
+

docs/developers.rst

@@ -13,10 +13,60 @@ developing RDFLib code.
 * Code should be formatted using `black <https://github.com/psf/black>`_  and we use Black v22.1.0, with the black config in ``pyproject.toml``.
 * Code should also pass `flake8 <https://github.com/psf/black>`_ linting
   and `mypy <http://mypy-lang.org/>`_ type checking.
-* You must supply tests for new code
+* You must supply tests for new code.
 
 If you add a new cool feature, consider also adding an example in ``./examples``
 
+Pull Requests Guidelines
+------------------------
+
+Contributions to RDFLib are made through pull requests (PRs).
+
+In general, maintainers will only merge PRs if the following conditions are
+met:
+
+* The PR has been sufficiently reviewed.
+
+  Each PR should be reviewed and approved by at least two people other than the
+  author of the PR before it is merged and PRs will be processed faster if
+  they are easier to review and approve of.
+
+  Reviews are open to everyone, but the weight assigned to any particular
+  review is at the discretion of maintainers.
+
+* Changes that have a runtime impact are covered by unit tests.
+
+  There should either be existing tests that cover the changed code and
+  behaviour, or the PR should include tests. For more information about what is
+  considered adequate testing see the :ref:`Tests section <Tests>`.
+
+* Documentation that covers something that changed has been updated.
+
+* Type checks and unit tests that are part of our continuous integration
+  workflow pass.
+
+In addition to these conditions, PRs that are easier to review and approve will
+be processed quicker. The primary factors that determine this is the scope and
+size of a PR. If there are few changes and the scope is limited then there is
+less that a reviewer has to understand and less that they can disagree with. It
+is thus important to try and split up your changes into multiple independent
+PRs if possible. No PR is too small.
+
+For PRs that introduce breaking changes, it is even more critical that they are
+limited in size and scope, as they will likely have to be kept up to date with
+the master branch of this project for some time before they are merged.
+
+It is also critical that your PR is understandable both in what it does and why
+it does it, and how the change will impact the users of this project, for this
+reason it is essential that your PR's description explains the nature of the
+PR, what the PR intends to do, why this is desirable, and how this will affect
+the users of this project.
+
+Please note that while we would like all PRs to follow the guidelines given
+here, we will not reject a PR just because it does not.
+
+.. Tests:
+
 Tests
 -----
 Any new functionality being added to RDFLib _must_ have unit tests and