The Mautic community continues to grow, and with growth comes a need to develop a governance model to enable and empower volunteers. We want to encourage the community to take up responsibilities and have a say in the direction of the Mautic Open Source project, while working collaboratively with Acquia.
In acquiring Mautic Inc., Acquia has made a firm commitment to supporting and accelerating the growth of the Mautic community.
What follows is our proposal for developing a governance model which enables volunteers in the community to step up and form Working Groups and Teams around key areas.
This model ensures that the community is able to become a steward of the resources owned by Acquia relating to the community. It also demonstrates how Acquia will be involved in supporting and funding the growth of the community and ongoing future development of the Open Source project.
Community structures
Project Lead DB Hurley had previously outlined a proposed structure for the community, from which we have developed an expanded model to incorporate Acquia’s role in supporting the community post-acquisition.
The structure includes five teams, each led by a Team Lead and Assistant Team Lead, with working groups under them. Five teams were proposed:
- Product
- Community
- Events
- Law & Finance
- Marketing
Each of these teams will be responsible for managing and overseeing working groups beneath them. Team Lead and Assistant Team Lead positions will be selected by the Project Lead from the community-elected Working Group Leads and Assistant Working Group Leads.
Acquia will delegate stewardship of assets to the relevant Team Lead, who will be responsible for managing them on a day-to-day basis and ensuring appropriate, responsible use of the assets.
As an example, the Marketing Team Lead will be responsible for owning the content shared on community social media channels and in the community newsletter, in line with guidance from Acquia and using their PACSI matrix (see below) to determine who needs to be informed or consulted throughout the process.
Team Lead, Assistant Team Lead, Working Group Lead and Assistant Working Group Lead positions will have a 12 month term with a review at six months.
Team Leads and Assistant Team Leads will form the relevant Steering Group assigned to their teams. The steering groups are an opportunity for the Team Leads of related areas in the community to work together on larger projects such as an overall communications strategy, product roadmap/strategy and budget preparation, escalating up to the Community Council and receiving feedback from the Council as appropriate.
This structure is a solid base from which to work, and we believe that the Community Council will help to facilitate effective, long-term collaboration between Acquia and the Mautic community. See below for an outline of how the proposed structure would work with example working groups.
The four Community Representative positions on the Mautic Community Council will be nominated by the community from the Team Leads and Assistant Team Leads who wish to be considered for nomination. Community representatives on the Mautic Community Council will have a term of 12 months.
It is important to understand that this structure is not expected to be immediately in place in its entirety, but that community will begin moving toward such a structure over time pending adoption of this proposed model.
Implementing this structure
Team Leaders and Assistant Team Leaders will be appointed by the Project Lead with a term of 12 months. The community will commence with formalising a small number of Working Groups in areas where they are already informally in place and gradually expand as needed to spin up further working groups.
Working Group Leads and Assistant Working Group Leads will be community-elected, and can either by Acquia employees or not, depending on what the community decides. In the event that there are insufficient community volunteers, the Team Leads can work with Acquia to see if Acquia is able to appoint a paid employee to the role to make sure the work gets done.
The Team Leader of Legal & Finance will initially be an Acquian.
The Mautic Community Council
There will be a Community Council of 4 Acquians and 4 Mauticians to discuss issues which impact the Open Source project as a whole.
The four Acquians will initially be the Project Lead, Project Sponsor, Community Manager and Head of Communications. These roles will be appointed by Acquia the Project Sponsor and may vary over time subject to the needs of the Council.
The Community Representatives will be elected on an annual basis by the community from the Team Leads and Assistant Team Leads who choose to stand for nomination. DB Hurley will retain a casting vote as Project Lead.
The Community Council will operate more on consensus than on votes, seeking agreement from the people who will have to do the work.
In the role of Project Lead, DB Hurley has the ability, with regard to Acquia employees, to ask people to work on specific projects, specific feature goals and specific bugs. He also has a casting vote on the Product Steering Group and the Community Council, should it come to a vote. This capacity is not used lightly.
We believe that the community functions best when it can reach broad consensus about a way forward. However, it is not uncommon in the Open Source world for there to be multiple good arguments, no clear consensus, and for open questions to divide communities rather than enrich them. The debate absorbs the energy that might otherwise have gone towards the creation of a solution.
In many cases, there is no one ‘right’ answer, and what is needed is a decision more than a debate. The project lead acts to provide clear leadership on difficult issues, and set the pace for the project.
Some examples of how this casting vote might be called into effect could include:
- Decisions without a consensus – any time there is an equal split on a decision, the Project Lead may use their casting vote to decide the vote
- Technical decisions – for example frameworks to adopt or key strategic objectives – where there is no clear consensus from the community, or the suggestions being made could be detrimental to the long term vision for the project, the Project Lead can determine the path to be taken
- Feature prioritisation – if a particular feature needs to be prioritised the Project Lead can instruct Acquia employees to work on developing that feature
Delegation and teams
The Community Steering Group and Product Steering Group, in turn, delegate their responsibilities through teams that span both the globe and a vast diversity of disciplines.
The Project Lead will appoint Team Leaders from among the community-elected Working Group Leads to ensure that the best people are recognised as leaders, decision makers and experts to get the job done.
The aim of the Community Council is not to impede progress but to engender a transparent, consultative approach in major issues that require engagement between the community and Acquia.
Finance and budget
In the interim stage, any budgets required by the community (for example to organise a Community Sprint) would be proposed as an individual business case via the Team Leads and reviewed by Acquia.
Once the structure becomes established, the Team Leads will be responsible for reviewing their team’s spend over the previous year and preparing a budget for the following year, which will be proposed to the Mautic Community Council. The Council will review all requests and prepare a Community Budget Proposal which will be presented to Acquia for approval.
This budget would, once approved, be allocated by Acquia and managed by the Team Leads, with support from the Project Lead and Community Manager.
About the Mautic Acceleration Team (MAT)
You may have noticed a mention of establishing a Mautic Acceleration Team at Acquia – this is in the very early stages but we felt this was an appropriate time to share more about our vision for this team.
What will they do?
The MAT will function in the same way as the Drupal Acceleration Team (DAT) and will add speed, momentum, planning, scheduling, organization to Mautic core efforts. They will ensure Mautic has a future by thinking two years ahead.
How will they do it?
The MAT will deliver hard-problems engineering work, address technical debt, accelerate initiatives, and push Mautic forward into new areas. They will manage the community and help fix problems with the core and with dependencies. They will manage minor, patch, and security releases. They will provide Mautic core product, framework, and dependency management.
The MAT is currently in the early days of forming but we anticipate it being involved with several initiatives including coordinating with the community in developing a new email and landing page builder, improving the Mautic dependencies, and immediately responding to security issues as they are raised.
About Mautic’s Core team
Development is open and available to any member of the Mautic community. All fixes and improvements are done through pull requests to the code. This code is open source and publicly available. Pull requests and code submissions are decided upon by the release leader and the core team. When a decision is not clearly evident then the following voting process will be implemented.
Who are the Mautic core maintainers and what do they do?
The Mautic Core team is divided into 5 groups. Each team member can belong to only one group at a time. Any privilege listed for a particular group is also available to all higher priority groups. The Mautic Core groups, in descending order of priority are as follows:
The Project Lead – DB Hurley
The project lead elects members into any other group, oversees project vision and direction, and makes decisions on proposed changes. The project leader listens to the counsel of trusted advisors and individuals respected for their contributions to Mautic. The Project Lead is appointed by Acquia.
Core Team
Release Leader
The release leader is responsible for a particular major version release and implementing the project’s vision as it relates to a release. This role may be held by a Mautician or an Acquian, and is appointed by the Project Lead.
Core Committers
The core committers are a small team that review proposed changes and have commit access to the core repository. These core committers are selected by the Project Lead based on their previous experience and project involvement.
Maintainers
The maintainers are individuals who have a level of responsibility over a particular area of the project (for example a particular Mautic Bundle). Maintainers are appointed by the Project Lead. Core contributors who have made substantial contributions may apply for maintainer status by writing to the Project Lead.
Core Contributors
Core Contributors are those individuals who assist in other areas of the project including patch contributions, documentation, translations and other key services for the Mautic core. Contributions are peer-reviewed and decided upon by the Core Committers, Release Leader, or Project Lead. Code contributions can be submitted by anyone.
Voting Policy
Votes are cast by all members of the Core Team. Votes can be changed at any time during the discussion. Positive votes require no explanation. A negative vote must be justified by technical or objective logic. A Core Team member cannot vote on any code they submit.
Merging Policy
The voting process on any particular pull request must allow for enough time for review by the community and the Core Team. This involves a minimum of 2 days for minor modifications and a minimum of 5 days for significant code changes. Minor changes involve typographical errors, documentation, code standards, minor CSS, javascript, and HTML modifications. Minor modifications do not require a voting process. All other submissions require a vote after the minimum code review period and must be approved by two or more core members (with no core members voting against).
Core Membership Application
Core Team members are based on a form of meritocracy. We actively seek to empower our active community members and those demonstrating increased involvement will be given everything needed for their continued success.
Core Membership Revocation
A Mautic Core membership can be revoked for any of the following reasons:
- Refusal to follow the rules and policies listed herein
- Lack of activity for the previous 6 months
- Willful negligence or intent to harm the Mautic project
- Upon decision of the project leader
Revoked members may re-apply for core membership following at 12 month period.
Assigning responsibility
The following Responsibility Assignment Matrix illustrates how decisions might be made in different scenarios that might arise in the community.
While the most common format for such matrices is RACI (Responsible, Accountable, Consulted, Informed), we have decided to adopt a variation used by the Drupal community called PACSI (Perform, Accountable, Control, Suggest, Informed) which more closely matches the collaborative nature of our culture.
Key
Perform (P)
The role(s) that carry out the activity.
This is placed in the column of the role(s) that predominantly drive those changes, but this doesn’t preclude other roles from also carrying out work.
Accountable (A)
The role(s) ultimately accountable for the correct and thorough completion of the task, and often the ones who delegate the work to the performer (P).
Control (C)
The role(s) that review the result of the activity (other than the Accountable, A). They have a right of veto and their advice is binding.
Suggest (S)
The role(s) consulted for advice based on their expertise. They provide non-binding advice.
These are role(s) whose input via two-way communication is actively sought, though this does not preclude others from making suggestions.
Informed (I)
The role(s) that must be informed of the result of the activity.
Examples of PACSI Matrices
Note that if a change includes multiple rows in this table, there will be multiple roles involved.
Below is an example of a matrix that might be used within the Product Team:
* The Project Lead may proactively make or override these decisions if they deem it necessary.
Each team would develop its own PACSI relating to their own area of stewardship, created in collaboration with Acquia via the Community Manager and Product Lead.
As an example [provided to illustrate how this might work, rather than using factually correct responsibilities], the Marketing team might develop the matrix below with examples of tasks that arise within their team, and clarity around who is responsible for making decisions, taking actions, etc.
This would be developed and revisited as the team grows and responsibilities are delegated to them.
And the Legal team’s might look like this:
Credits:
Inspiration and examples have been drawn from several Open Source projects and governance models in preparing this proposed model, including:
Drupal
Ubuntu
Joomla
