docs: recommend making an issue before making an enhancement (#2391)

Suggest that contributors first make an issue to get in principle
agreement for pull requests before making the pull request.

Enhancements can be controversial, and we may reject the enhancement
sometimes, even if the code is good, as it may just not be deemed
important enough to increase the maintenance burden of RDFLib.

Other changes:
- Updated the checklist in the pull request template to be more accurate to
  current practice.
- Improved grammar and writing in the pull request template, contribution guide
  and developers guide.

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,6 +1,6 @@
 <!--
 Thank you for your contribution to this project. This project has no formal
-funding or full-time maintainers and relies entirely on independent
+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
@@ -15,23 +15,25 @@ and ask.
 More detailed guidelines for pull requests are provided in our [developers
 guide](https://github.com/RDFLib/rdflib/blob/main/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 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.
+PRs should be reviewed and approved by at least two people other than the author
+using GitHub's review system before being merged. This is less important for bug
+fixes and changes that don't impact runtime behaviour, but more important for
+changes that expand the RDFLib public API. 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
+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
@@ -49,13 +51,17 @@ 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:
+- If the change adds new features or changes the RDFLib public API:
+  <!-- This can be removed if no new features are added and the RDFLib public API is
+  not changed. -->
+  - [ ] Created an issue to discuss the change and get in-principle agreement.
+  - [ ] Considered adding an example in `./examples`.
+- If the change has a potential impact on users of this project:
+  <!-- This can be removed if the changed does affect users of this project. -->
+  - [ ] Added or updated tests that fail without the change.
   - [ ] 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/CONTRIBUTING.md

@@ -1,8 +1,8 @@
 # RDFLib Contributing Guide
 
 Thank you for considering contributing to RDFLib. This project has no formal
-funding or full-time maintainers and relies entirely on independent contributors
-to keep it alive and relevant.
+funding or full-time maintainers, and relies entirely on independent
+contributors to keep it alive and relevant.
 
 ## Ways to contribute
 
@@ -47,6 +47,12 @@ Some ways in which you can contribute to RDFLib are:
 Contributions that involve changes to the RDFLib repository have to be made with
 pull requests and should follow the [RDFLib developers guide](./developers.rst).
 
+For changes that add features or affect the public API of RDFLib, it is
+recommended to first open an issue to discuss the change before starting to work
+on it. That way you can get feedback on the design of the feature before
+spending time on it.
+
 ## Code of Conduct
 
-All contributions to the project should be consistent with the [code of conduct](./CODE_OF_CONDUCT.md) adopted by RDFLib.
+All contributions to the project should be consistent with the [code of
+conduct](./CODE_OF_CONDUCT.md) adopted by RDFLib.

docs/developers.rst

@@ -23,6 +23,11 @@ Pull Requests Guidelines
 
 Contributions to RDFLib are made through pull requests (PRs).
 
+For changes that add features or affect the public API of RDFLib, it
+is recommended to first open an issue to discuss the change before starting to
+work on it. That way you can get feedback on the design of the feature before
+spending time on it.
+
 In general, maintainers will only merge PRs if the following conditions are
 met:
 
@@ -47,19 +52,19 @@ met:
   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
+be processed quicker. The primary factors that determine this are 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.
+is thus important to try to 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 ``main`` 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
+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.