BeyondYes

MeatballWiki | RecentChanges | Random Page | Indices | Categories

In the context of MeatballBoard TedErnst wrote: I do think the BeyondYes process could be helpful here. The idea is to create a solution that works toward addressing the concerns of everyone, while understanding that to get anything done we just need agreement of "enough." The process has four parts:

the StaticContract? tells us how we know when we're done (for example: We're done when 90% of at least 20 people say YES to the DynamicPlan?, and the DynamicPlan? stays unchanged for 7 days - could also say that at least 15 of those 20 have to be people with namepages here and at least one edit in the last year, or any other criteria you like)
the YesMeter? is where people register their current status - choices are YES and NotYet? - participants can change status whenever they like, as many times as they like - those with status NotYet? have a responsibility to express their concerns in the ForumForConcerns? and/or edit the DynamicPlan? directly to get their concerns met
the DynamicPlan? is where the emerging agreement goes - eventually, when the StaticContract? is satisfied, it will be the binding agreement
the ForumForConcerns? is where people with status NotYet? articulate as clearly as they can what their concerns are and if they can, how those concerns might be addressed

: We also need to clearly express the issue we're working on. Perhaps the issue is "How will Meatball govern itself?" -- TedErnst

Ted, the concept is not entirely clear to me. Can you expand on it? I also wonder, whether it is compatible with the direction we went in GründerWiki, which means that anyone can contribute to a decision process and be heard, but only a known, trusted group of active contributors which is pretty open (this means that anyone can invite new members anytime) and as large as possible will make the decisions. Is BeyondYes more inclusive? and if yes, then how can you avoid being overrun in a decision making process? DynamicPlan? sounds a bit like the "ConsensusGroup plus SilentAgreement" we use. -- HelmutLeitner

So sorry I've been absent! Not even sure if this conversation is still going on. BeyondYes isn't inherently more or less open than any other process. It could be used completely privately among 3 trusted friends, or wide-open among all residents of Europe. The Static Contract is where those decisions are made, before work happens on the Dynamic Plan. You describe a process where anyone can be heard, but only a smaller group makes the decision. If you were to write that into the Static Contract, it might say something like:

: We're done when we have all of:
: * 90% YES from the ConsensusGroup
: * At least 10 of the 14 ConsensusGroup members participating
: Contributions to the Dynamic Plan or the Comment section are welcome from all, but only participants in the ConsensusGroup will be counted.

Another way it might be done:

: We're done when we have all of:
: * 80% YES from all participants
: * 90% YES from the ConsensusGroup
: * At least 20 participants
: * At least 12 of the 14 ConsensusGroup members participating

This one allows a bit more openness, but ensures that the core group has a certain measure of veto power. -- TedErnst

I've splashed some concerns and ideas at the bottom of ConsensusPolling, Ted, don't know if you spotted them. Could you take a look?

: BeyondYes processes bring to mind the old way that the Apache group used to govern itself. During one phase of the old Apache group, any developer could express an opinion by voting, but only the votes of the "core members" of the group were binding. One thing that the Apache group found was that their voting system worked better for incremental changes, than for periods of rapid and intense development (probably because there are too many decisions that need to be made a consensus process to keep up). However, I think that BeyondYes and ConsensusPolling could work with intense/rapid periods of development. Let's look at the example of the evolution of living things, which might provide some useful metaphors.

: We could say on the one hand that life evolves without "consensus". We could say that organisms adapt and change over time without stopping to "take a vote". But, I think we would be partially wrong if we said this. Because there is a hidden order in the way that life evolves and changes ove time. Living things seem to have come to a sort of internal and complex "consensus", with their total environment about the simple rules that they follow on smaller scales. We see this in the form of genes and "genetic algorithms" present in all life forms. The evolution of life has found, and so far stuck with, a core "standard" from the earliest bacteria to human beings. In the timescale of the evolution of life, this has allowed "rapid and intense development". The "oversight" is an emergent process of gene, organism, and environment.

