Documentation: Encourage documentation with code changes

The resource allocator woes post-4.12 release showed room for
improvement on both discussion and documentation.  To encourage this
(and encourage reviewers to look out for issues in that space),
extend the review guidelines so that they encourage to more clearly
document the reason for a change with the change (commit message or
our documentation) and also to loop in the mailing list.

Change-Id: I1962dba3fe7e1a01fa4c8b0058297c7d050cb7b7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41493
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>

1 files changed, 17 insertions, 0 deletions

diff --git a/Documentation/getting_started/gerrit_guidelines.md b/Documentation/getting_started/gerrit_guidelines.md
index 735ba3ba3d..59f675a2ff 100644
--- a/Documentation/getting_started/gerrit_guidelines.md
+++ b/Documentation/getting_started/gerrit_guidelines.md
@@ -254,6 +254,23 @@ commit message itself:
 The script 'util/gitconfig/rebase.sh' can be used to help automate this.
 Other tags such as 'Commit-Queue' can simply be removed.
 
+* Check if there's documentation that needs to be updated to remain current
+after your change. If there's no documentation for the part of coreboot
+you're working on, consider adding some.
+
+* When contributing a significant change to core parts of the code base (such
+as the boot state machine or the resource allocator), or when introducing
+a new way of doing something that you think is worthwhile to apply across
+the tree (e.g. board variants), please bring up your design on the [mailing
+list](../community/forums.md). When changing behavior substantially, an
+explanation of what changes and why may be useful to have, either in the
+commit message or, if the discussion of the subject matter needs way more
+space, in the documentation. Since "what we did in the past and why it isn't
+appropriate anymore" isn't the most useful reading several years down the road,
+such a description could be put into the release notes for the next version
+(that you can find in Documentation/releases/) where it will inform people
+now without cluttering up the regular documentation, and also gives a nice
+shout-out to your contribution by the next release.
 
 Expectations contributors should have
 -------------------------------------