RFC: Formalize our commit style to mention that we don't use conventi…

…onal commits.

It's the simple _when in Rome, do as the Romans do_ rule.

docs/contributing.md

@@ -36,9 +36,17 @@ commit and the new feature in a different commit. If the refactoring itself
 consists of many parts, try to separate out those into separate commits. You can
 use `jj split` to do it if you didn't realize ahead of time how it should be
 split up. Include tests and documentation in the same commit as the code they
-test and document. The commit message should describe the changes in the commit;
+test and document. 
+
+The commit message should describe the changes in the commit;
 the PR description can even be empty, but feel free to include a personal
-message.
+message. We write commit messages in an affected component style and don't use 
+[conventional commits](www.conventionalcommits.org/en/v1.0.0/). This means if 
+you modified a command in the CLI, use its name as the topic, e.g 
+`next/prev: <your-modification>` or `conflicts: <your-modification>`. We don't
+currently have a specific guidelines on what to write in the topic field, but 
+the reviewers will help you provide a topic if you have difficulties choosing 
+it.
 
 When you address comments on a PR, don't make the changes in a commit on top (as
 is typical on GitHub). Instead, please make the changes in the appropriate