Product Team

⚡️🎯 Drive Mautic's Innovation: Connect at the Product Team's Monthly Meetings! 🎯⚡️

Intrigued by shaping Mautic's trajectory? Our monthly meetings are your stage to turn this intrigue into action. From release planning, enhancing security, to brainstorming new features, we explore the gamut of product development.

No matter your role - developer, coordinator, tester, or user - your unique insights can fuel our mission. A hub for both discussions and decisions, these gatherings are the engine behind Mautic's evolution.

Connect with us to truly impact Mautic's course and be part of our inventive symphony. Together, let's engage, innovate, and revolutionize Mautic's journey! 🚀🌍🔧

Attendees (Name, Company)

• Ruth Cheesley
• Mattias Michaux (Dropsolid)
• Jan Linhart (Acquia)

Apologies

• None received

Actions from last meeting

• Ruth / Mattias will work on an official blog post which explains what the tiger team is doing and apologises for the previous confusion around processes/PRs (and call for volunteers to help with testing/reviewing)

Notes from this meeting

• Release planning
• Mattias suggested two options for releases, quarterly or biannual releases: https://docs.google.com/spreadsheets/d/1ndtPILWwwErmtHfnk7_AFoYpsafZueethMylKI_mWmU/edit?gid=0#gid=0
• We decide to go with the quarterly approach. Security releases will be included in the patch releases as and when they are ready to be released. Security Team will be required to lead at least one release per year to be part of the team.
• We discussed how we deal with 'show stopper' bugs which need to be fixed before a release is made - for example we blocked the 5.1 release before the SAML bug was fixed, because nobody worked on it but a large and growing number of people were impacted by it
• We should set aside a time period where we have specific resources from companies available to help working on unblocking the release by fixing the bugs which are considered 'show stoppers' and essential to be fixed before the release. Ideally this should come after the Release Candidate period and before the release is made
• We need to make sure we schedule a release planning meeting towards the end of a Release Candidate phase, where we review the outcomes from the release candidate testing, and decide which bugs need to be prioritised by that team of people who are committed to working on them. These issues should be assigned to one or more people who have the responsibility of delivering them before an agreed date
• We decided that we should extend the time period which we support previous major releases to 7 months of security support (when the x.2 release is out, the previous major release is no longer supported).
• We discussed about how we might consider back-porting bug fixes to older versions but feel like that adds too much complexity right now - especially as we're dependent on volunteers largely, and at some points in the release schedule it would mean back-porting PRs to three different branches which is a huge ask. Maybe in the future we can make a LTS program where people can be financially compensated to backport PRs and/or companies can sign up to the program, but we haven't quite got the resources to start this right now.
• We want to enable orgs to 'own' a minor / major release (on their own or in partnership with other organisations)
• They would be responsible for having a release manager and assistant for the release who works with the product team to plan what features are to be included
• They'd have a minimum requirement to be available for Open Source Fridays where they are reviewing PRs, checking the minimum requirements are met, and merging the PRs.
• They'd be responsible for supporting the triaging of incoming issues and that they are correctly labelled, assigned where appropriate, and put forward to release planning meetings where they are essential for closing the release milestones
• Company could sponsor the release for either bug fixes or features in the case of a minor release
• We discussed that it might help to get PRs moving from our backlog if we could have specific focuses for features. We tried this before but we didn't really have the support to maintain the focus.
• Webmecanik in particular may benefit from this as it would give them clearly defined timeboxes in order to rebase and prepare their older PRs.
• We will pull all the open PRs and analyse to find what the most common category labels are, and then prioritise those, sort them into proposed releases
• We need to decide how we're going to manage the roadmap / priorities and clearly communicate that (for example, specified themes for specified releases) and set expectations as to when we'll merge things. We don't want to keep contributors waiting around if the PR is ready to be released, so we should be clear about how we'll deal with those which come 'over the fence' without prior planning.
• We will give a specific timeline in which we need to get all open PRs older than 6 months rebased, tested and merged after which we close all older PRs so that we can start working on 6.0

Actions from this meeting

• 5.1 release to go out tomorrow, Nick Van Praet will be release leader
• Pull a list of all PRs and analyse by the labels
• Share the UX/UI blog post update
• Draft up the blog post announcing the release processes and workflows, and collaboratively work through discussions
• Identify named release leaders for the upcoming 5.x and 6.x releases and company sponsors