Update pull request guidelines

This commit is contained in:
Hanno Braun 2022-03-09 14:02:40 +01:00
parent 0892626b29
commit adc1ed2822

View File

@ -70,9 +70,33 @@ Before starting to work on an issue, feel free to leave a message there first. M
### Pull Requests
- If your pull request is a work in progress, please submit it as a draft to make that clear. Once you believe it is ready to be reviewed, convert the draft into a pull request.
- Once your pull request has been reviewed, but not yet merged, please add any additional changes as new commits. This makes the review process much easier.
- If you're making changes before the pull request has been reviewed, for example in response to the CI build, feel free to modify the existing commits, if that makes things clearer.
#### Favor small, incremental changes
If a pull request gets too large or stays open for too long, it'll turn into a pain. Mostly for you, because you have to keep merging in the latest changes. But also for others, because once your pull request is merged, they'll have to deal with one big change at once, which is harder than dealing with multiple small changes over time.
If you can split a big change into a series of smaller, incremental changes, do so! If some of those smaller changes are self-contained, like cleanup work that's required to implement your main change for example, submit those as separate pull requests, to get them merged right away.
#### Don't be afraid to change existing code
Fornjot isn't the result of some stringent top-down design process. It grows and changes, based on evolving requirements. If you see something that doesn't seem to make sense, that's probably because it actually doesn't. Maybe it once did, but then things changed around it to create the current situation.
Never be afraid to change code like that! If something is in your way, don't think you have to work around it. Just change the existing code, until your change is easy.
If you're worried about making a mistake, feel free to just ask. But really, if you make a change that's wrong, and it doesn't trigger a failure in an automated test, *and* gets through review, then that's not your fault at all.
#### Pull request lifecycle
If your pull request is a work in progress, please submit it as a draft to make that clear. Once you believe it is ready to be reviewed, convert the draft into a pull request.
Once your pull request has been reviewed, but not yet merged, please add any additional changes as new commits. This makes the review process much easier. If you're making changes before the pull request has been reviewed, for example in response to the CI build, feel free to modify the existing commits, if that makes things clearer.
#### Dealing with changes
If the code you're modifying has changed in the `main` branch, favor `git rebase` over `git merge`, unless there's a good reason not to. `git rebase` will lead to a linear history that is easier to understand.
#### Miscellaneous
Don't worry about the changelog! It will get updates as part of the release procedure, so making changes there as part of your pull request is not necessary.
### Commits