From 736024afdb9b89006a006996e6ed62bccc338c11 Mon Sep 17 00:00:00 2001 From: Patrick Georgi Date: Sun, 17 May 2020 22:10:53 +0200 Subject: 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 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41493 Tested-by: build bot (Jenkins) Reviewed-by: Angel Pons Reviewed-by: Arthur Heymans Reviewed-by: Paul Menzel --- Documentation/getting_started/gerrit_guidelines.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') 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 ------------------------------------- -- cgit v1.2.3