doc: formalize pull request review timelines

Describes a pull request process that prevents maintainers from
merging code too quickly, giving contributors a chance to react to
changes and voice concerns before a pull request is merged and
closed. This makes development more transparent and inclusive.

The process prescribes a lag time between maintainer approval and
merge of minimally 24 hours because that creates a workable
balance between maintaining development momentum and transparency.

Maintenance tasks are exempt from the lag time requirement, as are
time-critical fixes.
This commit is contained in:
Patrick Lodder 2022-05-13 17:49:59 +02:00
parent 4d837b2395
commit c52dd654c3
No known key found for this signature in database
GPG Key ID: 2D3A345B98D0DC1F

View File

@ -169,6 +169,25 @@ discussed extensively, be accompanied by widely discussed documentation and have
a generally widely perceived technical consensus of being a worthwhile change,
based on the judgement of the maintainers.
### Merging pull requests
Maintainers can only merge pull requests after any maintainer, other than the
author of a pull request, has approved the code according to the decision
making process outlined above.
Maintainers must keep pull requests open for at least 24 hours after approval
to merge is given, to allow anyone to voice a concern that may have been missed
in review, or request more time to investigate a suspected issue. If a situation
arises where more time has been requested but cannot be granted, at maintainer
discretion, a new issue or pull request should be opened to address the defect
or discuss improved alternatives. Requests for time and maintainer decision
making are expected to be clearly documented on the pull request discussion on
Github.
Maintenance tasks and time-critical patches can be exempted from this rule if
these are clearly marked as such, at maintainer discretion.
## Copyright
By contributing to this repository, you agree to license your work under the