diff options
author | Zeger-Jan van de Weg <git@zjvandeweg.nl> | 2019-02-13 14:10:29 +0300 |
---|---|---|
committer | Zeger-Jan van de Weg <git@zjvandeweg.nl> | 2019-02-13 15:07:09 +0300 |
commit | 341556816c37b996dac1f7b343224e6fb4a6b8a9 (patch) | |
tree | e923b393125425e70742133fe93161a1f30272a9 /doc/development | |
parent | a772e01051a07ce6f4b539b603b542bc23daad62 (diff) |
Add a soft SLA for reviewers and maintainers
By setting expectations both the contributor and reviewer have more
certainty on what gets reviewed when, and at what speed changes could be
merged.
Diffstat (limited to 'doc/development')
-rw-r--r-- | doc/development/code_review.md | 7 |
1 files changed, 7 insertions, 0 deletions
diff --git a/doc/development/code_review.md b/doc/development/code_review.md index 25ea2211b64..f45de25aee5 100644 --- a/doc/development/code_review.md +++ b/doc/development/code_review.md @@ -132,6 +132,13 @@ If a developer who happens to also be a maintainer was involved in a merge reque as a domain expert and/or reviewer, it is recommended that they are not also picked as the maintainer to ultimately approve and merge it. +Try to review in a timely manner; doing so allows everyone involved in the merge +request to iterate faster as the context is fresh in memory. Further, this +improves contributors' experiences significantly. Provided full availability; +reviewing within two work days should be the aim. If you don't think you'll be +able to review a merge request within that time, let the author know as soon as +possible. + Maintainers should check before merging if the merge request is approved by the required approvers. |