From 91f26ff45344cf30a85ee9491506b27cd265db2b Mon Sep 17 00:00:00 2001 From: Miklos Vajna Date: Thu, 7 Sep 2023 11:50:39 +0200 Subject: [PATCH] Contriburing instructions: add a section on commit messages It happens in many cases that it's not clear what are the steps to reproduce the problem to be fixed, let's have some explicit instructions on how to document these + the reasons for having these rules. Signed-off-by: Miklos Vajna Change-Id: I725f78dabd388fa85db0286e354527fd96e6d6be --- README.CONTRIBUTING.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/README.CONTRIBUTING.md b/README.CONTRIBUTING.md index d38bca1da7..761451ca46 100644 --- a/README.CONTRIBUTING.md +++ b/README.CONTRIBUTING.md @@ -34,3 +34,33 @@ Signed-off-by: Random J Developer using your real name and the email address (sorry, no pseudonyms or anonymous contributions.) + +## Other information to put into your commit message + +When reviewing a patch, we look for the following information in the commit message: + +- Title: a single line, short and to the point summary of what the patch does. + + - The reason is to be able to do `git log --pretty=oneline` and have a usable result. + +- Intro: observation of the current state + + - Rationale: the problem to be solved is obvious to you, but not to the reviewer. It's good to + have a list of steps to reproduce the problem. + +- Problem description: pros and cons of the current state + + - Rationale: when some feature doesn't work the way expected, frequently there is some other + use-case that motivated the current behavior. It's easier to not break the old use-case with + your change if you're aware of the old use-case. + + - If there was an old use-case and you found it by research, please document it, so the person + reading the commit message finds it easily. + +- Solution: give orders to the codebase + + - A short description of how you introduce new behavior while not breaking old behavior is useful, + because it may not be too obvious just by looking at what you changed. + +An alternative is to have much of this information in a (public) issue, refer to that issue and have +a short commit message. That works better e.g. when using images to demonstrate the problem.