Contributing guideline

nikstur commented

2023-02-28 19:16:40 +00:00

(Migrated from github.com)

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.

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.

👍 1

AkechiShiro commented

2023-08-21 04:11:02 +00:00

(Migrated from github.com)

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.

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 commented

2023-08-21 04:13:04 +00:00

(Migrated from github.com)

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.

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 commented

2023-08-21 16:45:28 +00:00

(Migrated from github.com)

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.

> 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.

👍 1

AkechiShiro commented

2023-08-21 16:54:13 +00:00

(Migrated from github.com)

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 ?

Rows
Columns

Contributing guideline #124