# Should we use standard version in our commit messages for Mautic core and plugins?

**URL:** https://forum.mautic.org/t/should-we-use-standard-version-in-our-commit-messages-for-mautic-core-and-plugins/37502
**Category:** Product Team
**Created:** [March 19, 2026, 11:42am UTC](https://forum.mautic.org/t/should-we-use-standard-version-in-our-commit-messages-for-mautic-core-and-plugins/37502 "2026-03-19T11:42:36Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![adiux](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/adiux/32/5793_2.png) [@adiux](https://forum.mautic.org/u/adiux)
#### Post date: [March 19, 2026, 11:42am UTC](https://forum.mautic.org/t/should-we-use-standard-version-in-our-commit-messages-for-mautic-core-and-plugins/37502/1 "2026-03-19T11:42:36Z")

</div>

## Proposal: Standardize Commit Messages across Mautic using Conventional Commits

Hi everyone,

while working closely with different parts of the Mautic ecosystem, I noticed that we currently use a variety of commit message styles across repositories.

This makes it harder to:

- understand changes quickly

- generate consistent changelogs

- automate releases in a reliable way

I see some already apply `Conventional Commits`: feat(email): my amazing feature.

👉 I would like to propose that we align on a common standard:  
**Conventional Commits (used by standard-version / semantic-release)**

## Why this matters

A consistent commit format enables:

- automated changelog generation

- better readability of commit history

- easier onboarding for contributors

- cleaner release processes

Many modern projects already follow this approach.

## Proposed format

```auto
type(scope): short description

```

Examples:

```auto
feat(contact): add bulk edit for contact segments
fix(form): prevent radio value 0 from being preselected
obs(logging): add structured JSON logs for API requests

```

## Suggested base types

A simple and practical set could be:

- `feat` → new user-facing feature

- `fix` → bug fix

- `ux` → user experience improvement

- `obs` → logging, tracing, metrics

- `perf` → performance improvements

- `security` → security fixes

- `chore`, `docs`, `refactor`, `test`, `build`, `ci` → internal changes

## Aivie setup (example)

We implemented this in Aivie using:

### 1. Commitlint (validation)

```auto
'type-enum': [
  2,
  'always',
  [
    'fix',
    'feat',
    'ux',
    'obs',
    'chore',
    'perf',
    'revert',
    'docs',
    'style',
    'refactor',
    'test',
    'build',
    'ci',
    'security'
  ]
]

```

### 2. Standard-version (changelog + releases)

- commits are grouped automatically

- changelog sections are generated consistently

- releases are derived from commit history

### 3. Git hook (enforcement)

We enforce the format via a `commit-msg` hook:

```auto
npx --no -- commitlint --edit "$1"

```

This ensures:

- consistent commit messages

- immediate feedback for contributors

- no need for manual policing

## Why not enforce this centrally?

This is not about strict enforcement across all repos immediately, but about:

- agreeing on a shared convention

- gradually aligning over time

- improving the developer experience across the ecosystem

## Sources

- [Conventional Commits Docs]( [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/#summary) )

-[Aivie Recaptcha Plugin]( [GitHub - aiviemarketing/aivie-recaptcha: This Plugin brings reCAPTCHA integration to mautic. · GitHub](https://github.com/aiviemarketing/aivie-recaptcha) )

## Open questions

- Would the community be open to adopting a shared commit convention?

- Are we ok with the proposed set of types?

- Should we force topics? E.g. feat(email): new features for email

- Would it make sense to include this in contributor guidelines?

Happy to hear your thoughts and discuss 👍