16/05/2023 Model Proposal - Section 2, Decision Making

Community Governance
, ,
1

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

  1. 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. 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.2 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

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

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

2

This is too important not to debate to exhaustion every single detail.
This should be the first decision we make and it should not be tied to anything else.

For non-trivial decisions, the discussion should be open for at least 36 hours
Why 36 hours?

What is the difference between “non-trivial decisions” and “significant decisions”

Sometimes there may be a need to request a quorum
Why? when? How?

Any voting member can request a quorum for any decision being made
I have repeatedly expressed my concerns about quorum enforcement, quorum is very problematic, especially when the groups are already very small to begin with. It introduces a way of blocking and it is hence destructive of both consensus and direction.

I therefor must refuse this section of the proposal, until we can better define all the important details.
And specifically until we have a method to resolve disputes if the interpretation of these details is different for 2 people.

3

Hello @rcheesley I have some questions :

  • What is the difference between “non-trivial decisions” and “significant decisions”?
  • Why 36h? Is too short for volunteers who aren’t necessarily online every day and have other priorities in their life. I think a period of a few weeks (2?) would be more appropriate.
  • Where will these decisions be debated? At present, there are too many channels for discussion. Can we define that all discussions take place on the forum (instead of Slack). The forum is visible from Google, so conversations remain archived and searchable.
  • Who decide and vote?

Pierre

4

I would probably use a similar method that is used in the Product Team.

If it impacts (or has the potential to impact) one area of the project and/or impacts a small subset of users/community members, is something that is a reversible decision (once made, it would be relatively easy to revert the decision without too much impact), and it’s something that is not contentious, consider it to be non-trivial.

If it impacts (or has the potential to impact) more than one area of the project and/or a large subset of users/community members, is not an easily reversible decision, or it’s in any way contentious, consider it to be a significant decision. (we could add a $$ budget amount, as well, perhaps)

Speaking to the ‘why’ part of your question:

As we discussed in the Working Group, there might be some discussions where it is felt to be important to ensure that the majority voice is being heard, to prevent a one-sided debate being pushed through. Having a quorum called means that at least a minimum percentage of the folks who could vote, turn up to vote. For example in a working group meeting there might be 10 people who are part of the working group and eligible to vote, and we might want to ensure that at least 5 people are present for the vote (e.g. a quorum of 50%).

I would see this as being the exception to the norm and not something that would happen often. It would just be when there are important things to discuss where the breadth of folks need to agree.

Speaking to the ‘How’ of your question, I thought this was outlined in the following point:

On a scale of 1-10 on how important this is to me, I’d put this somewhere around 6.

I think that it’s helpful to have this provision available, for the reasons that I have outlined.

I think that it would be beneficial to the community so that they have the option to request (with good reason) a quorum to be considered.

The fact that the request, and the response from the leadership of the team will need to be public, would (I hope) detract from bad actors using this to block decisions.

If there are small teams involved, the number required for a quorum is equally small and the likelihood of this being invoked also small - so I don’t think it would be a problem.

5

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.

Non-trivial decisions would be things that do require a bit more involvement from others, but they are reversible. So they don’t need extensive, exhaustive consultation. Two weeks to decide on how many tracks to run at a conference or which catering provider to use would be simply too much time. It would be counter-intuitive to enabling teams to run.

Significant decisions, on the other hand, do often need more time to discuss. For example, which event platform should we use for a conference (this impacts several teams, has $$ impact, and also impacts the wider project). In those cases, indeed, a longer time box is needed as indicated.

We already do this naturally within teams - for example we go through a couple of team meetings with the MautiCon working group before we make such decisions.

Please see the tooling thread: 16/05/2023 Model Proposal - Tooling that might support this proposal where I’ve outlined a proposal for this.

In the past we did have team leads post to the forums, but that became very clunky and cumbersome when the Chrome plugin we used stopped working so effectively.

Please see the Membership thread for who is eligible to vote.

Decisions will be made by the leadership of the entity proposing the discussion/debate/vote, based on the outcomes.

6

Thank you @rcheesley for all those explanations, all of which should have been included into the proposal, but you cannot know what those questions or remarks could be beforehand and that is why you cannot put a time frame around this type of process.

7

I really think you are missing @pierre_a 's point and mine too.
You define some open ended rules, then you put a “board” on top of it, it leaves all that stuff open to almost any possible interpretation, that’s a very bad way to define rules and it will end biting us all in the butt!
We need more specificity, we need time…

8

Hello @rcheesley,

On this point I understand that decisions need to be made quickly. In this case I propose that these decisions be made by the team in charge of the operational side of this specific subject.
Not every subject needs to be discussed by everyone all the time. :smiley:

The community’s role would be to ensure that there are no excesses within the operational teams and that decisions are taken for the common good.

What do you think?

I don’t understand the link between forum usage and a Chrome plugin. :slight_smile:
If all structuring discussions take place on the forum, why do we need a Chrome plugin?

Pierre

9

I absolutely agree. I’ll add those as clarifying points in the proposal above, if folks agree that those examples and explanation are sufficient to give context and clarity? I can make a clearly noted edit to the existing post to reflect that?

Absolutely - trivial decisions should be made by the team.

Just for clarity as I got my wording mixed somewhere in my explanations:

Trivial - Small decisions which should be made by the team. Doesn’t impact anything, reversible, and does not need debate/discussion.

Non-trivial - Things which are not trivial, but they are not major decisions either. They sit in the middle ground where some involvement is needed but it’s not a massively impacting decision, so we don’t need to have a full-on consultation.

Significant - Bigger impact decisions which do need more thought, research and debate. These need a longer time box and wider involvement.

Maybe the wording needs to be clearer, perhaps trivial v non-trival could be confusing, especially when translated?

I think that this would ensure (if we were for example to put a $$ cap on any financial decisions above a certain threshold having to be considered significant) that the community is actively involved (through whatever channel is the most appropriate) in the operational decisions when large amounts of money are involved, in particular. I think the open startup reporting will also help with this aspect.

Ahh, sorry for the lack of context there. That’s an omission on my part.

Team and working group meetings typically happen online (eg Zoom) and/or they happen asynchronously on Slack. We have documentation here and here on how those meetings work, including using a Chome plugin which scraped the meeting notes from Slack async meetings into a format that we can post into the forums.

That plugin became really clunky and the markup was often mashed up and required (sometimes an hour or more) of time to make it a format that would be legible. I feel that’s the main reason why this was stopped (posting to the forums the results of the meetings).

Just recently as well, some teams haven’t been meeting formally so that is something that’s in the process of being revisited.