Decision making in the steering committee

D by duncan on 21 Dec 2022, edited 4 Jan 2023 # +1 votes

This is mostly a copy of a post from a discussion in the steering committee chat room as follow up to the December meeting. @theoryshaw and I agreed it made sense to bring this discussion to the forum.

Steering Committee chat: https://matrix.to/#/#OSArch-org:matrix.org

Minutes from the December meeting: https://gitlab.com/osarch/OSArch/-/tree/main/Meeting%20Minutes/2022-12-07_Minutes

Regarding decision making, I don't agree with majority decisions in such a small committee which in such a narrow way represents the community. Depending on who turns up to a specific meeting there can be wild variation in opinion. Decisions need time and agreement. Agreement - as we've seen a few times - can be in the form of "I'm not so sure, but let's try it your way". But I think it should at the least be possible for any member to put in a veto. I know consensus is regarded as messy, and it wouldn't make sense if we were a parliament of 150 members. But we are so few I have real trouble seeing that there could be a situation where the only solution is a vote in the committee. One way around this is to say that a vote can be requested and announced as being held at some specific later date. There can be a process that the parties must formulate their views on the forum or in some way work towards clarity and perhaps consensus. It would also give the wider community a chance to push their view in if there is a strong feeling.

In our community of twelve households here where I live the only way to hold a formal binding vote is to follow the process for calling an extraordinary general meeting. This ensures that there is a cost to voting - or I could say that it brings a cost to not reaching a consensus. Otherwise it's easy for a small majority to agree and push their view onto the others.

I have been thinking that we might need a 'constitution' of some sort which ensures the values we cannot move against in decisions. For example not supporting proprietary projects and only supporting FSF endorsed licenses etc.

Having such a constitution which can be improved over time can also help avoid the impulse to vote as some typical disagreements can go through a heavy consensus process and end up in a binding constitution which is made hard to change.

One important problem with narrow majority voting or decisions without wide input: often those decisions get overturned not long after. That is often a very destabilizing situation. An example from national politics is that this is one reason why countries with proportional representation in their parliaments are often more rather than less stable. Decisions can only be made by broad coalitions. No small group can hijack the process for a few years and swing policies violently from one extreme to the other.

Some concrete proposals that might be a start for discussion:

financial decisions can only be made is they've been on the agenda for at least one prior meeting.
Any SC member can veto a decision that has not yet been implemented
Any two SC members can request a vote at the following meeting for an item on the next agenda. The different views must be presented on the forum at least 14 days before the SC meeting.
Financial decisions require attendance of at least 4 SC members. SC members can express their view or veto before the meeting if they can't attend. (needs work)

I'm not married to those suggestions, but you can see where I am going with this.

Sorry for this tomb, but I think this is important. No hurry in replying. Thinking is sometimes better than chatting here. I'm on sick leave so I have time to think.

Added note: after rereading my text I can see it needs clarification, I'll get to that after Ryan has added his reply.

D by duncan on 21 Dec 2022 # +1 votes

@Jesusbill followed up with this comment:

Regarding decision-making, I support to have unanimous decisions (I think we all support that) but I understand that not always there will be a global agreement; for those cases I would prefer voting, after discussing and exchanging arguments, than having the possibility to apply a veto and stop everything. At the end of the day, both approaches (unanimous or not decisions) have their pros and cons, its the persons who implement it that make the difference

T by theoryshaw on 21 Dec 2022 # +1 votes

_here's my copy/pasted blurbage from the discussion here._

I personally prefer voting.

I think reaching 100% consensus, even with such a small group, is near impossible. It is even in most households. ;) We might agree on most things, most of the times, but there's always those subtle disagreements about an idea, in whole or in part, that slows the process down to a gridlock.

I also think in the pursuit of consensus there's a lot of compromise and watering down of ideas, because people just acquiesce to a proposal just to move forward. Consensus feels like veiled compromise, a lot of the times.

Other times, there might be someone that agrees with 95% of a proposal, but does not want to compromise on one specific detail, but all the others disagree. In such a situation, does the project just stop?

Also, since 100% consensus takes so long, and can water ideas down, it drains the enthusiasm of the one person (or small group) that originally proposed the idea, and is really the one, more than likely, that will do the work and lead the charge on the project. I would argue there's more risk of not implementing a project due to this loss of enthusiasm, than there is risk of not getting everyone to agree on all decisions.

Not a one-to-one comparison, but being able to act and implement based on a small majority, is similar to the open source development mentality--that is, if you think you have a good idea, you are free to implement it. Obviously, such a do-what-you-want approach would not work in the governance of OSarch, but this simple majority allows us to get closer to the spirit and freedom of open source.

Regarding being able to "veto a decision that has not yet been implemented". I could see a veto as being very debilitating to someone that's halfway through, or almost done implementing something. We need to give the implementers confidence to proceed.

Also, as the case with ever project, as one (or a small group) works toward implementation of the project, there's always subtle decisions that need to be made. In an environment where 100% consensus is required, there's less incentive to propose a solution to the group, as they know the potential back-and-forth will gridlock the project.

I think it's important to incentive the implementer to propose these subtle, project specific, proposals back to the group. In such scenarios I would propose that someone can move forward on a decision if there's no objections, about the proposal, from the group. That is, I don't think it's necessary, or even practical since we're all busy, to have everyone vote on all proposals, all the time. In the event, there are objections from another member on a proposal, then all SC members need to weigh in with their verbal opinion, or propose alternate solutions. In this scenario, I propose a simple majority should give the implementer the confidence to move forward.

N by Nigel on 22 Dec 2022, edited 22 Dec 2022 #

I acknowledge the risk of veto and consensus. The constitution is a good idea but more important is the core values to which decision or vote is measured against. If a voter cannot honestly say their vote stands up to those, as yet to be defined core values then they are not representing the community.

D by duncan on 22 Dec 2022 # +2 votes

Let's see if I can summarize the views put forward by @theoryshaw - just to see if I'm understanding them correctly.

complete agreement is rarely possible
small disagreements can stall a larger project
consensus often means compromise, and compromise sometimes gives weaker decisions
effort spent on reaching consensus can drain energy from people, projects and their implementation. perhaps that energy drain is a bigger problem than not always agreeing
allowing a veto would cripple projects under way and drain enthusiasm for starting projects
requiring consensus can mean that small decisions are made outside the SC meetings as a way to avoid drawn out discussion

Do you get the impression I've understood those points? I'm guessing I understand them - I agree with each of them in isolation. So the question is probably just how to design processes that acknowledge those issues.

Maybe @theoryshaw you'd like to summarize my main points. I'm always surprised at how much more clearly one understand things when forced to summarize them.

If I understand your last paragraph I think you're saying that during a meeting while consensus runs all is good. If the group however cannot agree, then in that situation a decision should be postponed until the rest of the group has had a chance to engage with the issue and contribute their thoughts. Is that correct?

D by duncan on 4 Jan 2023 #

Rest of the Steering Committee feel encouraged to comment: @brunopostle @Moult @Jesusbill