From ae7656072a403f69607109d941aa0c4b6274f60c Mon Sep 17 00:00:00 2001 From: Linus Groh Date: Sat, 20 Nov 2021 22:42:31 +0000 Subject: [PATCH] Meta: Tighten rules around commit categories in CONTRIBUTING.md These are the rules we have implicitly used & preferred for a while. Document them explicitly. --- CONTRIBUTING.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b4d7fda48f3..8f8c3ab741b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -45,7 +45,11 @@ Nobody is perfect, and sometimes we mess things up. That said, here are some goo * Split your changes into separate, atomic commits (i.e. A commit per feature or fix, where the build, tests and the system are all functioning). * Make sure your commits are rebased on the master branch. * Wrap your commit messages at 72 characters. -* The first line of the commit message is the subject line, and should have the format "Category: Brief description of what's being changed". The "category" can be a subdirectory, but also something like "POSIX compliance" or "ClassName". Whatever seems logical. +* The first line of the commit message is the subject line, and must have the format "Category: Brief description of what's being changed". The category should be the name of a library, application, service, utility, etc. + * Examples: `LibAudio`, `HackStudio`, `Base`, `Kernel`, `ConfigServer`, `cat` + * Don't use a category like "`Userland`" or "`Utilities`", except for generic changes that affect a large portion of code within these directories. + * Don't use specific component names, e.g. C++ class names, as the category either - mention them in the summary instead. E.g. `LibGUI: Brief description of what's being changed in FooWidget` rather than `FooWidget: Brief description of what's being changed` + * Several categories may be combined with `+`, e.g. `LibJS+LibWeb+Browser: ...` * Write the commit message subject line in the imperative mood ("Foo: Change the way dates work", not "Foo: Changed the way dates work"). * Write your commit messages in proper English, with care and punctuation. * Squash your commits when making revisions after a patch review.