MeatballWiki |
RecentChanges |
Random Page |
Indices |
Categories
A
ConsensusGroup is a dynamic group of contributors (
consensus partners) interested in supporting consensus. Anyone can join, leave and return to the consensus group at any time; a list of
inactive partners is maintained as well as a list of
active partners. Each contributor agrees their silence is to be interpreted as
SilentAgreement after a given
review time (say, two days).
Consensus can only be reached about a formal suggestion, something like AgreementMode; it is a matter of politeness to carefully elaborate the suggestion, with reasoning. Consensus is reached when all consensus partners signal agreement, either explicitly or by remaining silent for the review time. (Consensus can only not be reached, therefore, if there is an opposing voice within the review time; equally, it can only be reached early if all concerned pre-empt their SilentAgreement.)
If someone does not contribute anything to the wiki for a while - maybe 2 weeks - he can be assumed inactive, and can be moved from the active list to the inactive list by a consensus partner; he may later reactivate himself at any time. This may allow quicker consensus in future.
Examples:
- a suggestion is made, no-one comments, after 2(X) days consensus is assumed
- a suggestion is made, all active partners agree, the last after 10 hours - at that point consensus is assumed
- a suggestion is made, there are explicit agreements, but also a request for change - no consensus, a new suggestion must be made
- a suggestion is made, someone thinks it's unclear, no consensus, a new suggestion must be made
A ConsensusGroup is a new development that has been suggested by "sigi" and tried at GründerWiki. It is experimental and under development. It is meant to overcome the problems of WhatIsaConsensus. Note that the consensus should not be immediately identified with a decision, it only builds a foundation to assume that those people who are interested in a consensus (a known number of consensus partners) do agree.
The ConsensusGroup:
- is a group of wiki contributors, a changing subset, a list (A) is kept for active partners
- anyone can become part of the consensus group, one must only declare to be part of it, this means
- to be interested in supporting consensus
- to allow to interpret silence as SilentAgreement, after a given timespan (maybe X=2 days)
- anyone can leave the group anytime and return anytime, a list (I) is kept for inactive partners
- if someone does not contribute anything to the wiki for a while (maybe 2 weeks), he is assumed inactive and someone may move him from the active list to the inactive list (he may activate himself anytime)
- consensus can only be about a formal suggestion
- something like AgreementMode
- it is a matter of politeness to carefully elaborate the suggestion (reasoning)
- consensus is reached when one of these is valid
- all consensus partners give an clear explicit agreement
- there is no opposing voice within 2(X) days
Notes:
Thanks for sharing this.
- I find this a very appealing approach.
- One aspect I really like is that it seems to be a good (and efficient) inital approach to the problems of Decision-making.
Do you think it would also be a good initial process leading up to Voting systems?
-- HansWobbe
Hans, maybe. Currently ConsensusGroup is used informally for smaller things like creating or deleting pages. One has to get used to it. Of course, one can feel the wish to overthrow the system by a tighter interpretation of silent agreement, by suggestions that touch constitutional questions, ... I think we can only wait, what this will lead to. For me, it's a step forward to have a first model, how a consensual decision might look. Of course, some elements of the planned voting system and the consensus group look strikingly similar. On the other hand, ConsensusGroup is meant to work with soft means, while the voting system is going to be a "hard" system. -- HelmutLeitner
Your realization that we can "only wait" also makes sense.
After all, the ideal case is complete consensus within a Group (which ironically making decision-making a trivial undertaking). Since Group dynamicals are continuously evolving, there will undoubtedly be an almost infinite number of forces, circumstances and their variations that will affect each particular group.
Very interesting. -- HansWobbe
Question: since the actual consensus is simple veto over a review period, what is the motive for the active/inactive separation? Merely a convenience to see at a glance who's actually been around recently? -- ChrisPurcell
- No, the active list is important to allow a quick consensus. Lets assume, you are one of 5 contributors in the list, and you have a wait time of N=3 days. Your suggestion is answered by the 4 partners within 10 hours. So you can continue based on that. Otherwise you would always have to wait the full N=3 days.
- The inactive list exists primarily to avoid the necessity to just delete people from the active list. Moving is nicer than deleting and one can add a reasoning ("saw that he didn't write for a month", "I'm on a 2 week vacation"). You see that they once were active. They can reactivate more easily. -- HelmutLeitner
::claps head:: Oh, yes, my mistake. Thanks. -- Chris
Is MeatballWiki a ConsensusGroup around many of its major 'vetoable' actions, such as the PageDeletion and FileReplacement mechanisms, or even non-technically implemented changes that survive PeerReview through RecentChanges? Should it be? -- SunirShah
- I don't think it is one, exactly because one cannot hasten PageDeletion or FileReplacement by making your agreement non-silent - there's no AudibleAgreement?. They all could be moved to a ConsensusGroup design, but there seems little point. For instance, unless we move to a StableView system (with a ConsensusGroup choosing the StableCopy, that is), there is exactly zero benefit to setting up a ConsensusGroup for PeerReview.
- Is it worth setting up a sort of SuperPage? around these ideas, by the way? I keep seeing Veto everywhere in modern low-tech Wiki, now I look; ConsensusGroup seems the simplest extension, and essentially transfers all conflict from the voting system to the contributors list. This aspect in particular might be worth looking into further. Mmmm, musing time... -- ChrisPurcell
CategoryConflict
CategoryConsensus