CivicEvolution - pushing information up to the meta teams
From:
Michael Allan
Date:
Feb 16 20:56 UTC
Short link
Ron Lubensky wrote:
> I believe the whole membership should simply be asked to endorse the
> final document as a whole.
I believe so, too. Otherwise, those members who disagree with the
aggregate whole (the consensual outcome) will be unable to express
their disagreement. They would find themselves in a dilemma: either
continue to work toward an outcome that is disagreeable; or vote with
their feet, and depart from the process. Neither of these options is
satisfactory: the one leading to a false consensus; the other, to an
unstable system.
So (assume) the aggregate document must be subject to consent.
Members must be able to vote for it, or against it. This leads us to
ask: What happens if they vote against it, and deny consent?
It may be necessary, then, to reverse the process and back out of an
abortive aggregate. A mechanism would be needed to dis-aggregrate the
document; unwind the process; and take the system back to a prior,
consented state. It might then move forward along an alternative
path, toward an alternative document. Hopefully, that alternative
could win the consent of the members. If not, they would try again.
And so on. (A serial process.)
Let's try something (a different point of view, for the sake of
perspective). Leave aside the issue of *consent* for now, and look at
the creation and flow of ideas, of *content*. (You may need to switch
your mail reader to a fixed-width font, here, in order to see these
diagrams.) According to Brian's description, we have:
--> A <-- (higher levels, not shown)
/ \
/ / ^ \ \
/ / | \ \
/ / | \ \
20 20 20 20 20
Multiple teams (bottom), each contain 20 or so members. Each team has
its own ideas, and its own working document. The teams are also
pushing selected content into a common, aggregate document (A),
sitting one level above. (And there are higher levels too, arrayed
further above, in a hierarchy. But we'll just focus on this one.)
We could rearrange the diagram, to yield this (equivalent):
20 20
\ /
\ /
\ /
20 ------> A <------ 20
/ \
/ \
/ \
20 20
Above, we have multiple teams (periphery) pushing content into a
single, shared document (center).
Below, for contrast, is a different flow of content:
2O <----- 2O
\
\
\
\
2O ---------\--------> 2O
\
\ \ /
\ \ /
\ \ /
2O 2O
Here we have multiple teams *pulling* content from each other. They no
longer push to the center (there is no center). Rather, each team
selects the content it likes from other teams, and then copies it to
its own working document.
One more step: Suppose each member is competent to express her own
ideas, in her own working document. In that case, we no longer need
formal teams. We can allow individual authors to pull content
directly from each other:
1 <----- 1
\
\
\
\
1 ---------\--------> 1
\
\ \ /
\ \ /
\ \ /
1 1
What we've arrived at, here, is a process of 'recombinant text'.
http://zelea.com/project/textbender/d/overview.xht
But this only takes us half way. Because now we now have a diverse
population of working documents (one per author), and no single
consensus document. Somehow, all of the individual ideas, all of the
alternative documents, must pull together into a single aggregate.
And that aggregate must attain the consent of the authors (members).
We'll arrive, in a moment, back where we started. We'll see a kind of
*hierarchy* emerge. It will emerge through voting. We can see it
begin to emerge here. This is a diagram of vote flow (not content
flow):
1 1
\ /
\ / (many other such star
\ / patterns, not shown)
1 ------> 1 <------ 1
/ \
/ \
/ \
1 1
Here, authors have the option of voting for other authors. This
naturally results in the formation of many small clumps of consensus
(only one is shown above). It might result in an even larger
consensus. One can imagine a thousand authors, all plunking for a
single author and her document. It would be a massive star pattern.
But something is missing. Recall that there is content flow going on,
simultaneously. The content (unlike votes) is flowing peer to peer in
a variable criss-cross pattern, with little discernable structure.
However, once voting is introduced, the content flow is going to
change somewhat. New content (new ideas) will tend to migrate in a
slightly central direction, toward the consensus documents (those
having votes). The reason is simple: the consensus author is going to
want to attract voters. The best way to attract them is to pull in
their content (voters are also authors, recall), and to be generally
open to receiving ideas from them. So consensus documents will tend
to draw content from the 'cloud' of other documents along
communication lines that resemble (somewhat) the voting lines.
Communication is the key here. Content and ideas do not flow like
water, of course. The flow is almost always accompanied by a dialogue
between authors. One author is pulling select items of content, and
hoping to retain a voter's support; the other is wielding a vote, and
'pushing' ideas. This is fine, until the consensus grows too large.
As the consensus grows, communications become less efficient. The
star pattern (as a network topology) scales poorly. When a consensus
document has a thousand voters, there is no way the author can engage
in dialogue with all of the voters. Consequently, the flow of content
slows to a trickle.
To correct this, we need to improve the lines of voting. For this
purpose, we can employ a different voting mechanism. With a delegate
cascade mechanism, for example, the votes would flow into a
hierarchical structure.
http://zelea.com/project/votorola/a/design.xht#delegate-cascade
The voting lines (and some of the content flow) would then follow a
pattern like this:
--> 1 <--
/ \
/ \
--> 1 1 <--
/ \
/ / ^ \ / ^ \ \
/ / | \ / | \ \
/ / | \ / | \ \
1 1 1 1 1 1 1 1
This appears to be similar to the consensus (and content flow) that
you and Brian wish to foster. However, it depends on a very different
relationship among the members. They are not designated members of an
administrative hierarchy, working as a coordinated team; rather they
are equal peers in a fluid, dynamic community, engaged in free and
open discourse. This has implications. It implies that the process
could be embedded in an actual community. It implies that an entire
town, region, or nation could use this process to reach a consensus.
An application to grassroots legislative drafting is described here
(policy drafting would be nearly identical to this):
http://zelea.com/project/textbender/d/overview.xht#Law-Making
Is this useful? Would this process suit your needs?