From 9cd0a7516c7885b248560359eedc4d3fc6495753 Mon Sep 17 00:00:00 2001 From: Karl Fogel <kfogel@red-bean.com> Date: Mon, 24 Apr 2023 11:23:24 -0500 Subject: [PATCH] Give more explanation in the "Obvious Fix" rule --- CONTRIBUTING.md | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 3b2d6ad..0341609 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -129,15 +129,24 @@ include things like fixes for obvious typos (e.g., a misspelling in a comment or in a user-visible string), source code formatting changes (e.g., removing trailing whitespace from lines in preparation for a substantive change to follow, as per the ["keep unrelated changes -separate"](#keep-unrelated-changes-separate) rule), etc. You may use -your judgement about what constitutes a trivial change. After all, -everything is under version control, so if someone makes a mistake, or -there is disagreement about the effects of the change, then we can -roll back and discuss. +separate"](#keep-unrelated-changes-separate) rule), etc. + +The purpose of this exception is to avoid paying the costs of the +review process in situations where it's unlikely to bring benefits. +Going through review is good for quality, but it reduces velocity and +increases the state-maintenance burden for contributors -- an unlanded +change takes up space in people's minds as well as on MR lists. For +most changes, that cost is worth paying, but not for all. + +You may use your judgement about what constitutes a trivial change. +Everything is under version control, so if someone makes a mistake, or +there is disagreement about the effects of the change, then the group +can roll back and discuss. Note that individual projects may use stricter review guidelines, if -the development team wants to. Specifically, some projects don't make -the "obvious fix" exception: everything goes through pre-merge review. +the development team chooses to. Specifically, some projects don't +make the "obvious fix" exception, and prefer instead that everything +go through pre-merge review. ## No surprise rebasing -- GitLab