See parent thread with all sections of the proposed governance model here.
See original text with explanatory comments here.
2 - Decision making
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.
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
1.1 To facilitate an understanding of how long is needed for making decisions, we consider three types of decisions:
1.1.1 Trivial decisions like which colour 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.
1.1.2 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.
1.1.3 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, indeed, a longer time box is needed as indicated.
1.2 For non-trivial decisions, the discussion should be open for at least 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.
1.3 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, to ensure that appropriate communication and promotion of the decisions being taken can happen.
2.2 - General guidelines - methodology
-
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 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.
2.2.1. 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 feedback on their decision for or against a quorum being required.
Edit log:
6th June 2023:
- Add clarification on how complexity of decisions are made and explain the terms trivial, non-trivial and significant decisions