Governance model v1 (archive)
Following the acquisition of Mautic Inc. by Acquia in May 2019 which included all assets relating to the Mautic community, a governance model was proposed and adopted following a period of community consultation.
Read more in the initial proposal and the subsequent follow up which addressed questions raised by the community. Subsequent adaptations were made during the Community Summit in November 2019 to arrive at the model outlined below.
Further updates were made in May 2020 with the change in project leadership and introduction of the Founder role.
The aim of the governance model is 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.
Community Structure
The structure of the community includes five teams, each led by a Team Lead and Assistant Team Lead, with working groups under them.
Each of these teams are responsible for establishing and overseeing working groups within the team. 
The Mautic Community Governance Model
Initially the team leadership roles will be self-elected from within the team. See Leadership Team for the current post holders.
Going forward the 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.
Delegation of resources
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.
Term durations and elections
Team Lead, Assistant Team Lead, Working Group Lead and Assistant Working Group Lead positions will have a specified initial term (dependent on the team) with a review at the half way point.
Terms will be staggered to avoid elections for multiple leadership roles happening at the same time.
Steering Groups
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.
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 currently are the Mautic Project Lead, Project Sponsor, Technical Community Lead and Community Specialist. 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. The Project Lead will retain a casting vote.
The Community Council will operate more on consensus than on votes, seeking agreement from the people who will have to do the work.
The role of Project Lead has the ability, with regard to Acquia employees, to ask people to work on specific projects, specific feature goals and specific bugs. They also have 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
Finance and budget
Mautic now uses the Open Collective to manage its finances.
Each year, team leads make a budget request for the coming year, which are reviewed by the Community Council. A Community Budget is prepared and adopted by the council.
Transactions on the Open Collective are open and visible to all.
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 (who form part of the Product 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
The Project Lead elects members into any other group, oversees project vision and direction, and makes decisions on proposed changes. The Project Lead listens to the counsel of trusted advisors and individuals respected for their contributions to Mautic. The Project Lead is appointed by Acquia.
The full responsibilities and expectations of the Project Lead are detailed [here][project-lead-definiton].
The Technical Community Lead
The Technical Community Lead supports the technical growth and development of the Mautic project and community. This role is pivotal in empowering other developers in our community, and setting up the foundations for them to become active contributors.
They are the face of the developer community, and a central point of call for any technical issues.
The Technical Community Lead also has primary responsibility for supporting in-person sprints, releases, and being a bridge between the community and Acquia from the technical perspective.
The full responsibilities and expectations of the Technical Community Lead are detailed here.
The Project Founder
Our Project Founder is DB Hurley. He remains an ambassador for the Mautic project, and may be asked to speak and represent the project at events. There are no responsibilities or expectations in the governance model specific to the Project Founder. They do not have any voting rights, or any involvement in the governance model.
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.
Tiger Team Leaders
The Tiger Team leaders are individuals who have a level of responsibility over a particular area of the project (for example a particular Mautic feature or bundle). Tiger Team leaders are appointed by the Project Lead. Core contributors who have made substantial contributions may apply for Tiger Team Leader 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 one 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: .png)
- 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..png)
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: .png)
Credits:
Inspiration and examples have been drawn from several Open Source projects and governance models in preparing this proposed model, including: DrupalUbuntuJoomla
Found errors? Think you can improve this documentation? edit this page