Use of the "Conventional Commit" standard for project commits

[ThibFrgsGmz]

F´ Version	latest
Affected Component

---

Feature Description

Adding the Conventional Commit standard to all commits made to the project will allow for better readability and understanding of the changes made to the code.

Commits should be formatted as follows: <type>(<scope>): <subject>.

For example: feat(module): added trajectory calculation functionality or fix(module): fixed a bug in satellite communication management.

To help the adoption of this standard, a series of steps can be implemented:

• Setting up a pre-commit tool to check that contributors comply with the standard before they can commit.
• Add a section in the project documentation explaining the standard and the types of commits expected.
• Organize a training session for team members to help them understand the usefulness of the standard and how to use it.

Using the Conventional Commit standard, it is also possible to automatically generate detailed changelogs using tools such as conventional-changelog or commitlint-config-conventional.
This makes it easier for end users and contributors to write release notes, providing a clear overview of the changes made to the project.

Rationale

The "Conventional Commit" standard has become an industry standard for software commits. It allows :

• a better understanding of the modifications made to the code by specifying the type of commit (new functionality, bug fix, documentation, ...)
• a better traceability by allowing to follow the history of the commits and to understand the motivations behind the modifications.
• a better collaboration between team members by allowing to quickly understand the modifications made by the different contributors.

Automatic generation of detailed changelogs to facilitate communication of changes to the project.

The implementation of this standard can however take some time and may seem restrictive for contributors in the short term, but in the long term it brings gains in productivity, quality and maintainability that are worth the effort.

[astroesteban]

I like this standard but I would suggest we select a subset of the possible scopes (feat, fix, docs, etc). Just to make things simpler for contributors maybe we use only feat and fix? What are y'all's thoughts on this?

[ThibFrgsGmz]

Personally, I prefer to follow the entire standard, even though it seems rather cluttered and little or not used at all. As this standard becomes more and more common in the industry, contributors who are familiar with it won't feel limited if they can use it fully.

Or why not try using Gitmoji ? Maybe it's my hipster side talking, but I find it quite original and I seem to be seeing it more and more often. There are many tools that come with it (see here):

• gitmoji-vscode : Gitmoji tool for git commit messages in VS Code
• gitmoji-changelog : A changelog generator for gitmoji.
• gitmoji-changelog-action : GitHub action for gitmoji-changelog

[LeStarch]

So to drop in some thoughts:

1. I would not ask committers to do this. It is too large a group to control and it would provide a substantial barrier if committers needed to rewrite all their commits.
2. We can apply it to the people who squash-and-merge. That would make the F´ history contain these well formatted commit messages. Thus item 1 would only apply to sub-commit comments and have less of a direct impact on the commit log.
3. While I do like gitmoji it was quit jarring to see it the first time. I think it is a bit much for our project given the range of customers we have today.

[thomas-bc]

Converting this issue to a discussion as it seems more appropriate to this conversation

[SterlingPeet]

I would like to advocate for something as a standard. I do not want to advocate for enforcing it programmatically on every commit, at least not initially.

As a project that has a lot of supporting tooling, I don't see a large barrier to building some tooling to support quickly updating contributed commits to conformance. I can concede that it is not quite as easy as requiring code to be formatted with clang, but I personally just don't see it as fundamentally different. In the projects that I have converted to (usually to gitmoji, but as mentioned that isn't for everyone) it has dramatically improved the documentation and release process.

I will note, the fact that I can include F Prime as a library lets me use my preferred tooling and processes already. I have found that other tools and frameworks I have used are not quite as well separated, leading to mixed standard usage and lots of edge cases to configure in the toolchain. Amusingly, by taking the pressure off of me, the pressure is also relieved on the framework side to address this issue, a hilarious failure mode of doing a good job. 😄