Mautic 6.0-alpha and 5.2.2 release – January 2025

January is shaping up to be a fruitful month, as we plan to release Mautic 6.0-alpha.

While you might still be basking in the glory of Mautic 5.2, it’s important to know that work on Mautic 6 started months ago. Mautic is getting closer to running on Symfony 6, and the team is aiming for the 6.0-alpha release by January 27th (Monday).

There are 9 open pull requests and 45 merged pull requests right now – so it’s all hands on deck!

Right after that, we’ll drop Mautic 5.2.2 on January 28th.

Expect 27 merged bug fixes and 5 still hanging in the air as of this blog post. 

Mautic versions usually come with almost 2 years of support, plus another year of security patches (and even two more years security support with Extended Long Term Support if you need it.) Mautic 6, however, will have a shorter life cycle, acting as a bridge to Mautic 7. After the stable release of Mautic 6, we’ll shift focus to Mautic 7, which will finally synchronize Mautic with the Symfony release schedule. 

Why the focus on another Major release?

You might be wondering why we’re jumping so quickly to another major release of Mautic after we released Mautic 5 not so long ago, and the reason is because we’ve been playing catch-up for the past few years so that Mautic is running on an actively supported version of Symfony – currently that is Symfony 6.4 which is in active support until 2027 – and to a lesser extent, PHP. 

In order for Mautic to ensure that we’re keeping up with Symfony and PHP releases, we need to get up to Symfony 7 as soon as possible, which will enable us to provide the much needed longer periods of support for each Mautic version. It also frees up our core team to focus on improving Mautic’s features and functionality rather than simply keeping up with mandatory updates. 

So, we’re going to release Mautic 6.0 as a ‘bridging release’ with only bug fix releases after it’s shipped, and then straight away our focus will be getting Mautic 7 ready to roll with Symfony 7 support, which means Mautic 7 is coming in Q4 2025. 

The first version for testing is expected by the end of summer 2025, and we’re super pumped!

Why testing and merging PRs is so important right now

Once Mautic 6 is out, no new features will be added to it. All new features and improvements will go directly into Mautic 7. 

This is why it’s so important to test, and get those amazing PRs into Mautic 6 before the release freeze. Mautic 6 is nearing its final stages, and after the freeze, no new code will be added. If you’ve got a great PR, now is the time to get it in! We rely on your contributions to make Mautic better, and we’re counting on you to help us finish strong!

Now, just because Mautic 6 is a stepping stone to Mautic 7 doesn’t mean the summer is going to be boring – oh no! We have a ton of features in Mautic 5 that we haven’t fully documented and featured yet, and they’re waiting to be discovered. Our Education Team is about to go into screenshot mode, as Mautic’s look and feel has had a shiny makeover and the documentation therefore needs updating.

But that’s not all – Campaign Library (remember that cool project announced at MautiCon?) has just launched in the research phase of our grant-funded project, with Project Manager David Jarvis (DJ) and developer Levente Bajusz. You’ll be seeing a few blog posts about it in the coming weeks on the Community Portal. It’s going to be epic!

And let’s not forget the amazing Mautic contributors who keep surprising us with new plugins that bring brand-new functionality to our beloved tool. You rock!

Mautic 7: the future is bright!

As soon as Mautic 6 is released, we’ll kick off work on Mautic 7. If all goes according to plan, we could even release Mautic 7.0 General Availability earlier than expected. We’ll have to make sure we stay in sync with Symfony’s releases, though, as they’re only on minor release 7.2 and the 7.4 release will be their Long Term Support (LTS) version, we expect. We’ll keep an eye on any BC-breaking changes and deprecations, but you can rest assured – we’re on it!

We’ve listened to a lot of feedback from across the community and we have decided to slightly adjust our release strategy to better streamline our processes without stifling innovation.

Our goals with this updated release strategy are:

• Predictable releases which are on-time 
• Ensure Mautic is always up to date with releases from our major dependencies
• Rapid release of bug fixes and new features when fully tested and reviewed
• Longer support periods for major versions, with minor releases for 12 months followed by a long period of feature stability

 In summary, we will:

