diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index f426017b4..9bd11d95c 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -1,6 +1,6 @@ # Summary of changes + - [ ] 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: + + - [ ] 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. diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index f900dcb49..dfbb00e1d 100644 --- a/docs/CONTRIBUTING.md +++ b/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. diff --git a/docs/developers.rst b/docs/developers.rst index 9d74df2f2..43e88385b 100644 --- a/docs/developers.rst +++ b/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,11 +52,11 @@ 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 @@ -59,7 +64,7 @@ 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.