clarify merging PRs for people with write access

Slightly rephrase the section about pull requests to clarify that
a pull request can be merged either by the reviewer or the author
(if they have push access) if they are satisfied with the feedback.

Also discussed on IRC, e.g.:
[2022-09-03 21:53:20Z] <toast> I think "whenever any reviewer feels comfortable with it, or the submitter thinks the given feedback is sufficient"
This commit is contained in:
Johann150 2022-09-04 01:25:39 +02:00
parent 30495ef8da
commit 4d7f1b0374
Signed by untrusted user: Johann150
GPG key ID: 9EE6577A2A06F8F1

View file

@ -28,7 +28,7 @@ For a production environment you might not want to follow the `main` branch dire
## Considerations to be made for all contributions ## Considerations to be made for all contributions
This project follows [Semantic Versioning 2.0.0](https://semver.org/spec/v2.0.0.html). This project follows [Semantic Versioning 2.0.0](https://semver.org/spec/v2.0.0.html).
Significant changes should be listed in the changelog (i.e. the file called `CHANGELOG.md`). Significant changes should be listed in the changelog (i.e. the file called `CHANGELOG.md`, see also section "Changelog Trailer" below).
Although Semantic Versioning talks about "the API", changes to the user interface should also be tracked. Although Semantic Versioning talks about "the API", changes to the user interface should also be tracked.
Consider if any of the existing documentation has to be updated because of your contribution. Consider if any of the existing documentation has to be updated because of your contribution.
@ -50,21 +50,27 @@ Some more points you might want to consider are:
## Code contributions ## Code contributions
There are two ways you can contribute: There are different "rules" of how you can contribute, depending on your access privileges to the repository.
If you **have push access** to this repository, you can push stuff directly. ### Without push access
But y'know, "with great power comes great responsibility" and so on.
We most likely will not kick you out if you made a mistake, it happens to the best.
But this of course means that the erroneous contributions may be either fixed or undone.
Even if you have push access but are trying to make larger or sweeping changes, please consider also using the following way of contibuting. If you do not have push access, you have to create a pull request to get your changes into Foundkey.
If you do **not have push access** you can create a pull request.
Someone with push access should review your contribution. Someone with push access should review your contribution.
If they are satisfied that what you are doing seems like a good idea and the considerations from the section above are fulfilled, they can merge your pull request. If they are satisfied that what you are doing seems like a good idea and the considerations from the section above are fulfilled, they can merge your pull request.
Or, they might request another member to also review your changes. Or, they might request another member to also review your changes.
Please be patient as nobody is getting paid to do this, so it might take a bit longer. Please be patient as nobody is getting paid to do this, so it might take a bit longer.
### With push access
You can push stuff directly to any branch.
But y'know, "with great power comes great responsibility" and so on, be sensible.
We most likely will not kick you out if you made a mistake, it happens to the best.
But this of course means that the erroneous contributions may be either fixed or undone.
Alternatively, you can also proceed as for "without push access" above.
In this case it will be assumed that you wish for a review of the changes you want to make.
Instead of having someone else merge the pull request when they have approved your changes, you can also merge yourself if you think the given feedback is sufficient.
### Changelog Trailer ### Changelog Trailer
To keep track of changes that should go into the CHANGELOG, we use a standard [trailer](https://git-scm.com/docs/git-interpret-trailers). To keep track of changes that should go into the CHANGELOG, we use a standard [trailer](https://git-scm.com/docs/git-interpret-trailers).