: Living things have a built-in infrastructure for (relatively) rapid development and decision making. Living things continue to develop, evolve and refine ways to process and use information about themselves and their environment. Within aliving organism (based on frameworks we are using at http://cooperationcommons.com, and in particular drawing from http://www.rheingold.com/cooperation/decisionmaking.pdf)

: * Information flows freely, there are no "boundaries", only thresholds, such as the physical limits of the biological "hardware".
: * Information and knowledge are organized in a flexible chaotic/ordered ways within living systems
: * Living things detect patterns of synchrony in information flows in volitile environments. Living things then sync themselves up with these patterns. Their genetic systems equip them with increasingly effcient ways to recognize and remember patterns.
: * From http://www.wired.com/wired/archive/11.04/quorum_pr.html :New research suggests [..]that microbial life is [..]: highly social, intricately networked, and teeming with interactions. (Bonnie) Bassler and other researchers have determined that bacteria communicate using molecules comparable to pheromones. By tapping into this cell-to-cell network, microbes are able to collectively track changes in their environment, conspire with their own species, build mutually beneficial alliances with other types of bacteria, gain advantages over competitors, and communicate with their hosts. Even the earliest living organisms devise ways to catalyze the sharing of information. Even the earliest living organisms created GroupFormingNetworks?. They did not hoard information. They strategized collectively locally to compete globally.
: * The evolutionary process in living things evolves forms of "trust" system adaptations, and group identity system adaptations.
: * The evolutionary process equips living things with "parsing signal from noise" adaptations, both on individual organism, and groups of organism scales.
: * Simple organisms, like bacteria, resolve conflicting "agendas" of the individual vs. collective good by genetically programming themselves to sacrifice themselves for future generations. Yet, we also discover that some of the bacteria instead evolve genetic programming to "cheat", and not kill themselves when the rest of the colony sends out the "die-off" signal.
: * Simple organisms evolve swarm-like behavior that make collective decisions "on the fly" about real-time conditions.

: (Note that Meatball already displays many of these properties to some degree).

: BeyondYes, or ConsensusPolling could harness some of the properties of complex adaptive living systems for decision making processes. The http://www.rheingold.com/cooperation/decisionmaking.pdf paper recommends to:

: * "Develop both stocks and ﬂows of information."
: * "Cultivate ongoing cycles of sense making and interpretation"
: * "Identify surrogates for rapid trust to build social capital"
: * "Distribute control to optimize creative freedom"

: For instance, the StaticContract? and the DynamicPlan? could be merged into one ongoing EdgeOfChaos? system. This merged Plan/Contract could be an ongoing and open plan/contract, built off of "stocks and flows of infromations, and ongoing cycles of sense making and interpretation". Participation can be more open, more oriented towards RadicalInclusiveness, if there are transparent reputation and rating systems that allow the "rater" to rate the "ratee" and vice versa. This can also help distribute control. Each person is really only "in charge" of what they do personally, thus all of their work is part of an ongoing greater community DynamicPlan?. There is only a StaticContract? for the duration of the time when one more other people agree to work on my piece of the greater DynamicPlan? with me. In order for this to work, then every person in the community would have to agree to try their best to work within a system that develops their piece of the DynamicPlan? based on what they are believe are the best Info Stocks and Flows, and every person in the community would have to do their best to cultivate ongoing cycles of sensemaking and interpretation of their info stocks and flows (viauslize data to improve pattern recognition, test hypotheses on an ongoing basis, "think out loud", encourage an environment that makes tacit knowledge explicit). Every person would have to agree to do their best to employ transparent trust building systems, and every participant would have to do their best to understand how these elements empower them, and how they distribute control to them. We already see many of these elements emerging in many different pages around MeatballWiki. Particularly in ConsensusGroup.

: ConsensusGroup is, in my opinion, more felxible and in line with everything that I've rambled on about in this comment so far. This does not mean that I think that BeyondYes can't work. But, I think BeyondYes might be a better system for an larger-participant environment like Wikipedia, for instance. BeyondYes might be a good reforming strategy for Wikipedia's current governance system. BeyondYes could also be a good and possibly efficient route to encourage civic engagement in systems that already employ voting, like state or city governments, or for- and/or non-profit cooperative business models. -- SamRose

Sam, I totally agree with you that some places don't need BeyondYes. We're definitely focusing on larger groups and groups that don't work nearly as well together as Meatball. Wikipedia is one such group. ICANN is another: http://icannwiki.org/Consensus:New_gTLDs

Also, could you say more about how to StaticContract? and the DynamicPlan? could be merged? I ask because we created them as seperate to solve the problem of "How do we know when we're done?" and I'd love to hear your perpsective on this. Thanks! -- TedErnst

: Ted, I think that in a way they already are merged to a certain degree in your framework. Because the StaticContract? is really just a freezing of the DynamicPlan?, based on a unique voting system, with deliberation among "not yet" voters.

: Basically, what I am thinking is that we can say that the StaticContract? is the binding agreement for now, but can be superceded by something better that might emerge from an ongoing community DynamicPlan?, in order to "merge" the two. So, anyone involved can pull the StaticContract? back into the DynamicPlan? and re-work it. The StaticContract? still stays binding in it's current form until enough people agree under the YesMeter? to adopt the re-worked form instead. This allows the StaticContract? to benefit from feedback and emerging issues that may outdate the knowledge and information that led to the creation of the static contract in the first place. Of course, sticking a StaticContract? back into the dynamic plan should require that a good amount of people who made the contract be involved in it's re-working, too. But, it helps to DevolvePower when people in a community know that they can put in motion a transparent community re-working of a contract when conditions change (as long as the re-working is within the bounds of the law). -- SamRose

Two thoughts come to mind reading this, Sam. First, can you give an example of a time when the static contract would need to be changed mid-stream? Second, we (Brandon and I) envision a system where anyone in the community can start a consensus poll on any issue at any time. We don't envision gatekeepers setting up static contracts to limit participation or impose anything on the whole. I'm totally with you on DevolvePower, but I'm not sure I understand the applications you're talking about.

One situation could be that I start a poll and say the yes threshold is 60% (instead of the customary 90%). You come to participate and disagree with the lower threshold, so you make your status NOT YET and vow to keep it that way until we have 90%. The, to make sure, you go recruit 4 friends to do the same. Now, instead of 6 of 10 people needing to have status YES, now it takes 8 of 8 or 9 of 10 (other than you and your 4 friends). By your actions, with 4 friends, changed the dynamics dramatically, and ensured the finished product is more to your liking. Now if you all change your status to YES, the finished product has 15 of 16 YES, which is well more than 90% you thought should be the threshold to begin with. Sorry, that's probably more detail than we need here, but I'm interested to hear other scenarios you're playing with. -- TedErnst

: Ted, I think that what you describe above pretty much accomplishes merging the DynamicPlan? with the StaticContract? (because at some point everyone must come to an agreement).

: But, I think about, for instance, let's say that me, you, and BrandonCsSanders decide to make a StaticContract? based our co-created DynamicPlan? about how to best pool our our resources to accomplish something.

: But, if some unforseen conditions arise that cause our StaticContract? to place too much of a burden on one of us, then it may be necassary to adjust the StaticContract?. Of course, provisions for this can easily be part of the StaticContract?. So, it's not too big of a deal in the grand scheme of BeyondYes, but it is something to keep in mind. I think. -- SamRose

CategoryConsensus

BeyondYes

Discussion