8

Decision making paradigm

Submitted by surreal in konsent (edited )

This post is about discussing the decision making process behind konsent.

Do we want users to have the option to choose whatever paradigm they wish to follow? this would be a big undertaking. If we have to choose one paradigm, at least at first, which one should be?

At the moment majority voting is implemented. Peeps made arguments in favor of consensus decision making. We have to do some research and designing beforehand.

material:

Comments

You must log in or register to comment.

2

leftous wrote (edited )

What if consensus is achieved in a similar conceptual way to git?

Let's call the initial proposal the "master" branch. Everyone presents "issues" that may impede a consensus being reached. To these issues, people suggest potential solutions. Then these "solutions" are voted on and merged into the master (in a majority vote way).

By the time we get to the veto phase, most of the potential issues with the proposal should have been hammered out and the final proposal can pass by consensus. However, if there is another veto in the veto phase, someone opens an "issue" (not a solution) and the community determines if it's legitimate issue. If this issue is determined to be legitimate, it goes through another solution suggestion phase.

If there are still vetoes after x amount of rounds or if it's one small contingent of users abusing the consensus/veto process, it should fall back to a majority vote.

This also allows decisions to be more malleable and fluid because at any time, members can open issues/bugs with the proposal. Also possibly if no consensus can be reached with a particular community, a proposal can be forked to a subforum to be crafted to suit their needs.

2

surreal wrote (edited )

This is very interesting! i'm trying to create a flow chart and diagram for konsent, these concepts will come in handy.

At the moment we're going with the separation of the discussion part and the consensus part. Discussion will take place elsewhere and not in konsent.

1

dele_ted wrote (edited )

I think the best solution, as we talked about on GitHub, is allowing contributors to add links to external discussion during phase two. Discussion would happen alongside phase 2, and Konsent would avoid becoming a mutant with three half-finished arms.

If you want to know why i like this solution better, here's a wall of text, as is tradition:

Consensus alone won't cut it when it comes to online communities. It is already a somewhat problematic solution at times, often requiring lengthy discussions, a lot of thought and engagement from all parties involved and, at times, completely giving up an issue simply because a solution could not be found.

I think decision making without hierarchy can be refined and fitted better for online communities by finding a balance between direct (and open) democracy and consensus decision making, which can be accomplished with the technological means that almost everyone carry with them everywhere already. Direct and open democratic voting, discussion, influence according to engagement and a universal right to veto; all this combined can, in my opinion, shape a new and much needed foundation for collective decision making without hierarchy.

2

surreal wrote (edited )

when you say direct democracy do you mean majority voting?

At the moment the solution that is accepted in phase3 is the one with the most votes. That's plurality voting which is kinda worse than majority, cause in this case there is a chance that even the majority would be left out.

Vetoing is absolutely needed no argue about that, what the consensus model does is move it earlier in the process and creates a feedback loop which gives space not only discussion but also reshaping of issues/solutions.

1

dele_ted wrote

I mean majority voting, but with onymous votes, as if we were simply counting raised hands.

At the moment the solution that is accepted in phase3 is the one with the most votes. That's plurality voting which is kinda worse than majority, cause in this case there is a chance that even the majority would be left out.

If they feel that their needs were overlooked, they can use their veto. Trying to dominate the minority and simply forcing your solution upon them without being open to modifying it until everyone is satisfied is just wasted time, since it'll be vetoed instantly without a doubt. I don't think we need to have rules for this, i think it'll happen dynamically if discussion is accessible and encouraged.

1

surreal wrote

Yea onymous voting it necessary for open discussion. We are pretty much saying the same thing, it's mostly about implementation.

If you take a look at 'The process' paragraph in the anarchistlibrary article or in this flow chart it seems that vetoing is part of process and not an option after the process has come up with a solution. This makes the loop faster and forces the issue/solution proposals to change more while the discussion is happening.

1

dele_ted wrote

Hmm, you're right that vetoing should not just throw the issue away and restart everything. I just had this idea, it might work, it might not, haven't thought it completely through myself:

We'll add a new type of veto: soft. Soft veto won't bring the issue to "vetoed proposals", but will instead send it back to phase two. This will probably make people much more careful with the hard veto, too.

What do you think?

1

surreal wrote

yea that's a start. this is complicated

1

dele_ted wrote

It really is. I like the concept of registering "stand asides", might be something worth looking into later on.

We should also make it so that a veto, soft or hard, will require a short explanation.

We really have to beta-test Konsent once it's ready for that to spot the flaws. It's difficult to figure out how the community will use it right now.

1

surreal wrote

the explanation will be part of discussion. with onymous voting there is no need to add extra stuff other than links.

2

dele_ted wrote

You're right, that's not necessary. One thing I've been thinking about is, how should we handle individuals who grief Konsent and veto every proposal, even the proposal to ban them? Do we need some sort of emergency use vote-for-ban that would require 90% or more to support? Should individuals not be allowed to veto proposals involving themselves?

3

surreal wrote (edited )

this is still unclear to me, maybe others can propose some solutions.

Maybe try it without any limits and see how it works at first? or a have veoting limit?

we will at some point need to add functionality for administrating the issue in a consensus way as well, that would mean we will have to implement specific 'meta' proposals, like banning, for the functionality behind unions and their more general issues.

Btw we should probably come up with a lingo for all these. Also i was thinking that there can be two types of 'issues', one that is a proposal that seeks cosensus, like banning a user, and the other being an issue that will require proposals to iterate until it come down to consensus about one. does this make sense? edit: this can be abstract enough so there is no need for different types.

1

surreal wrote (edited )

What about the algorithm that decides which issue/solution will be accepted, at the moment it's majority voting of 51% which means that half of the people won't have a say.

1

dele_ted wrote

I think stage three, vetoing, completely negates that. People will want to arrive at solutions that nobody will veto against, which means they'll have to listen to the points of the other community members and consider them in their solution proposal.

1

surreal wrote

Vetoing as it's implemented at the moment blocks the solution and the whole issue right? It would be better if there is a loop there and not reject the whole issue with one veto for the solution that passed first.

1

dele_ted wrote

Definitely, I've considered that too. I'm assuming people will just open the issue again and make the necessary changes for now, though.