Welcome to Mautic!
Within the Mautic project, our governance is driven by our core values:
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 do not have voting rights. They can attend and contribute to discussions and decision making processes, but may not vote and are not counted for the purposes of 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.
To gain voting rights, there are two ways, financially or practically contributing to Mautic.
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 are not 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.
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 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 a form each year.
The Community Council will verify all membership requests on a monthly basis. They will 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.
Organizations can become a member by joining at one of the following tiers:
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.
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, shall be counted for purposes of a quorum.
All categories of membership other than Basic Membership have voting rights.
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 are not provided for individual or organizational members which 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 with 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 a termination due to a Code of Conduct breach.
It is 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 we recommend are followed, which provide alignment with our core values.
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, we consider 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 are 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 are not easy to reverse without consequences. For example, which event platform should we 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 is strongly advised that a longer timebox 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.
In the Mautic community we default 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 2.1 for guidance) if there are not 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.
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.
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
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.
The following teams currently exist in the Mautic project as established in the 2019 governance model:
Any member or group of members may propose a Team. In order to propose a vote to approve a Team, the member(s) 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.1 has been created and a proto-team established to demonstrate viability of the 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.
Team Leads or voting members may establish one or more Working Groups as required to fulfill the tasks of a team or needs of the project. All Working Groups will sit underneath one of the existing Teams, with the Team Lead being responsible for their budget.
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 project(s) managed by such a group, and they may establish rules and procedures for the day to day management of project(s) 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 which apply to them.
In order to propose a vote to approve a Working Group, the member(s) 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.
Any member of the community who is eligible to vote and who does not 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.
Teams and Working Groups will elect through ranked choice voting on a 'whoever turns up' basis, a Lead and Assistant Lead.
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 are replaced by an incoming Assistant Team Lead. Example:
Year 1
Year 2
Year 3
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
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.
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:
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.
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 does not 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 5.2.4 and may include any further information as to their suitability for the position.
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.
Members of the Community Council shall not be compensated for their duties as a representative. Reasonable travel expenses will be covered where they cannot 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 are absent from any discussions and voting in the Community Council relating to or directly impacting their role.
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.
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.
Each at-large representative shall hold office for the term for which they are 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 are replacing a representative that 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 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.
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.
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.
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:
They are appointed and managed by the Community Council.
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.
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 is recommended that they are shared in advance of the date with a full agenda of what is 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.
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.
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 vote of such members.
No more than two (2) of the members of the Community Council may share a common affiliation as defined in Section 5.2.4. 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 member(s) 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, is controlled by, or is under common control with the other entities declared as affiliations by other members of the Community Council.
Contributors are people who contribute their work to Mautic. This includes but is not limited to:
Code contributions are very welcome, they are the life-blood of our 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. We call these organizations and individuals 'stakeholders' throughout this section of the governance model to summarize them.
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 which carries much responsibility, so we have quite strong processes around adopting new maintainers.
The current list of active maintainers can be found in the MAINTAINERS list.
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 does not make you qualified to be a maintainer, it is 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.
So you want to be a maintainer of Mautic? Awesome!
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 maintainership will seek you out rather than the other way around.
Here's some ways that you can work towards what we expect to see in a maintainer:
It should go without saying, but here it is 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, young padawan. This is particularly true if your motivations for wanting to become a maintainer are primarily negative, power-focused or self-centered, e.g.
Periodically, the existing maintainers curate a list of contributors that 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, geography, 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 ⅔ 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 are 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.
Maintainers may resign at any time if they feel that they will not 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 in order 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 https://community.mautic.org/profiles/core-team/ and in the MAINTAINERS file.
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 do not 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 is not able to work on Mautic any more.
GitHub Owners are a sub-group of the Admins, and other than the regular Admin duties, they do not have any additional responsibilities.
The Core Team are the people who take responsibility for Mautic's code base. They review incoming change requests - we call them PRs - while ensuring that security issues are resolved promptly, and also ensure that we are taking proactive steps 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.
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 are 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 document Managing a Release (3). 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 in the RELEASE_LEADS file.
The Mautic Security Team are focused on:
Members of the Security Team are not 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 are considered full members of the team.
Mautic has well documented processes we follow when it comes to decision making in our 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 is being discussed and decided upon.
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 '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 which is not yet public does not satisfy 'need to know' (e.g. 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 is not 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.
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.
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.
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
The following were used in researching and developing this model:
https://www.python.org/psf/bylaws/
https://peps.python.org/pep-8002/
https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951
https://www.zotero.org/groups/2310183/foss_governance/library
https://en.wikipedia.org/wiki/Direct%20democracy
https://en.wikipedia.org/wiki/Representative%20democracy
https://en.wikipedia.org/wiki/Garbage%20can%20model
https://en.wikipedia.org/wiki/Consensus%20decision-making
https://en.wikipedia.org/wiki/Instant-runoff%20voting
https://en.wikipedia.org/wiki/Anarchist%20law
https://en.wikipedia.org/wiki/Referendum
https://en.wikipedia.org/wiki/Flat%20organization
https://en.wikipedia.org/wiki/Cooperative
https://communityrule.info/templates