Governance model

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.

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. Image of the governance model detailing teams, working groups, steering groups and the community council

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 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

Finance and budget

In the interim stage, any budgets required by the community (for example to organise a Community Sprint) are to 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 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 – 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: Example Product Team PACSI

  • 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.
Example Marketing Team PACSI

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: Legal Team PACSI

Credits:

Inspiration and examples have been drawn from several Open Source projects and governance models in preparing this proposed model, including: DrupalUbuntuJoomla