doc: refactor CONTRIBUTING.md to read more easily

1 files changed, 21 insertions, 24 deletions

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index aad46b1..a7982e8 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -50,31 +50,28 @@ Debian, other Linux distributions, other Unix variants, other
 operating systems) and architecture, but do not currently have the
 ability to test that. (Help would be welcome.)
 
-**Keep commits in a merge request small, related, and integral:** It's
-easier for us to review a small change than a large one, unless the
-changes are highly mechanical. For example, if you rename a function, a
-commit that does that and nothing else can be quite large, but is easy
-to review. If the same commit does other things as well, such as
-adding a new argument to the function, it becomes harder to review.
-Such a change should be split into different commits: one renames the
-function, the other adds the new argument.
+**Keep commits small:** It's easier for us to review smaller commits,
+less than about 200 lines of diff, except when each hunk is similar.
+For example, if you rename a function, a commit that does that and
+nothing else can be quite large, but is easy to review.
 
-Please also keep different commits in the same merge request related
-to each other. If you are adding a new feature to do foo and notice a
-bug in old feature bar, submit foo and the bug fix as separate merge
-requests. This allows us to consider the bug fix independently.
+**Keep commits integral:** Each commit should be a cohesive change,
+not a mix of unrelated changes. If a commit renames a function, it
+shouldn't also add a new argument to the function or make other
+changes unrelated to the rename.
 
-* Try to keep individual commits at 200 lines or less of unified diff
-  patch, unless each "hunk" of the patch is basically identical.
+**Keep commits in a merge request related:** If a commit adds a new
+feature, it shouldn't also fix a bug in an old feature. If there's a
+need to re-do the new feature, the bug fix will take longer to get
+merged. 
 
-* Each commit should be a cohesive, integral change, and not a mix of
-  unrelated changes.
+**Tell a story with a merge request:** The commits in a merge request
+should be arranged in a way that make the change as a whole easy to
+follow: they "tell a story" of how you would make the set of changes
+the second time, knowing everything you know after doing them the
+first time.
 
-* Each merge request should consists of related changes, arranged in a
-  way that make the change easy to follow: they "tell a story" of how
-  you would make the set of changes the second time, knowing
-  everything you know after doing them the first time. 
-  
-  The goal is not to show the path you originally took, but show how
-  to get there in the best possible way. You should tell the story of
-  flying by plane, not how you invented flying machines.
+The goal is not to show the path you originally took, but show how to
+get there in the best possible way. You should tell the story of
+flying by plane to get somewhere, not how you explored the world and
+eventually invented flying machines to travel faster.