Project Lead Office Hours: Maintainer Month - How Mautic is maintained

Project Lead O ce Hours 16th May 2025 Maintainer Month special: Let’s explore how Mautic is maintained ffi @RCheesley

Ruth Cheesley (she/her) Mautic Project Lead ruth.cheesley@mau c.org speaking.ruthcheesley.co.uk for slides, recording, links and resources ti @RCheesley

Today’s schedule: 1. Short talk: How Mautic is maintained as an open source project (this part, and any Q&As, will be livestreamed) 2. Open oor: fl Any questions you’d like to ask, or things you’d like to discuss (this part will not be livestreamed)

Some ground rules: • All discussions abide by the Mautic Code of Conduct at all times: http://mau.tc/coc • The open oor section is under Chatham House rules: “participants are free to use the information received, but neither the identity nor the af liation of the speaker(s), nor that of any other participant, may be revealed.” • Please hold questions to the end, raise your hand or ask your question in the chat. • No AI note takers, the talk will be recorded and fl fi fl streamed, and the open oor is not to be shared.

How is Mautic organised? Council > General Assembly > Teams > Working Groups/Tiger Teams

Many opportunities to get involved! • Teams: meet fortnightly, regular onboarding, open to all (get an invite at mautic.org/slack) channels pre xed with #t-<team> • Tiger Teams: small groups with a focus on a speci c area (e.g. email deliverability, UX/UI, Campaigns, Forms, etc) - pre xed with #tt-<name> • Working Groups: formed for a speci c focus, e.g. organising a conference, managing the website, writing the newsletter, maintaining Docker image pre xed with #wg-<name> fi fi fi fi fi https://mau.tc/contribute

How are bugs xed in Mautic? fi fi Let’s follow a bug report from start to nish.

User of Mautic reports a bug. 1. Bug reported using the issue template on GitHub 2. Clearly explains what the problem is, how to reproduce it, and what is the expected behaviour fi 3. Triage Team review the bug report and assign the appropriate labels, con rms they can reproduce the issue and add any further clarifying details to the PR so that developers can understand the bug report.

1. Developers look for bugs to resolve by using labels - good rst issue, regression, tiers, area of Mautic or version affected - or through the Open Source Friday project’s ‘To Do’ column. 2. A proposed x is made using a Pull Request, connecting with the issue by mentioning that it xes the speci c issue fi fi fi
2. Clear instructions are provided for testers and reviewers, showing a before/after screenshot where appropriate and steps to test. fi fi Developer xes the bug.

Test and review. 1. A minimum of 1-2 people must manually test and approve the bug x (depending on the complexity of the x, more complex = more people) 2. A minimum of 1 person must review and approve the code changes, ideally someone from the Core Team 3. Any UX/UI changes must be approved by a member of the UX/UI Tiger Team fi fi 4. All automated tests must pass

Release leader merge/release. Once all testing and code review is completed, the PR is marked as ‘Ready to Commit’. The Release Leader for the relevant release conducts a nal review, ensures all feedback is actioned, and merges the PR. The connected issue should automatically be closed. fi When the release is made, the PR will be automatically mentioned in the release notes and the contributor credited accordingly.

How are major features introduced in Mautic? fi Let’s follow a major feature from start to nish.

User of Mautic requests feature. 1. Feature requested on Mautic Forums 2. Users of Mautic vote on features they want to see introduced 3. When suf cient interest, feature proposed via Community Portal for Core Team to consider fi 4. Developers submit proposal, or funding is sought for the proposed project

Proposal accepted. 1. Core team accept proposal if it’s something that would t with the project’s vision and mission, and should exist within core 2. Timelines agreed with developer, proposed release set for when the feature will become available in General Availability fi 3. Work starts on project

Community updates. 1. During work phase, community is regularly updated through an Assembly on the Community Portal 2. Work follows a two-weekly sprint cadence, with updates at the end of each sprint 3. Pull Request created so that work is public and can be reviewed iteratively by the Core Team 4. Testers and Code Reviewers requested to validate the work and approve it for merging into a release

Release leader merge/release. Once all testing and code review is completed, the PR is marked as ‘Ready to Commit’. The Release Leader for the relevant release conducts a nal review, ensures all feedback is actioned, and merges the PR. fi When the release is made, the PR will be automatically mentioned in the release notes and the contributors credited accordingly.

Ruth Cheesley (she/her) Mautic Project Lead ruth.cheesley@mau c.org What questions can I answer? ti @RCheesley