• Move to a 24-month release cycle between major releases, which is aligned with that of Symfony – Mautic’s primary dependency and underlying framework
• Move to time-based releases (from a mix of time and feature based)
• Extend support for each Major version so that it’s supported for at least 18 months
• Continue with monthly patch (bug-fix) releases during the active support period
• Provide one security release each quarter during the active and security support period, where fixes are ready to release (and any urgent out-of-cycle releases as deemed necessary by the Security Team)

Below you will find a detailed explanation of our new release strategy.

Establishing a Long Term Support (LTS) version

To date Mautic has never had an official Long Term Support (LTS) version – we continually shipped feature releases quarterly until a new release was out, and then we stopped supporting the previous version within a matter of months. 

This is painful for businesses with complex installations or agencies supporting large numbers of versions, because:

• They want stability more than continuous change, and 
• They need time to test and update the new Major release for their instances (and sometimes have to wait for third party plugins to be available and mature) however bug fixes are no longer provided for their current versions.

Now, we’re going to ensure that the previous version of Mautic is supported for at least six months after the General Availability release of the next Long Term Support version.

Generally speaking after Mautic 6.0 (which is a special series – more on that later) the Long Term Support version will be the *.3 release of any series, unless there is some unexpected need to issue more minor releases.

For example, Mautic 7.3 will be the LTS release in the 7.x series, and that will receive bug fix updates through until the end of 2026 when it will then receive security fixes for another year.

This means that going forward each release series will eventually be actively supported for at least three years from the General Availability release, when you consider active support and security support.

Establishing an Extended Long Term Support (ELTS) program

Following debate within the community, an Extended Long Term Support (ELTS) program is being developed which aims to launch in Q1 2025. This will see us offering a paid service which provides subscribers with security fixes for an additional period of two years (paid in annual subscriptions) from the end of security support, after which that release series reaches End of Life.

The ELTS will be an annual subscription which is paid at the beginning of the calendar year for the following 12 months, on a per-instance basis. More details on this will be released by the ELTS working group in due course.

Establishing a clearly defined release cadence

In the past we had aimed to release at the end of the month on the last Monday, but recently this has become more sporadic as we fell into the trap of trying to get specific features or bug fixes merged into a release, resulting in delays. 

Now, we’re going to move to a strictly time-based release process. Whatever is ready, tested, documented and merged on release day will be included in the release. Everything else will have to wait for a later release. The Product Team will continue to have a bounties fund which they can use to incentivize fixing specific bugs which need to be addressed and where there isn’t existing interest.

Major releases have a clearly documented Alpha, Beta and Release Candidate feature freeze – if features are not ready, they will not be considered for that release. Minor releases will have a Release Candidate freeze the month prior to release and no further features will be considered after this date.

We will also ensure that the second release in a quarter is a security release where there are security fixes ready to be released. This gives Mautic users more clarity on when to expect these fixes to come over, and also means the security team are primed with clear dates in mind to get their work deployed to Mautic users.

Catching up with Symfony releases

Since Mautic 3 we’ve been playing catch up with Symfony releases, which has meant that Mautic has only just managed to deploy a new version before security support ends for a series of Symfony releases. This is quite painful for larger businesses who require their software to be running on actively supported versions, and it also puts a great deal of pressure on the Product Team to cram a lot of changes into a release with very tight deadlines.

We are planning to address this in a couple of ways:

1. We will make Mautic 6.0 – which supports Symfony 6.x – a ‘bridging release’ which will only be supported for 21 months from the General Availability release, plus one year of ELTS support rather than two.
    
   • Mautic 6.0 General Availability will be released in Q1 2025
      
   • This will be the LTS version of Mautic 6.x – there won’t be any other feature releases in this series, only patch releases
      
   •  Mautic 6.x will become End of Life after 12 months of ELTS support, in October 2027, with Symfony 6.x being End of Life in November 2027.
      
2. After 6.0 is released, all future features will be on the 7.x branch
   • Mautic 7.x will support Symfony 7.x 
   • Mautic 7.3 will be the LTS version
   • Security support ends at the end of 2027

