diff options
author | Riku Isokoski <riksu9000@gmail.com> | 2023-01-05 13:59:44 +0200 |
---|---|---|
committer | Riku Isokoski <riksu9000@gmail.com> | 2023-01-22 09:00:14 +0200 |
commit | ee8349a6767da9b7198a3563b6252a93537524a3 (patch) | |
tree | 793c17c06a1072840b41672f060a702094f6e247 | |
parent | 2692231b951ccdc7ece23e21394c3c1c88dd613b (diff) |
doc: Add maintainer guide
-rw-r--r-- | README.md | 1 | ||||
-rw-r--r-- | doc/maintainer-guide.md | 45 |
2 files changed, 46 insertions, 0 deletions
@@ -34,6 +34,7 @@ Fast open-source firmware for the [PineTime smartwatch](https://www.pine64.org/p - [Versioning](doc/versioning.md) - [Project branches](doc/branches.md) - [Files included in the release notes](doc/filesInReleaseNotes.md) +- [Maintainer's guide](doc/maintainer-guide.md) ### Contributing diff --git a/doc/maintainer-guide.md b/doc/maintainer-guide.md new file mode 100644 index 00000000..ba95eb83 --- /dev/null +++ b/doc/maintainer-guide.md @@ -0,0 +1,45 @@ +# Reviewing PRs + +Approving a PR means that the reviewer has deemed the PR ready to be merged. + +There are two steps to reviewing PRs. + +- Review the feature: + + - Consider if the feature aligns with the [InfiniTime vision](InfiniTimeVision.md) + - Discuss alternative ideas or implementations + +- Review the code: + + - Check the quality of the code and make sure it conforms to the [coding conventions](coding-convention.md) + - Consider the maintainability of the code + - Test the code with at least InfiniSim or a PineTime + +# Merging PRs + +Two approvals from core developers is usually required to merge a PR. +Exceptions include urgent fixes +and small maintenance PRs by core developers, +that don't affect the apparent behaviour of the watch in any way. + +All but the simulator check must be passed before merging a PR. + +PRs are either rebase or squash merged, +depending on whether the commits satisfy the following requirements: + +### Commits + +- Commits that fix mistakes from previous commits must be squashed before merging a PR. +- The title and description of the commit must sufficiently explain the changes in the commit. + +If these requirements are not met, +the PR must be squash merged, +and the merger must write a satisfactory description. + +# Stale PRs + +Work-in-Progress PRs shall be marked as draft. + +Draft PRs with no activity by the author for 3 months may be closed as stale. + +PRs with changes requested, but no activity by the author for 3 months may be closed as stale. |