contributing: review rules for bugs

Half of the ideas came from Daniel but most of them are reworded, the
rest are my thoughts.

Mention compiler warnings specifically, and be more explicit on what
kind of code or bugs or bug fixes are acceptable or not. Clarify commit
scope.

v2: move the "In a patch series" rule to the bottom, reworded.

Cc: Daniel Stone <daniels@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Derek Foreman <derek.foreman.samsung@gmail.com>

CONTRIBUTING.md

@@ -228,11 +228,21 @@ include tests excercising the additions in the test suite.
 - The code fits the existing software architecture, e.g. no layering
 violations.
 
-- The code is correct and does not ignore corner-cases.
+- The code is correct and does not introduce new failures for existing users,
+does not add new corner-case bugs, and does not introduce new compiler
+warnings.
 
-- In a patch series, every intermediate step produces correct code as well.
+- The patch does what it says in the commit message and changes nothing else.
 
-- The code does what it says in the commit message and changes nothing else.
+- The patch is a single logical change. If the commit message addresses
+multiple points, it is a hint that the commit might need splitting up.
+
+- A bug fix should target the underlying root cause instead of hiding symptoms.
+If a complete fix is not practical, partial fixes are acceptable if they come
+with code comments and filed Gitlab issues for the remaining bugs.
+
+- The bug root cause rule applies to external software components as well, e.g.
+do not work around kernel driver issues in userspace.
 
 - The test suite passes.
 
@@ -250,6 +260,8 @@ clarity suffers.
 
 - The code adheres to the style guidelines.
 
+- In a patch series, every intermediate step adheres to the above guidelines.
+
 
 Commit rights
 =============