ELTS support will extend until the end of 2029, when both Mautic 7 and Symfony 7 will reach end of life.

Sponsored releases

The biggest blocker for Mautic’s ability to sustain its progress is having the resources to lead and support releases.

Going forward, we will have the option for companies and organizations to sponsor a release, which means their logos and links will be prominently linked on the release notes and the website, along with all communications associated with the release.

In exchange, they can either fund or provide in kind the services of a developer who will work with the release team, moving that release through from planning to deployment.

Conclusion

To wrap up, we’re really looking forward to implementing this new release strategy to better serve our community. By moving towards a 24-month release cycle, focusing on time-based releases and extending support for each major version, we’re taking steps towards a more predictable, stable future for Mautic from which all benefit.

The introduction of an official Long Term Support (LTS) version and providing a paid-for Extended Long Term Support (ELTS) program demonstrates our commitment to providing greater stability for those users who require it, without sacrificing innovation.

By catching up and keeping pace with Symfony releases, we can ensure we’re always providing the latest technology and features while removing technical debt, ensuring Mautic is using the latest versions of the secure and modern framework on which we depend.

We’re confident that these changes will help to streamline our processes, enhance our product and inspire future growth and innovation. This is an exciting new chapter in Mautic’s journey and we’re looking forward to embarking on this journey together with our community. Here’s to a bright future for Mautic!

We haven’t met those proposed dates, and here’s why.

What is taking so long with releasing Mautic 5?

In the previous versions of the framework that underpins Mautic – Symfony – two templating engines were supported: PHP and Twig.

Mautic has been built using the PHP templating engine – it’s familiar for developers, and provides more flexibility. However, this engine was officially deprecated in Symfony 4.3 and has been removed in Symfony 5. This means that we have to migrate all of our existing templates over from the PHP to the Twig engine.

This might sound easy, but our best guess suggested that this would mean over 700 files need to be updated, with many files requiring others to be updated first, as they were dependencies.

What do we need to do to release Mautic 5 faster?

As at writing this blog post, the product team channel has been working every week during the Open Source Friday but until recently, a small team of volunteers now work daily to get Mautic 5 ready for alpha-release and there are still a couple of outstanding tasks and some need reviews before they can be merged.

• Remove UI based upgrade TPROD-341
• Get Mautic working on Symfony 5 TPROD-342
• Remove support for PHP 7.4 and implement support for PHP 8.1 TPROD-345

The following needs review to get them merged:

• LeadBundle – Import
• Add Symfony Mailer Only
• DynamicContentBundle: migrate views from PHP Engine to Twig
• NotificationBundle – Mobile – Convert PHP Templates to Twig Templates
• NotificationBundle – Web – Convert PHP Templates to Twig Templates
• LeadBundle – Import #11814

You can find our more information on GitHub Roadmap to 5.0-alpha release

How you can contribute

You do not need to be a Developer to test new features that are planned for Mautic 5. Here is how you can contribute as a Tester and we encourage you joining our #t-product on Slack, if you are not on Mautic Slack you can request an invite.

Together with your contribution we can make Mautic 5 Alpha Release possible by the end of February 2023.

What follows is an update on how we’re getting on with that process, and what you can expect as a Mautic user as regards timelines and new features.

tl;dr

Mandatory upgrades

Symfony 5 support

Mautic uses several different tools ‘under the hood’ which we have to keep up to date, and the biggest of these is Symfony, the framework that underpins Mautic. Symfony has a regular release schedule just like Mautic, and as a result we have to keep up with that and implement support for new releases in Mautic.

Mautic 5 will ship with Symfony 5 support, and we are very nearly complete with the work that needs to be done in this area, which we are tracking under https://mautic.atlassian.net/browse/TPROD-248. 

We recently crowdfunded $4,000 to support a contractor working through a large part of the outstanding tasks where we could not find community contributors to work on. This work has just been started and is expected to be concluded by the end of October.

As soon as this work is completed we will be able to test Mautic with Symfony 5, and fix any outstanding issues.

We aim to have this completed by the end of November, with a view to making a testable alpha release at that point. We are aiming for a Release Candidate in December, with General Availability in January 2023 assuming the support from the community with testing and reviewing.

