Propose removal of conventional commit style

[CodyCBakerPhD]

I've noticed we really don't tend to enforce or even incidentally use this convention across various repos (within this org or DANDI)

OK to just remove?

[asmacdo]

IMO a useful read even if we don't strictly follow, but I don't mind if we remove.

However I was asked to put this here by @yarikoptic so let's leave until he weighs in.

[yarikoptic]

Indeed, I would keep it

• I do encounter good number of projects (outside of DANDI where we do not have/enforce convention) using them
• Among some of ours involved some other conventions at least at PR level (e.g. as in bids-specification) are used so not applicable; and here we refer to datalad, so if/when you get to contribute there - could be your gateway to be "forced" to use it
• it would be a good practice to adopt them, please consider for all your projects!

[CodyCBakerPhD]

could be your gateway to be "forced" to use it

I have been using forced measures on all my latest projects: e.g., https://github.com/con/nwb2bids/blob/main/.pre-commit-config.yaml#L32-L37

The forced measures are exactly what make it extremely annoying and I haven't found any value in it personally. I'll just remove it from my own projects then

They also cannot be forcibly applied to GitHub suggestions, other web-side changes, or retroactively to already pushed commits (such as by someone who doesn't have pre-commit installed locally), which leads to a mix of the convention being used and not used (whereas the goal would be to always follow standard convention)

They also can't be enforced in that same manner for PR merges (whose merge commits are the name of the PR), and even if you did enforce it separately on PR names that would make the auto-generated changelogs look a bit ugly IMO

it would be a good practice to adopt them, please consider for all your projects!

If you feel like it is a good practice to adopt them, can I ask why you personally don't do it?

Quick glances at https://github.com/ReproNim/containers/commits/master/ and https://github.com/dandi/dandi-cli/commits/master/ show only 2 attempts at following the convention with neither being strictly valid (capitalized Refactor and leading [DATALAD RUNCMD] prior to chore)

[yarikoptic]

if some project already uses some convention -- then that convention could/should be continued to be used . That is what keeps me often using some old one with all those ENH BF etc prefixes -- kinda engraved into my brain/fingers.

it would be a good practice to adopt them, please consider for all your projects!

If you feel like it is a good practice to adopt them, can I ask why you personally don't do it?

I do when I am reminded about it or I contribute to a project which does. Indeed should likely strive to use it more instead of the engraved in the brain non-standard one.

As for forcing it -- in datalad team they use https://commitizen-tools.github.io/commitizen/ AFAIK e.g. http://github.com/datalad/datalad-core/blob/HEAD/.github/workflows/conventional-commits.yml.

Should we try it out for new projects? ;-)

[CodyCBakerPhD]

As for forcing it -- in datalad team they use https://commitizen-tools.github.io/commitizen/ AFAIK e.g. http://github.com/datalad/datalad-core/blob/HEAD/.github/workflows/conventional-commits.yml.

The pre-commit validation behavior for that doesn't look any different in behavior from the one I linked and doesn't seem to resolve any of the problems in the cases I pointed out (cases where pre-commit cannot retroactively run)?

In the worst-case, that particular approach looks like it could conflict with the autorelease changelog and versioning (which approach takes precedence?)

I do when I am reminded about it or I contribute to a project which does. Indeed should likely strive to use it more instead of the engraved in the brain non-standard one.

Exactly - my point is that if the natural tendency (to which we all seem to gravitate) is to not adhere to such conventions all the time (even by learned habit), then surely the implication is that we did not find enough of a mental benefit from the convention itself to be worth the hassle

Perhaps it 'sounds better in theory' than it does in practice?

Should we try it out for new projects? ;-)

I did, and that is why I no longer wish to. I do not find any benefit to it

As this is included here as an official onboarding policy without being widely used or enforced across the org, I merely found it curious why we would not simply remove it here or at least downgrade to a 'gentle suggestion' if people have a preference.