Managing contributions in an open source project

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!