Contributing guideline

[nikstur]

We should create a contributing guideline. This should include our commit conventions (following nixpkgs) and a logging policy (as mentioned in #121). Ideally, we would have a CONTRIBUTING.md file that is linked from the README.

[AkechiShiro]

In the contributing guide, will commits need to have signed-off:<author-name> (like for kernel contributions ?) and perhaps be GPG signed as well, for instance, or there is no need for anything like this yet, to be enforced, just thinking about a security standpoint.

I'm not sure if enforcing this would need to deploy specific bot accounts, I've never enforced this kind of setup for a GH repository.

[AkechiShiro]

Maybe we can also scrap some documentation from here :
https://www.conventionalcommits.org/en/v1.0.0/

Or even link it, I'm not sure if it's relevant but from what I see for PR names, it might be.

There would also be the following benefits according to the "specification" of conventional commits :

• Automatically generating CHANGELOGs.
• Automatically determining a semantic version bump (based on the types of commits landed).
• Communicating the nature of changes to teammates, the public, and other stakeholders.
• Triggering build and publish processes.
• Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.

[RaitoBezarius]

In the contributing guide, will commits need to have signed-off:<author-name> (like for kernel contributions ?) and perhaps be GPG signed as well, for instance, or there is no need for anything like this yet, to be enforced, just thinking about a security standpoint.

No, I don't think we need to bother ourselves with GPG nonsense, neither with developer certificate of origins.

I'm not sure if enforcing this would need to deploy specific bot accounts, I've never enforced this kind of setup for a GH repository.

This is not relevant.

For the conventional stuff, I feel like you are trying to solve a technical problem.

[AkechiShiro]

Are these technical problems, something we should actively try to solve in order to have lesser friction for handling new contributions/reviewing and release maintenance ? Or this is not a key focus right now, as other things needs to be polished, first ?