Points to note:

1. There is a pre-commit hook, it should validate on CI
2. What do we validate? (e.g. starting at which commit, HEAD...n)? What about merge commits? "Validate that all commits in PR are valid according to convention"
3. Test drive the changelog generation (can we include github refs in there?)
4. Preferably use the inline validation in pyproject

Basic format:

• Conventional commit with optional ticket ref: feat: [#456] make things work better
• We'll go for all the conventional ones, except perf
• Dependencies are: chore(deps), but otherwise no scopes (That's enforced). Unless and until we have a clear enumeration of meaningful scopes

OIP Breaking change criteria

• Potentially requires action of admins (e.g. data migrations that might not be lossless, such as prosemirror upgrade) or the gemeente, e.g. if they anticipate confusion/disorientation from users and might want to prepare help, increased support, etc.
• No longer supporting a particular (version of) a third-party system, such as a ZGW backend (would then be good to make explicit what versions we do support)
• Removal of any page or functionality
• Removing any public facing URL (Wthout putting a redirect in place, as we would usually do)
• "Significant" changes in the design or flow of existing pages (what is significant? Hard to say: might prompt a spike in user questions for gemeente, if user cannot be reasonably be expected to figure it out)
• Inability to process imports from older versions (e.g. with ZGW objects).

To be clear: adding new functionality or pages is as a general rule not a breaking change.