If the work proceeds faster than expected (which you can help with, by joining us on Fridays to help with testing!) we may also consider whether we can jump two versions, and include support for Symfony 6 with Mautic 5.

The revised release schedule can be found below, and is always available on the Releases page.

PHP 8.1 support

We were not able to implement support for version 8.1 until Mautic 5, because it requires some changes which break backwards compatibility. The work to introduce support for 8.1 will necessarily mean that we no longer support the outdated version, 7.4, as we only support the latest two minor versions of PHP. 

This work will commence as soon as we have completed the work for Symfony 5 support, because it is dependent on several aspects of that work.

We aim to have PHP 8.1 support included in the alpha release at the end of November.

New features

Mautic 5 will ship with some new features:

Contacts

• Allow exporting of stage with contact exports
• Show contact’s engagement statistics on their profile (Total sent, Open rate (OR), Click-through rate (CTR), Click-to-open rate (CTOR))
• Show contact created and modified date on profile

Campaigns

• Use stages as a condition in Campaign Builder

Segments

• Showing a segment dependency tree to identify optimization opportunities in your segmentation
• Several substantial performance optimizations for building segments

Emails

• Replace Swiftmailer with Symfony Mailer (3x faster message sending, and no more cron jobs for sending messages!)
• Prevent duplicate sending of segment emails when a send is already in action
• Addition of dropdown in editor for inserting Mautic tokens into the GrapesJS builder

Forms

• Allow formatting of help messages on Forms with HTML

Landing pages

• Configure a success message when preference center options are updated

Reports

• Filtering reports by tags
• Reports based on devices used

Webhooks

• Several substantial performance optimisations relating to the processing of the Webhooks queue

Potential features

More features may be added over the coming months, if we have help to test them. Some examples of features waiting for review include:

• Ability to anonymise exported data https://github.com/mautic/mautic/pull/11535
• Additional configuration of web push notifications to include image, badge and icon settings https://github.com/mautic/mautic/pull/11395
• Allow cc, bcc and attachments on direct emails to Contacts https://github.com/mautic/mautic/pull/11297
• Add token support for SMS https://github.com/mautic/mautic/pull/10779
• Add support for SMS callback with read and received notifications https://github.com/mautic/mautic/pull/9952
• Management of multi-companies https://github.com/mautic/mautic/pull/10817
• Improvements to the Preference Center https://github.com/mautic/mautic/pull/10579
• Segment membership change webhook https://github.com/mautic/mautic/pull/10511

