Managing contributions in an open source project Ruth Cheesley and Dennis Ameling

Ruth Cheesley Dennis Ameling Mautic Project Lead Assistant Team Lead, Product Team @RCheesley @DennisAmeling

Looking back a few years

There was: ● No governance structure for the project and community outside of code governance ● No established teams or working groups ● Significant dependency on Mautic Inc. for features, fixes, code reviews and releases

● People being unclear how to contribute, what the process was, and how they could get involved ● A lack of clarity on how the community could have a say in the future direction of the project ● A large backlog of PR’s and issues accumulating as Mautic Inc. stepped back for managing community releases This resulted in:

Start with governance

Establishing a clear governance model took time!

What have we learned from the last 12 months?

Be transparent and welcoming to all

Efficiently involving developers ● There’s something for everyone ● Tier 1 (Easy): small fixes ● Tier 2 (Medium): minor features or enhancements ● Tier 3 (Hard): major changes touching multiple parts of Mautic ● The key is to make it a smooth process for folk to get started (code + review)

Be quick and consistent with your responses ● Contributions need to be addressed in a fair time period ● If that hasn’t happened, be honest and do your best to make it right ● Make sure that you get back to people if they ask for help ● Document every step of the contribution journey in extreme detail!

Build a diverse Product Team (WIP!) ● Technical folk to review PR’s and check code quality ● Welcoming committee to meet and greet contributors ● Marketeers - people who actually use the tool ‘in the world’ ● Documentation writers, media creators ● UI / UX / Accessibility experts ● Diversity in every sense of the word helps us serve our users better

Ensure everybody understands the importance of their role ● Ensure they understand how they add value to the team ● Encourage contributors to specify how much time they are able to commit ● Set expectations appropriately and empower contributors to push back if they are taking on too much ● Recognise that being a contributor is voluntary, but not without obligation

Take a firm but fair approach to triaging old PR’s and issues ● Timebox expected response times and inform authors what will happen if they do not respond ● Consider having another contributor pick up any PR’s that are valuable but the original contributor is not responding (remember to always credit the author) ● You may have to spend time yourself testing issues to see if they persist!

Create a release schedule, and stick to it 3.1.2 3.2.1 26 October 2020 28 December 2020 3.2.0 3.2.2 30 November 2020 25 January 2021 ● Creates a ‘beating heart’ of the project ● Sets expectations for contributors ● Allows prioritisation of bug fixes and features ● Allows users to plan around release dates for maintenance windows

Encourage organisations to enable their teams to contribute ‘on the job’ ● It is not practical to expect a project to scale and grow at a decent pace when everybody contributing is a volunteer ● Burnout is sadly very common in Open Source - often as a result of people contributing in their free time ● Organisations are often willing to enable their teams to contribute if they can see how, where, when, and most importantly, why.

Example: Reviewing code contributions (PRs) ● Sometimes technical knowledge is needed for this, sometimes not ● We’re working hard to ensure that both users (marketers) and developers can easily test code contributions

Where are we now?

Community engagement is growing Mautic Inc. acquisition announced Source: All community engagement (Git/Github, Slack, Forums, Meetup) excluding Acquia and Mautic Inc. employees https://dashboard.mautic.org/goto/5350ad97a5147dcf3374408aafc24aee

Dealing with technical debt We have made a good amount of progress so far and with each release we are closer to our end-of-year target of under 100 open PR’s and issues. Jan 2020 Jul 2020 Sept 2020 932 Open Issues 444 Open Issues (-52%) 280 Open Issues (-37%) 332 Open PRs 218 Open PRs (-35%) 209 Open PRs (-4%) Dec 2020 Targeted Open Issues <100 Targeted Open PRs <100

Automated tests ● Imagine having to manually test EVERY part of Mautic on EVERY change in the codebase (large or small) ● Computers are good (and fast!) at repetitive testing ● This is where automated tests come in

The importance of automated tests ● Ensures functionality keeps working as it should ● Enhances the overall stability of the product ● Motivates developers to write high-quality code ● Currently, ~32% of Mautic’s backend is covered by automated tests

Mautic and automated tests ● Every Pull Request (PR) should either keep test coverage the same or increase it ● Starting to write E2E (end-to-end) tests to simulate actual users interacting with the product ● Gradually increase test coverage ● Goal: make Mautic more reliable

Questions? Thank you!