Mautic Governance Model v2.0
Welcome to Mautic.
Within the project, Mautic governance is driven by Mautic’s core values:
Openness and Transparency - This includes being transparent with information, open to discussion, and accountable.
Integrity and Respect - This includes honesty, fairness, ethical behavior, and mutual respect.
Engagement and Representation - This includes welcoming diverse perspectives, seeking feedback, and actively engaging with the community.
Action and Accountability - This includes taking action to achieve project goals, being accountable for project outcomes, and valuing a project over individual interests.
Fairness and Inclusivity - This includes creating a level playing field, ensuring equal opportunity, and being inclusive of people and perspectives.
Figure: Visual representation of the governance model.
1. Membership
1.1 Basic member
To join the Mautic community, a person signs up and engages on one of the community channels, which include Slack, Forums, GitHub, Jira, Transifex, and the Knowledgebase. Joining the community is open to anybody, and they automatically become a basic member.
Basic members don’t have voting rights. They can attend and contribute to discussions and decision-making processes but may not vote and aren’t counted for the purposes of a quorum at meetings of the members.
Unless such member affirmatively declines such right in writing, any existing member of the Mautic Community shall automatically become a Basic Member without any further action on the part of such member.
1.2 Voting member
There are two ways to gain voting rights: financially and practically contributing to Mautic.
1.2.1 Financial contributor
Financially supporting the Mautic project as an individual, at a minimum rate determined by the Community Council each year in the annual General Assembly - adjusted based on the member’s home location using the Big Mac Index - is the first route to having voting rights.
The base rate for someone living in the United States is $100 per year.
Rates will be published publicly, including a spreadsheet with the amount per year by countries listed in the Big Mac Index. This will be proposed for adoption as a motion each year at the General Assembly.
Where countries aren’t listed, an approximation should be made based on the price of a Big Mac.
Membership must be paid annually in one single payment using the General Assembly Membership - Individual tier on Open Collective.
Individuals may decide to donate more than the stated amount, but this is the minimum amount required.
Upon paying the required minimum amount, such person will be deemed to be a Voting Member for the twelve-month period following such payment.
1.2.2 Practical contributor
You can become a voting member by supporting the Mautic project through making contributions to official Mautic resources which support the project’s growth.
You qualify as a member through practical contributions if you dedicate at least five (5) hours per month working to support Mautic or the Mautic community - for example, by organizing Mautic events, working on Mautic projects, participating in one of the Mautic working groups, etc.
You also qualify through practical contributions if you dedicate at least five (5) hours per month to working on projects which advance the mission of Mautic by creating or maintaining open source software or resources which are available to the public at no charge.
Members who wish to claim voting rights through this method are required to self-certify via the Practically Contributing Member Self Certification form each year.
The Community Council verifies all membership requests on a monthly basis. They use the Savannah CRM tool to verify engagement within Mautic-owned properties and available tools to verify engagement with external properties.
The name, affiliation, Working Group and Project associations of voting Members will be published to the Mautic membership once a suitable mechanism for doing so has been determined.
The Mautic Community Council reserves the right to reject a new application or revoke an existing membership should it be determined that the self-certification was made in bad faith.
1.2.3 Organization
Organizations can become a member by joining at one of the following tiers:
Community - $1,200/yr
Bronze - $5,000/yr
Silver - $10,000/yr
Gold - $15,000/yr
Platinum - $20,000/yr
Diamond - $30,000/yr
The tiers will be reviewed and set annually at the General Assembly.
Membership must be paid annually in one single payment using the General Assembly Membership - Corporate tier on Open Collective.
Organizations will be entitled to one (1) vote in the same way as individual members.
1.2.4 Honorary member
Some individuals have made substantial contributions to Mautic and may be granted a lifetime membership, known as becoming an Honorary Member.
To be eligible for membership as an Honorary Member, a member must be nominated by any Member of Mautic other than a Basic Member or by a specially created Working Group, which nomination should be based upon certain criteria to be established and adopted by the Community Council and which criteria shall be designed to emphasize extraordinary contributions.
Following such nomination, approval of two-thirds (2/3) of the members entitled to vote, or two-thirds (2/3) of the members of the chartered Working Group, or two-thirds (2/3) of the Community Council, shall be required in order for a member to become an Honorary Member.
Upon election, an Honorary Member shall remain an Honorary Member for the remainder of such person’s natural life, subject to any limiting provisions of this document, and to not have to contribute financially or practically to retain their status. Honorary Members may exercise voting rights at any time, and if they vote, they shall be counted for purposes of a quorum.
1.3 Voting rights
All categories of membership other than Basic Membership have voting rights.
1.4 Changing membership status
Members may convert their membership to Basic Membership or withdraw any tier of membership, including Honorary Member status and Organizational membership, at any point by completing the membership change request form. Refunds aren’t provided for individual or organizational members who are terminated early.
The membership of a member shall automatically be converted to Basic Member status upon the occurrence of any event causing such member to no longer qualify as a member of any membership class other than as a Basic Member.
A member’s membership may be terminated by the Community Council, for example, as a result of a Code of Conduct investigation recommendation, with an affirmative vote of two-thirds (2/3) of the members who are present and eligible to vote at the meeting. This also applies to Honorary Members and Organizations. No refund will be provided for early termination of organizational or individual memberships.
Upon any withdrawal from or termination of the membership of any member, the membership, including all related voting rights, of such member shall be terminated. After a withdrawal or termination of the membership of any member, such former member may reapply for membership in accordance with the application process detailed above and after following any reconciliation process that might be deemed appropriate after termination due to a Code of Conduct breach.
2. Decision making
It’s recognized that the governance model needs to be flexible enough to accommodate the many and varied kinds of decisions that are made in an open source project on a daily basis.
There are, however, some guiding principles that Mautic recommends are followed, which provide alignment with Mautic’s core values.
2.1 General guidelines - timing
As an international community distributed across timelines, making decisions should always take into consideration allowing the people who may have an interest in that decision the time to review and provide feedback.
To facilitate an understanding of how long is needed for making decisions, Mautic considers three types of decisions:
Trivial decisions like which color background to use for a conference event for example would never go to the vote. The team and contributors would just get on with it and make those decisions themselves, deciding on the appropriate time needed for discussion/decision making.
Non-trivial decisions would be things that do require a bit more involvement from others, but they’re generally reversible without major impact. So they don’t need extensive, exhaustive consultation. Some examples might be deciding how many tracks to run at a conference, deciding on who to invite for speakers at an event, or how to solve a problem in a code situation which has a few different options but isn’t going to have a major impact on the application if one is chosen above another.
Significant decisions often need more time to discuss. They usually impact several teams or even the whole project, have a financial impact, and probably aren’t easy to reverse without consequences. For example, which event platform should Mautic use for a conference - this impacts several teams, has a financial impact, and also impacts the wider project - or deciding how to approach a major deprecation in the code base for an upcoming release. In those cases, a longer time box is needed as indicated.
For non-trivial decisions, the discussion should be open for a minimum of 36 hours to ensure that contributors in other timezones have time to review. Consideration should also be given to weekends and other holiday periods to ensure active contributors all have reasonable time to become involved in the discussion process if they wish.
For significant decisions which have a wide impact across the project or reflect a substantial change in a team’s area of responsibility, it’s strongly advised that a longer time box should be employed. Generally speaking, this might be something like two weeks or more to ensure that appropriate communication and promotion of the decisions being taken can happen.
2.2 General guidelines - methodology
Mautic community defaults to using consensus as a means for establishing support for a decision, often using lazy consensus where the motion is considered passed after a time period is elapsed - see Section 2.1 for guidance - if there aren’t any objections.
Sometimes, there may be a need to request a quorum - a minimum percentage of the people who could vote, to turn up to vote. This helps to ensure that such a consensus decision is taken with the majority being involved in coming to that decision.
Any voting member can request a quorum for any decision being made by providing a clear and public statement as to why the community should expect to have a quorum for that decision.
The leadership of the relevant entity to which the decision belongs will consider the request and provide public feedback on their decision for or against a quorum being required. Unless there is reasonable grounds not to, a quorum should be implemented.
3. General Assembly
The General Assembly is where decisions are taken on everything that has to do with the governance of the project. All members other than Basic members are members of the General Assembly.
3.1 Powers of the General Assembly
To elect and remove members of the Community Council and Team Leads
To propose the forming or disbanding of Teams
To adopt pricing tiers for membership
To propose changes to this governance model
3.2 Frequency of meeting
The General Assembly shall meet in ordinary session once a year, ideally at an official Mautic Conference Global event held online, to maximize attendance.
The Community Council may call an extraordinary General Assembly whenever it deems it convenient and must do so when requested by 10% of the members through the Community Hub platform. The Assembly must take place within 30 calendar days of the request.
The Assembly is convened by the General Assembly Working Group - who exist to organize the General Assembly and oversee the voting process - through an open call on the Community Hub platform, which must contain, at a minimum, the agenda, location, and date and time of the meeting at least 15 calendar days in advance.
4. Teams and working groups
4.1 Current teams
The following teams currently exist in the Mautic project as established in the 2019 governance model:
Community Team
Education Team
Legal & Finance Team
Marketing Team
Product Team
4.2 Forming and disbanding teams
4.2.1 Proposal to form a new team
Any member or group of members may propose a Team. In order to propose a vote to approve a Team, the members proposing the Team must first draft a proposed Team charter that at least specifies the purpose of the Team and its relationship to the Mautic project’s mission, the work to be undertaken by such Team, how the members of the Team will be selected, the methods by which the Team will achieve its objectives, the methods of communication to be used by the members of the Team, how, what, and when the Team will report to the membership and/or the Community Council, and how the Team will be managed - including how the Leadership Team will be selected
The Community Council may add new teams to the governance model by a general vote on a ‘whoever turns up’ basis of the whole community using lazy consensus, providing that a clear proposal per Section 4.2.1 has been created and a proto-team established to demonstrate the viability of the team
4.2.2 Proposal to disband an existing team
The Community Council may disband teams by a general vote on a ‘whoever turns up’ basis of the whole community using lazy consensus to disband the team, and with affirmative votes from all existing leadership members of that team, confirming that they wish to disband the team.
On the disbanding of a team, any associated working groups and projects will be documented and distributed amongst other teams.
4.3 Working groups
Team Leads or voting members may establish one or more Working Groups as required to fulfill the tasks of a team or the needs of the project. All Working Groups will sit underneath one of the existing Teams, with the Team Lead being responsible for their budget.
4.3.1 Scope
Each Working Group shall be responsible for the active management of one or more projects identified by their Team Lead or voting members which may include, without limitation, the creation or maintenance of open source software for distribution to the public at no charge, proposing amendments to this governance model, or proposing changes to the operations of the organization. This shall be documented in the Working Group’s charter.
Subject to the direction of the Team Lead and Community Council, the leader of each Working Group shall be primarily responsible for projects managed by such a group, and they may establish rules and procedures for the day-to-day management of projects for which the group is responsible.
The Team Lead under which the Working Group sits shall have the sole power relating to the proposal of funds made available to such Working Groups, approved by the Community Council.
The Community Council may set policies or procedures which apply to Working Groups. These policies or procedures may apply to individual Working Groups, multiple Working Groups, or all Working Groups. The leaders of affected Working Groups are responsible for implementing and adhering to the policies or procedures that apply to them.
4.3.2 Forming and disbanding a working group
Any voting member or group of voting members may propose a Working Group.
In order to propose a vote to approve a Working Group, the members proposing the Working Group must first draft a proposed Working Group charter that at least specifies the purpose of the Working Group and its relationship to the Mautic project’s mission, the expected duration of the Working Group’s existence, which may in some cases be ongoing, the work to be undertaken by such Working Group, how the members of the Working Group will be selected, the methods by which the Working Group will achieve its objectives, the methods of communication to be used by the members of the Working Group, how, what, and when the Working Group will report to the membership and/or their associated Team Lead, and how the Working Group will be managed, including how the leadership will be selected.
Where a Working Group is expected to be created for a fixed duration, clear exit criteria must be determined in the charter at whose attainment the Working Group will be disbanded.
The Community Council may, by vote, dissolve a Working Group at any time with agreement of the Team Lead under which the Working Group sits and any existing Working Group leaders.
At disbandment, any existing resources and open projects will transfer to the team under which the Working Group sat.
4.4 Leadership
4.4.1 Eligibility
Any member of the community who is eligible to vote and who doesn’t have any outstanding, unresolved Code of Conduct breaches or investigations may nominate themselves, or be nominated with consent by another, to stand for election to the role of Team Lead or Assistant Team Lead, Working Group Lead or Assistant Working Group Lead.
4.4.2 Voting
Teams and Working Groups will elect through ranked choice voting on a ‘whoever turns up’ basis, a Lead and Assistant Lead.
4.4.3 Terms
Leaders will have a three year term. Where the expected duration of a Working Group is less than three years - for example, with a short-lived Working Group established for a specific purpose - the terms may match the expected duration of the Working Group.
A ladder-like structure sees an Assistant Team Lead taking over from the Team Lead, with the Team Lead becoming Assistant Team Lead before they’re replaced by an incoming Assistant Team Lead. Example:
Year 1
Person A - Team Lead
Person B - Assistant Team Lead - previous Team Lead
Year 2
Person A - Team Lead
Person C - New Assistant Team Lead
Year 3
Person C - Team Lead
Person A - Previous Team Lead
During the second year of a term, an election is held and a candidate is selected as being the first eligible candidate with the highest number of votes
A three-month handover period will see the incoming leader shadowing the outgoing leader
A three-month outgoing period will see the outgoing leader being available to assist the new leader as required
4.4.4 Removal or resignation of Team Leadership
A leader may resign at any time upon written request to the Community Council. Furthermore, any leader or the entire Leadership of a Team may be removed - with or without cause - by a vote of the majority of the members entitled to vote.
A leader will be automatically removed from their leadership role in the event that such leader ceases to be a member of the community for any reason. A representative may also be removed from their leadership role as a result of an investigation finding that there has been a breach of the Code of Conduct for which action is required in the form of removing their leadership roles.
5. Council
5.1 Function
The operational and fiscal management of the Mautic project shall be under the direction of the Community Council.
The Community Council shall, among other things:
Determine and regularly report on the budget of the project. This includes the budgets of any team, committee, or Working Group, which will be determined on an annual basis in collaboration with leaders of those entities
Manage all fiscal operations and relationships, including the approval of expenditures
Manage any employees and contractors working for the Mautic project
Monitor and regularly report on the health of the project as a whole
Lead on strategic fundraising planning to support the long-term strategy and growth of Mautic, in collaboration with the fundraising working group
Communicate and drive progress on the project’s long term strategy
Manage, safeguard, and enforce the trademarks and brand assets of the Mautic project, in collaboration with the Legal and Finance Team
Review and sign any contractual agreements relating to the Mautic project
Review, document, communicate, and adopt any such policies and procedures as may be determined necessary by any team, committee, or Working Group
Execute any recommendations in relation to breaches of the Code of Conduct
The Community Council meets on a regular basis to review and manage the operational and fiscal needs of the Mautic project.
Notes of the meetings are shared publicly, and agendas for the meeting are also made public in advance of the meeting.
Note that members of the Community Council are herewith referred to as Community Council members or representatives.
5.2 Eligibility
Representatives are elected on a yearly basis to the Council from the wider community by a referendum vote using ranked choice to determine the elected representatives. Voting is open to all those eligible to vote at the time of the election.
Any member of the community who is eligible to vote and who doesn’t have any outstanding, unresolved code of conduct breaches or investigations may nominate themselves, or be nominated with consent by another, to stand for election to the Community Council.
They will provide a proposal for review by the members, which must disclose any such affiliations as listed in Section 5.2.1 and may include any further information as to their suitability for the position.
The Community Council should be representative of the diverse community that they serve, and the community should ensure that their nominated representatives have the complement of skills and experience that are suited to guide and lead the project. It’s important, therefore, for potential candidates to clearly identify the skills and expertise that they bring to the Community Council in their proposal.
5.2.1 Disclosure of affiliations
A person running for the Community Council must make any affiliation - other than to Mautic - known to the members at the point of nomination. If the affiliation of any representative changes while serving on the Community Council, such new affiliation shall be immediately made known to the membership. The Community Council will maintain a publicly available list of registered affiliations, which must be referred to in any decision-making involving a third-party organization.
For the purposes of this section, a representative or prospective representative has an affiliation if that person is an employee, officer, or member of the Board of Directors of an entity; if that person has a significant consulting relationship with an entity; or that person owns at least 1% of the equity or debt, or derivatives thereof, of an entity.
5.3 Compensation
Members of the Community Council shall not be compensated for their duties as a representative. Reasonable travel expenses will be covered where they can’t be covered by other means - for example, corporate sponsorship or event funds - to attend the annual in-person Community Council meeting.
Members of the Community Council may be compensated for service as an employee or contractor of Mautic outside of their role on the Community Council, providing that they’re absent from any discussions and voting in the Community Council relating to or directly impacting their role.
5.4 Number
The Community Council shall initially have seven (7) representatives. Thereafter, the number of representatives is fixed until a change by a vote of the voting members at an annual meeting of members to another odd number of representatives greater than three (3). Any votes to change the number of representatives during a meeting of the members shall be deemed to take effect before the election of any individual representatives during the same meeting.
5.5 Election
At the 2023 annual meeting of members and at each annual meeting thereafter, the voting members shall elect representatives sufficient to fill seven (7) at-large representative seats.
At-large representatives shall hold office for a term of up to three years, with each year being counted as complete at the next succeeding annual meeting.
There shall be three cohorts of representatives elected in the 2023 election.
Cohort A representatives shall have an initial term extending for three (3) years beginning after the 2023 election of representatives.
Cohort B representatives shall have an initial term extending for two (2) years beginning after the 2023 election of representatives.
Cohort C representatives shall have an initial term extending for one (1) year beginning after the 2023 election of representatives.
For the 2023 election only, the three candidates receiving the highest number of votes shall be designated Cohort A representatives, the two receiving the next highest number of votes shall be designated Cohort B representatives, and the two receiving the third highest number of votes shall be designated Cohort C representatives.
5.5.1 Terms of office
Each at-large representative shall hold office for the term for which they’re elected and until their successor shall have been elected and qualified or until their earlier resignation, removal, or death.
Upon completion of the term beginning after the 2023 elections, representatives shall be elected for a three-year term unless they’re replacing a representative who resigned or was removed, in which case such replacement representatives shall be elected to a term sufficient to complete a three-year term as measured from the term of the original cohort.
Replacement representatives shall be chosen in order of the number of votes received, with the longest terms of service being allocated to candidates according to the number of votes received.
Persons elected as at-large representatives are considered to be seated in order from the most votes received to the least. If a person who would otherwise be elected withdraws or becomes ineligible before that person is seated as a representative, then the person receiving the next highest number of votes is selected.
5.6 Removal or resignation of representatives
A representative may resign at any time upon written request to the Community Council. Furthermore, any representative or the entire Community Council may be removed - with or without cause - by a vote of the majority of the members entitled to vote for the election of representatives or as otherwise provided in the governance model.
A representative will be automatically removed from the Council in the event that such representative ceases to be a member of the community for any reason. A representative may also be removed from the Community Council as a result of an investigation finding that there has been a breach of the Code of Conduct.
A majority of the number of representatives fixed in accordance with this governance model shall constitute a quorum for the transaction of business. The vote of a majority of the representatives present at a meeting at which a quorum is present shall be the act of the Council.
5.7 Executive and other committees
The Community Council, by resolution adopted by a majority of the full Council, may designate an Executive Committee and such other committees consisting of three (3) or more representatives as determined by the Council from time to time.
Each committee, to the extent provided in such authorizing resolution, shall have and may exercise all the power and authority of the Council in the management of the business and affairs of the organization, except such committee shall not have the power or authority to amend this governance model or to approve or recommend to the members any action which must be submitted to members for approval under this model.
Any Executive Committee established by the Community Council shall be composed exclusively of Community Council representatives. The rights and composition of any Executive Committee shall be established by the motion establishing such committee.
Any member serving on an Executive Committee or any other committee shall cease to be a member of the committee upon the occurrence of any event whereby such member ceases to be a Community Council representative.
A member wishing to resign from a committee may do so at any time upon written notice to the Community Council. Furthermore, any member of a committee may be removed - with or without cause - by a vote of the majority of the Community Council or as otherwise provided in the governance model.
The Community Council may resolve to nominate a representative to serve as an alternate to any committee member who is absent from a meeting of the committee or who has ceased to be a member of the committee.
The members of a committee may - whether or not they constitute a quorum - unanimously appoint a member of the Community Council to act in the place of a member who is absent or who has ceased to be a member of the committee.
5.8 Role of Project Lead
The Project Lead is appointed by the Community Council to lead the Mautic Community in implementing the vision and strategy of the Mautic project - as set in collaboration with the Community Council - on an operational level, to increase velocity, and to help the organization realize its potential by specifically focusing on it.
The most important aspect of the role is to enable Mautic to succeed and, more specifically, to:
Create a vision for the project and determine a strategy in collaboration with the Community Council
Inspire volunteers and contribution in all areas
Enable and create structures and processes that will support community contribution
Facilitate, but also be a part of, high-level decision-making - for example, strategic decisions - in the Mautic Community Council
Have a casting vote in the Mautic Community Council and other situations within the community where a tie-break situation may need resolving
Represent Mautic in public
Provide deep knowledge of all areas of the product, and also of the industry
Ensure that the community teams are on track, removing bottlenecks, and addressing any conflicts that hold back progress
Generally, lead in the best sense of the word
They’re appointed and managed by the Community Council.
5.9 Place of meetings
Regular and special meetings of the Community Council and any committee are held by teleconference or other means of communication whereby all participants can hear each other at the same time.
One annual meeting of the Community Council will happen in-person, at the location of and in advance or following the annual Mautic Conference.
5.10 Time, notice and call of meetings
Regular meetings of the Community Council shall be held within seven (7) days of the annual meeting of members and at such times thereafter as the Community Council may fix.
No notice of regular Community Council meetings shall be required, but it’s recommended that they’re shared in advance of the date with a full agenda of what’s being discussed.
Special meetings of the Community Council shall be held at such times as called by the Council or any two (2) Community Council representatives.
Written notice of the time and place of special meetings of the Community Council shall be given to each representative at least two (2) days before the meeting.
Members of the Community Council may participate in a meeting of the Council or of any committee designated by the Council by conference telephone, internet voice conference, or similar communications medium by means of which all persons participating in the meeting can hear each other at the same time. Participating by such means shall constitute presence in person at a meeting.
5.11 Actions without a meeting
Any action required or permitted to be taken at a meeting of the Community Council or of any committee thereof may be taken without a meeting if all the members of the Council or committee, as the case may be, consent thereto in writing or by other electronic means, and such consent is filed with the minutes of the proceedings of the Council or committee. Such consent shall have the same effect as a unanimous vote.
5.12 Conflicts of interest
No contract or other transaction between the Council and one or more of its representatives or between the Council and any other corporation, partnership, association, or other organization in which one or more of the representatives of the corporation are directors or officers or are financially interested, shall be void or voidable solely because of such relationship or interest or solely because such representative or representatives are present at or participate in the meeting of the Council or a committee thereof which authorizes, approves, or ratifies such contract or transaction or solely because their votes are counted for such purpose, if:
The material facts as to the representative’s relationship or interest and as to the contract or transaction are disclosed or are known to the Council or committee, and the Council or committee in good faith authorizes, approves, or ratifies the contract or transaction by the affirmative votes of a majority of the disinterested representatives, even though the disinterested representatives be less than a quorum, or
The material facts as to their relationship or interest and as to the contract or transaction are disclosed or known to the members entitled to vote thereon, and the contract or transaction is specifically approved in good faith by the vote of such members.
5.13 Limits of co-affiliation of representatives
No more than two (2) of the members of the Community Council may share a common affiliation as defined in Section 5.2.1. If the number of co-affiliated representatives goes above the limit due to a change in employment or a corporate acquisition, then, unless otherwise agreed between the co-affiliated members, the longest-serving members of the Community Council sharing that affiliation must resign before the next meeting of the Community Council to bring the total number of co-affiliated representatives below the limit.
A person who would bring the Community Council above the limit on co-affiliation is ineligible to be seated or appointed.
For purposes of this Section, a common affiliation includes all organizations that - directly or indirectly through one or more intermediary controls - are controlled by or are under common control with the other entities declared as affiliations by other members of the Community Council.
6. Contributors, Maintainers, and the Core Team
6.1 Contributors
Contributors are people who contribute their work to Mautic. This includes but isn’t limited to:
Code contributions,
Writing documentation,
Submitting bug reports,
Other issue reports,
Reviewing PRs,
Participation in technical as well as non-technical discussions,
Organizational considerations.
Code contributions are very welcome. They’re the life-blood of Mautic’s open source project. In order to streamline and harmonize code quality, contributors must follow the contributing guidelines.
Contributors may be associated with organizations - by employment or otherwise - who have a vested interest in Mautic or may be individuals who have their own personal stakes in Mautic. Mautic calls these organizations and individuals ‘stakeholders’ throughout this section of the governance model to summarize them.
6.1.1 Expectations of contributors
Be empathetic and respectful to the reviewers. Reviewing a change can be hard work and time-consuming.
Use the PR template in its entirety and provide very clear, step by step instructions on how to reproduce the bug you’re fixing - if it’s a bug fix - or what the feature is you’re adding - if it’s a feature - and how your contribution should work. Screenshots and screen recordings help enormously.
Don’t assume the reviewer is a developer. They may be a marketer helping with a user review.
Keep commits small when possible and provide reasoning and context when submitting changes. Reviews go smoother if you make the reviewer’s job easier.
Be responsive when changes are requested by the reviewer. It’s easier to re-review the modified changes if they’re completed shortly after the original review.
Ask for clarification if you are confused by a suggested change.
Speak up if your contribution appears to be stuck for more than a week. Post it in the #t-product on Slack and ask for assistance to move it forward.
6.2 Maintainers
Among the contributors to Mautic, some people have maintainer status, which consists of elevated write access to the GitHub repository and additional duties. This is an important role that carries much responsibility, so Mautic has quite strong processes around adopting new maintainers.
6.2.1 Expectations and duties of maintainers
Be an active reviewer and participant.
Know which changes are likely to be controversial, and work to resolve the controversy as early as possible.
Know when a change needs more reviewers involved.
Add the relevant Tiger Team to reviews when appropriate.
Ensure the review of a proposed change is thorough, both user testing and code review.
Point out when a contribution appears to be stuck and explain in clear steps how to move forward.
Assist with the authoring of release notes.
6.2.2 Who are the current maintainers?
The current list of active maintainers can be found on the Mautic Project Maintainers list page.
Maintainers are people who care about Mautic and want to see it grow and thrive. A maintainer does more than make changes to code. They have demonstrated their ability to collaborate and organize with the team, get the most knowledgeable people to review code or documentation, contribute high-quality code and documentation, as well as follow through to fix issues in code or tests.
Contributing to Mautic doesn’t make you qualified to be a maintainer; it’s about building trust with the current maintainers of the project and being a person that they can depend on and trust to make decisions in the best interest of the project, with personal views and preferences being put aside.
6.2.3 How do people become a maintainer of Mautic?
The saying “If you want to become a maintainer, behave like a maintainer” holds true at Mautic. If you follow this advice, then rest assured that the Core Team will notice, and maintainer role will seek you out rather than the other way around.
Here are some ways that you can work towards what Mautic expects to see in a maintainer:
Help out users and other developers on GitHub, on the forums, and on Slack
Review and test the PRs submitted by others; this can help to offload the burden on existing maintainers, who will definitely appreciate your efforts
Participate in discussions about releases, roadmaps, architecture, and long-term plans
Help improve the website and the documentation
Help unstick issues that people don’t want to or can’t work on
Participate in - or even initiate - real-world events such as user/developer meetups, papers/talks at conferences, in-person sprints, etc. Having people in the community meeting you in-person, human-to-human, is an important part of developing trust
Improve project infrastructure to increase the efficiency of maintainers and other contributors
Help raise the project’s quality bar, for example, by improving code coverage analysis
As much as possible, keep your activity sustained rather than sporadic
Deliver on your promises - if you say you’re going to do something, make sure you do it - or inform others as soon as it becomes clear you can’t
It should go without saying, but here it comes anyway: your participation in the project should be a natural part of your work with Mautic. If you find yourself undertaking tasks ‘so that you can become a maintainer’, then you’re doing it wrong. This is particularly true if your motivations for wanting to become a maintainer are primarily negative, power-focused, or self-centered, for example:
You desire the power of a -1 vote. This should be used only extremely rarely in a healthy project.
You want to push your own changes through unreviewed by others or move things along faster so you can get to your own - or your company’s - goal faster. Mautic follows a clear code governance policy where even maintainers need to wait for a +1 from another maintainer.
You only want to merge changes from other contributors within a particular affiliation group, for example, coworkers in the same organization. The maintainer role is about furthering a diverse project, not a narrow agenda.
6.2.4 Adding new maintainers
Periodically, the existing maintainers curate a list of contributors who have shown regular activity on the project over the prior months. From this list, maintainer candidates are selected and proposed in the Core Team private Slack channel. The Core Team will aim to have maintainer representation from different genders, geographies, and employers.
There will be a 2 week voting period after the proposed list of candidates is shared. Any abstention will count as a positive vote for the proposed member. In order to be added, a proposed member must carry a two-thirds (2/3) majority vote of current active and honorary members.
A temporary private Slack channel will be created for use of discussion of the proposed member - example name: #_tmp-vetting-lee-smith, etc. All Active and Honorary Core Team members will be added to this channel. Responsibility of creating/deletion of this channel falls to the Project Lead.
If a maintainer has a strong objection to the inclusion of a proposed member, they should make this objection known in the temporary vetting channel in Slack. If the objection is sensitive, the objection may be raised privately to the Project Lead.
After voting has concluded on the proposed member, this temporary channel will be deleted.
Once the Core Team decides to consider a candidate as a maintainer, they’re contacted by a member of the Core Team to determine their willingness to be considered as a maintainer and availability of their time to ensure they can fully commit to the role in a sustainable way.
6.2.5 Removing maintainers
Maintainers may resign at any time if they feel that they won’t be able to continue fulfilling their project duties.
Maintainers may also be removed if there is prolonged absenteeism, upon failure to fulfill their Maintainer responsibilities, or because of violating the Code of Conduct. This also includes actively, persistently, and intentionally trying to harm or successfully harming the code base of Mautic, especially, but not limited to, endangering the security or safety of Mautic.
Prolonged absenteeism is defined as a period of very low or no activity in the project. All maintainers are expected to lead and assist at least two releases in any calendar year - there must be at least one Core Team member allocated to every release - and to be actively engaged in reviewing contributions, supporting developers, and engaging in discussions in the Core Team Slack channel to remain active as a maintainer.
If a maintainer has shown little to no activity over a six-month period, the maintainer will be contacted to notify them of their activity status and offer a move to an honorary role. There is no automatic change of status in the project from active to honorary role.
First, the activity status is discussed by the Project Lead directly with the maintainer, and second, maintainers discuss whether other non-tracked contributions to the project reflect an ongoing, active participation in the project.
The honor role is maintained at the Mautic Core Team and in the Mautic Project Maintainers list pages.
6.2.6 GitHub Admins
GitHub Admins are a subgroup of the Core Team who have elevated access to the GitHub organization. They can grant access to repositories, add and remove people from teams, and change protections for branches.
Beyond those privileges they don’t have any additional responsibilities to Maintainers.
Admins are selected from active Maintainers, and due to the high level of trust required, they tend to be the longest-tenured members of the team. The Maintainers try to take care to spread the admin responsibility over several project stakeholders within the Maintainer body. This is to aspire some checks and balances between stakeholders as well as introduce redundancies in case a stakeholder isn’t able to work on Mautic anymore.
GitHub Owners are a sub-group of the Admins, and other than the regular Admin duties, they don’t have any additional responsibilities.
6.3 Core Team
The Core Team are the people who take responsibility for Mautic’s code base. They review incoming change requests - called PRs - while ensuring that security issues are resolved promptly and also ensure that proactive steps are taken to keep Mautic at the forefront of marketing automation technologies. They also liaise with other stakeholders across the project when it comes to discussions on new features and enhancements.
The Core Team consists of at least three and up to nine active Maintainers plus the Project Lead, individuals who have the responsibility for merging new code into Mautic.
6.4 Release Leads
Each release of Mautic will have a named Release Lead and Assistant Release Lead. At least one of these will be a Core Team member with merging rights. Becoming an Assistant Lead for a release is a great way to get to know the Core Team Maintainers more, and also to understand what goes into making a release happen.
Their duties include setting the dates for feature freeze for the release, enforcing the feature freeze, coordinating the - mostly automated - tests of a release, writing the release notes and creating the tags defining the release and its pre-release versions where appropriate. They’re also the primary person responsible for merging the PRs for the release, although other Maintainers may also merge PRs in collaboration with the Release Team.
The full set of tasks can be found in the - currently internal use only - document Managing a Release. Their duties end after the release they managed is out. In the case of a major release, the release team is responsible for Alpha to General Availability releases.
The upcoming release leads can be found on the Mautic release leads page.
6.5 Security Team
The Mautic Security Team is focused on:
Resolving reported security issues
Releasing and disclosing security fixes in an ethical and timely way
Providing documentation on how to write secure code
Providing documentation on how to secure your Mautic instance
Helping the infrastructure team to keep the
mautic.orginfrastructure secure
Members of the Security Team aren’t always members of the Core Team. As membership in the team gives the individual access to potentially destructive information, membership is limited to people who have a proven track record in the Mautic project.
Similar to the Core Team, Security Team members must maintain a minimum level of activity to be considered active. Exceptions to that can be made for short periods to accommodate other priorities, but people who can’t maintain some level of involvement will be asked to reconsider their membership on the team.
The Security Team follows the same processes as the Core Team in terms of maintaining its membership and ensuring that members are actively participating in the team, however, one difference is that the Security Team has a Provisional Member status which new members hold for a period of at least 12 months before they’re considered full members of the team.
6.5.1 Expectations and duties of the Security Team
Lead and assist at least two security releases per year to maintain their membership.
Dedicate at least a few hours every month on security issues.
Support Maintainers and Contributors by providing security-focused reviews of contributions and guiding contributors towards security-first development.
6.6 Decision making
Mautic has well-documented processes to follow when it comes to decision making in the Governance Model. Wherever there is a debate to be had on how to approach a situation, the Community Portal is used, with the Product Team’s Debate Section having the ability for discussion, voting, and endorsement by teams and individuals. This ensures that both the users - marketers - and developers have the opportunity to know what’s being discussed and decided upon.
6.7 Disclosure of sensitive information
In general, information shared within the Core, Security, or Release Teams should only be shared outside the team on a ‘need to know’ basis with full transparency to the rest of the team as to who is being informed and why.
For example, if knowledge of team information will allow a contributor to create a patch or provide direct support to the security team in fixing an issue, this satisfies the ‘need to know’, and the contributor should be invited directly to the private fork for collaboration purposes.
Offering team information to give others advance knowledge of an upcoming release that isn’t yet public doesn’t satisfy the ‘need to know’. For example, letting an organization know about a zero-day for purposes of operational preparedness.
In the course of their duties, members should:
Avoid creating a situation where people use still-private knowledge which is gained on the team or code released under agreements to get an unfair advantage with no regard for the health of the Mautic ecosystem. For example, a security team member may not publicly post about unreleased fixes, a release lead or security team member may not share the contents of an Extended Long Term Support release with their organization, especially important if that organization isn’t a subscriber to the programme already.
Minimize risk that the confidential aspects of their work will be leaked beyond the team and posted to the public, outside of the release window and before a patch is released.
7. Record keeping
The Community Council shall be responsible for keeping correct and complete books and records of accounts, and shall keep minutes of the proceedings of its members and Community Council.
Leads of Teams and Working Groups are responsible for publishing dates, agendas, and minutes of their meetings within a reasonable time.
The Community Council shall keep a record of the name and electronic mail address of each member, together with the date of membership, record of transactions relating to membership, and any withdrawal or termination of such member’s membership.
Each member shall be responsible for notifying the Community Council of changes to such member’s name or electronic mail address.
Any books, records, and minutes may be in written form or in any other form capable of being converted into clearly legible written form within a reasonable time.
Any person who is a member entitled to vote, upon written demand under oath stating the purpose thereof, shall have the right to examine, in person or by agent or attorney, at any time during the Community Council’s usual hours for business, for any proper purpose as determined under the laws of the State of California, the project’s membership records and its other books and records and to make copies or extracts therefrom.
8. Amendment of this Governance Model
Members may form Working Groups to consider changes to this Governance Model and may propose such changes to the Community Council.
However, this Governance Model may be altered, amended, or repealed only by action of the Community Council or by a majority of the voting members, and new entries may be adopted solely by the Community Council or by a majority of the voting members.
No alteration, amendment, or repeal of this Governance Model shall be effective unless and until the Community Council attempts, in good faith, to give notice to the members of the Community of such alteration, amendment, or repeal at least fifteen (15) days prior to the effective date of such alteration, amendment, or repeal, which notice may be by electronic means.
9. Credits
The following individuals contributed towards this governance model by providing comments on proposals, discussions, and debate on topics and researching topics contained within:
Ruth Cheesley
Sven Döring
Norman Pracht
Joey Keller
Ionuţ Ojică
Mthobisi Glen Sehlabela
Khalid Zamer
Daniel Lord
Yosu Cadilla
Pierre Ameloot
Nick Veenhof
Ekke Guembel
Gábor Hojtsy
Ilona Sot
Brad Thompson
10. References
The following were used in researching and developing this model:
Open source project governance examples and resources
Decision making models
Org structures
Governance tools
Community growth models
The Commons Social Change Library - Circles of Commitment: A Model of Engagement