Anybody who uses Mautic can help with testing these features, and developers can help with doing code review. Read more in our Community Handbook, and if you can join us on Fridays that is the best time, as we have a community contribution event every week – just head to Slack (get an invite at https://mautic.org/slack) and join #t-product.

A note for developers

As we have been working with the release process since Mautic 3, we have been refining our workflows. We have made a change to help with improving the stability of releases and prevent bugs slipping in as a result of merging changes from one branch to another.

The basic principles:

Assuming a = current major release, b = current minor release, c = upcoming major release

At the present time, a.b = 4.4, c.x = 5.x

• Features and bug fixes should always made against the c.x branch in the first instance – for example 5.x
   
• Bug fixes that need to be released into a minor or patch release should ALSO be made against the current minor release branch a.b – for example 4.4, in addition to being made on the c.x branch
  • This means creating a duplicate PR – we know it is an extra step, but:
     
    • This helps to prevent bugs with complex merges of minor to feature branch (often having over 100 conflicts to be resolved)
       
    • This means that the correct environments for the unit tests with the appropriate PHP and MySQL versions can be run at the point where you create the PR, and you can address any issues right away
       
    • This means that your bug fix will be tested in both versions, not just one and hoping it works in the other (which has led to several bugs recently).
       
    • This means we should be able to merge your PRs much faster and with greater confidence.

We know that this is an extra step, however doing this when you create the PR significantly reduces the possibility of bugs and helps us to move faster with making releases.

While we are really proud of the progress we have made, there are some areas that are not working so well, which we are going to address going forward.

Release planning

At the present time of writing, we have 209 open pull requests waiting to be tested and reviewed, however only 67 of these are in a condition that would allow them to be merged. There are various reasons why a pull request would not be mergeable, but the most common reasons that we see are:

• Inadequate automated test coverage
• Automated tests failing
• Conflicts with files that have changed since the pull request was created which have not been resolved
• Lack of documentation to support a new feature or significant change

In the past, we have been assigning a pull request to a milestone (which tells the developer when we are planning to release their change) regardless of whether the pull request was mergeable. If the pull request is not ready to be merged, it just gets bumped back to a later release. In some cases this has been happening for over a year!

Going forward, we will be changing this.

Quarterly release planning

Once a quarter, the Product Team will hold a release planning meeting (open to all) where they will decide what pull requests will be included in the next three releases. These will include two bug fix releases and one minor release (except for the last quarter, which may include a major release):

• Month 1 Patch release (eg 4.0.1)
• Month 2 Patch release (eg 4.0.2)
• Month 3 Minor release (eg 4.1)

The meetings this year will be held on:

• 6th July 2021
• 5th October 2021
• 4th January 2022
• 5th April 2022

All @ 1400 UTC, on Zoom – see the Community Calendar / Product Team Slack for information.

Having reviewed all the previous releases in the history of Mautic, we know that our average over the past two years has been around 20-30 pull requests per release. 

We will therefore only be accepting a maximum of 20 pull requests targeted for each release.

To be considered for inclusion, the pull request must:

1. Have all automated tests passing
2. Maintain, or ideally improve, automated test coverage (as measured by Codecov)
3. Have documentation updates already created and reviewed by the Education Team
4. Be in a mergeable state (have no file conflicts)
5. Have clear instructions in the pull request description for testers to follow which will allow them to:
   1. Reproduce the bug (if the pull request is a bug fix)
   2. Test the fix / test the feature
   3. Understand the areas that the pull request may impact to facilitate full and proper testing

The team will then update the milestone on the pull request accordingly once they have agreed on which are to be included.

Reviewing issues

Of course, pull requests are only one part of the story – we also have to think about the issues that users of Mautic are reporting.

During the release planning meeting, the Product Team will also review the open issues. If there are issues which they feel need to be addressed in future milestones but where there are no pull requests to fix them, they will be able to allocate funds from their bounty budget to those issues and will add them to the appropriate milestones.

The team will at this point accept five new issues per release, taking us up to a hard ceiling of 25 potential pull requests that will be considered for each release.

What about urgent fixes?

We fully appreciate that sometimes there are nasty bugs that are spotted or security issues that need to be addressed. 

The same rules will apply for such fixes to be considered for inclusion in a release as mentioned above. 

The team will do their best to include extra pull requests outside of the agreed scope for the release, however priority will be given to those pull requests that have been planned for inclusion in the milestone.

Areas of focus

The Product Team will also be introducing areas of focus for the quarterly release cycle, where they will be specifically targeting certain features or aspects of the product for improvement.

This will involve there being a bug fix release for two themes, and then a feature release which will focus on both themes.

As an example, the themes for the upcoming release after Mautic 4 are:

• July 2021 Bug fix release (4.0.1) – Forms
• August 2021 Bug fix release (4.0.2) – Campaigns
• September Features release (4.1) – Forms and Campaigns

Named release leads

Taking the role of a release lead is no easy job.  This has fallen to a very small number of people this year, and we want to involve more people in this process.

For this reason we will be having a named release lead for each release, and at least one assistant.  Newcomers to the role will serve as an assistant until they feel confident in leading a release themselves, giving the opportunity to pass on knowledge and involve more contributors in this process.

If you would like to be involved, please join the Product Team on Slack and get involved with reviewing pull requests and testing!

We hope that these changes will serve to focus our efforts on certain areas of Mautic and also give developers and users of Mautic a clearer understanding of what they can expect from upcoming releases.

While we would not exclude pull requests from a release if they are fully ready to be included, we will give first priority to those which are in the milestone, then those that relate to the area of focus. Other pull requests will be considered only if there are not enough to fill the quota for that release.

Throughout this time the Community Leadership Team has been working closely with Acquia on building the foundations from which we can grow as a project and a community.

We have some exciting updates to share with you today from across the project.

A full time Project Lead appointed

Key to the success of any Open Source project is a strong leadership team who are engaged and dedicated to the growth of the project with a shared common vision.

Today we are delighted to announce that – with the full support of the Community Leadership Team and DB Hurley – Acquia has appointed a new, full-time project lead. Community Manager Ruth Cheesley will be taking up the position of Project Lead.

After leaving Acquia, DB Hurley scaled back his participation in the Mautic community and felt it was in Mautic’s best interest to have a full-time Project Lead.  He will continue to act as an ambassador for the Mautic project. We are grateful for DB’s leadership and having guided us this far.

Ruth has been involved with Mautic for a long time, and is excited about the opportunity to take up the baton from DB.

This will mean some changes to the governance structure which are outlined here.

Setting the direction for Mautic

As a community, our underlying mission is to help people succeed with Mautic. Everything we do as a project aligns with this vision.

We have six areas we are currently focusing on – ways we are helping people to be more successful with Mautic.

1. Develop the features and functionality so that Mautic becomes the tool of choice for Marketing Automation, and the market leader in this space
2. Improve the ease of use for marketers
3. Improve the stability and reliability of Mautic
4. Improve the way we support people to succeed with Mautic
5. Enable organisations to scale Mautic as they achieve success
6. Build a community that is self-reliant, welcoming, diverse and engaged

We have multiple initiatives and projects which we will be sharing – some today and some over the coming weeks – all of which contribute toward our mission.  The first of these initiatives from the Product Team follows below.

Updates from the Product Team

With the launch of Mautic 3, the Product Team will be making some changes to move us toward our vision of helping people succeed with Mautic.

We hope that we explain them fully below, however if there are any unanswered questions we will be running a series of live discussions and Q&A sessions where you can ask questions.

Release strategy and cadence

Mautic 3 is the first major release in nearly four years. Between Mautic 2 and Mautic 3 there hasn’t been a clear cadence to the releases.

This creates challenges for everybody who relies on Mautic.

Organizations who rely on Mautic don’t know when to expect updates, which makes it very difficult for them to plan maintenance windows into their business cycles.

Community contributors who are submitting fixes and features don’t know when pull requests are going to be merged, or which releases they should be aiming for when they are creating their contributions.

Users of Mautic do not have forewarning of when to expect an update, or when features that they really need are likely to be delivered.

We appreciate that this not only causes confusion and frustration, but also makes it difficult for people to adopt Mautic when there is such uncertainty.

As a result the Product Team has decided to implement some changes to the way that we release updates for Mautic.  We follow semantic versioning in our releases, for more information please read semver.org.

Monthly patch releases

We will be making a patch release every month. Patch releases include bug fixes only.

An example of a patch release would be 2.15.1, 2.16.2, 3.0.1.

Quarterly minor releases

Every three months we will issue a minor release. Minor releases can include features which do not break backwards compatibility, and bug fixes.

An example of a minor release would be 2.15, 2.16, 3.1.

Yearly major releases

A new major release will be made any time there are backwards compatibility breaking changes ready for release.  We estimate a new major release every few years, but the exact frequency will depend on Mautic’s dependencies (e.g. Symfony, jQuery, etc).

As an example, we will need to upgrade from Symfony 3 to Symfony 4 or 5, well before Symfony 3 is end-of-life.  The upgrade from Symfony 3 to Symfony 4 or 5 will likely require us to release a new major version of Mautic.

Major releases may include backwards compatibility breaking changes, features and bug fixes. An example of a major release would be Mautic 2, Mautic 3.

Anticipated release schedule

• Mautic 3.0.0 – Symfony upgrade [Stable due May 2020]
  • Mautic 3.0.1 – June 2020 Bug fixes [monthly releases]
  • Mautic 3.0.2 – July 2020 Bug fixes [monthly releases]
• Mautic 3.1.0 – 3.x improvements and new features [August 2020]
  • Mautic 3.1.1 – September 2020 Bug fixes [monthly releases]
  • Mautic 3.1.2 – October 2020 Bug fixes [monthly releases]
• Mautic 3.2.0 – 3.x improvements and new features [November 2020]
  • Mautic 3.2.2 – December 2020 Bug fixes [monthly releases]
  • Mautic 3.2.3 – January 2021 Bug fixes [monthly releases]
• Mautic 3.3.0 – 3.x improvements and new features [February 2021]
  • Mautic 3.3.1 – March 2021 Bug fixes [monthly releases]
  • Mautic 3.3.2 – April 2021 Bug fixes [monthly releases]
• Mautic 4.0.0 – Backwards compatibility breaking changes [May 2021]

Requirements for merging pull requests

Automated Tests

From the release of Mautic 3, we will be requiring all pull requests to include automated tests before they are considered a candidate for being merged into a release.  This will help us improve the stability of Mautic and prevent regressions occurring.

We appreciate that this may be a challenge, and we are planning a sprint in the near future to improve our test coverage, up-skill developers in writing automated tests, and updating our documentation.  If you are experienced in writing automated tests and would like to help with this, please reach out to the Product Team.

Documentation

We already have a requirement for pull requests to include documentation, however this has not been strictly enforced.  This has led to outdated documentation and incorrect code examples.

From the Mautic 3 release forward it will be mandatory to include an update for the End User Documentation and/or Developer Documentation before a pull request is considered a candidate for merging into a release.   The Education Team will be working closely with the Product Team in all releases to ensure that this requirement is met.

Google Season of Docs

We were also recently selected for the Google Season of Docs, so over the summer we will also have technical writers helping us further improve our documentation.

Sneak peek at upcoming changes

The Product Team are currently working on some updates to our code governance workflows which are being reviewed and finalized.

The Community Team and Product Team are working together on a project which will enable contributors to take responsibility as a small team for specific areas of the Mautic project – for example specific bundles or features – becoming community experts in this area.

This will allow contributors to specialize with a small team in a focused area, and support the rest of the project with updates, improvements and features.

Interested to know more? Join the Product Team chat on Slack – get an invite at mautic.org/slack.

Questions?

We appreciate that this is a lot of information to take in, and we expect that you may have some questions.

We will be holding several AMA-style sessions and webinars over the coming weeks with our communities around the world, giving you the opportunity to put any questions you may have directly to the Community Leadership Team.

We are excited to be moving into a new phase as a project, and look forward to a bright future.

Live discussions and Q&A:

Please note, we are in the process of setting up webinars and meetings with our international communities and we will update the list below as we confirm dates and times. Would you like to host a webinar, call, podcast or something else? If so please contact Ruth directly at ruth.cheesley@mautic.org.

Ruth and the entire Mautic Leadership team will be available in a livestream event, where they will talk about the changes and answer your questions – Friday, 22nd May at 1500hrs UK time

Les mises à jour de la communauté Mautic en Français avec Ruth Cheesley, nouvelle Project Leader – Wednesday, 27th May 2020 at 1000hrs UK time

Deutschsprachiges Mautic Community Update und Fragerunde mit Ruth Cheesley (neuer Project Lead) – Wednesday, 27th May 2020 at 1130hrs UK time

Últimas noticias, preguntas y respuestas sobre la Comunidad Mautic con Ruth Cheesley, la nueva leader del proyecto – Wednesday, 27th May 2020 at 1630hrs UK time

Regular Office Hours

Join this open call with Ruth Cheesley, Mautic Project Lead, once a fortnight in each timezone.

Ask product questions, suggest feature requests, lodge complaints, offer praise, share ideas, discuss recent blog posts, or talk about good or bad experiences using Mautic.

Anything that’s on your mind is fair game. I’m here to listen, share, and be available to help in any way I can.

Office Hours with Ruth Cheesley EMEA/Americas – Fortnightly from 28th May at 1500hrs UK time Link to join: https://acquia.zoom.us/j/98583607751 (Password: 815478)

Office Hours with Ruth Cheesley APJ – Fortnightly from 3rd June at 0700hrs UK time Link to join: https://acquia.zoom.us/j/91119231380 (Password: 502111)