Patrick Georgi has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/41493 )
Change subject: Documentation: Encourage documentation with code changes ......................................................................
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 --- M Documentation/getting_started/gerrit_guidelines.md 1 file changed, 17 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/93/41493/1
diff --git a/Documentation/getting_started/gerrit_guidelines.md b/Documentation/getting_started/gerrit_guidelines.md index 735ba3b..7b0c247 100644 --- a/Documentation/getting_started/gerrit_guidelines.md +++ b/Documentation/getting_started/gerrit_guidelines.md @@ -254,6 +254,23 @@ 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 +(coreboot@coreboot.org). 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 -------------------------------------