Discussion: How might a Conventional Commits look like for docs/workshop repos #52
Description
Summarising the discussion in rostools/github-intro#90, I think this is a good time to start considering how to use Conventional Commits for doc projects, especially to make use of the existing commitizen workflows to auto-version the repos. E.g. to upload to Zenodo for every version bump (or upload only on breaking changes or something? That's another discussion).
As for when to start using this revised way... I think the argument that we've been using docs: so far, so we should keep doing that isn't a valid enough reason on it's own to not switch. It isn't hard to switch and it doesn't matter when we switch. Said another way, at what point would we switch? After the first time we run the workshop? What's the reason for that? It still feels very arbitrary. Plus, it would be fantastic if we could create a workflow to auto-version and deploy to Zenodo for the first time we run the workshop so we have a DOI and a more "formal" output 😁 🎉
So, how might it look like to use Conventional Commits in doc/workshop repos? The types that are the same as software projects are build, ci, style, chore, and revert. The ones that are not relevant are test and perf. The one that is basically all commits aside from the overlap ones with the software projects is docs, which in documentation/workshop settings is meaningless since they are all docs. So docs would no longer be needed.
That leaves only feat, refactor, and fix that are different from software projects.
Based on this, here are some ideas:
feat: Used whenever new content is added.refactor: Used whenever existing content is modified or revised, but the meaning or intent stays the same. This would be likely used in editing or proofreading phases or tasks.fix: Used whenever there is a typo, grammatically error, incomplete sentence, or other similar writing mix-up/situation where the text doesn't align with our original intent.
(Note: the Gitmoji commits are much more diverse, so can probably be continued to be used as is, except for maybe :memo: since that is pretty generic and not descriptive.)
Thoughts?