Commit messages

When suggesting or writing commit messages for this repo, follow these rules.

Format

Use Conventional Commits. Prefer the form type(scope): description or type: description. Keep the type to a set that tools like Release Please recognise: feat, fix, docs, style, refactor, perf, test, build, ci, chore. Scope is optional; use it when it helps (e.g. feat(graphql):, fix(data-sourcing):).
Subject line: Imperative mood, lowercase after the colon. Write it so it would make sense in a changelog on its own (e.g. feat: add whitelisting_rules query not feat: added whitelisting_rules query or feat: Adding the whitelisting rules query).
Jira/ticket refs: Only reference a ticket (e.g. SIM-652) in the subject or body if this commit fully resolves that ticket. Otherwise omit.
Merge commits: Leave merge commit messages as-is; do not rewrite them.

When to add a body: Only for non-trivial commits. Small, obvious changes do not need a body.
Style: Prefer short, concise bullet points. Focus on what matters to the end user or to the project’s architecture; avoid narrating every file or line changed.
Length: Keep the message reasonable. Nobody wants to read an essay.