All posts in the topic CivicEvolution - pushing information up to the meta teams (Short link)
Summary
- There are 7 posts — by 3 authors — in this topic.
- Latest post made by Michael Allan at Feb 17 05:26 UTC
Some details on pushing information up to the virtual teams
Let me clarify the terminology since everything online can be considered
"virtual"
A "base team" is group of actual participants, and this forms the base
of the pyramid.
A "meta-team" consists of all of the members of the constituents teams
below it in the pyramid.
meta level 2
/ \
meta level 1a meta level 1b ...
/ | \ / | \
20 20 20... 20 20 20 ....
Meta level 1a membership includes all of the actual team members below
it. There could be 20 base teams below it, but experience will dictate
what size is most appropriate. Likewise, Meta level 2 will consist of
of the actual team members below it, in this case the actual members are
2 levels down.
In a base team, members have full posting and voting rights. Currently,
voting consists of endorsing key points posted by you and your immediate
teammates. I will expand voting to all of the content type in the team
which currently includes comments and resources as well as key points,
and may soon include "value statements"
When 50% of the members of a base team endorse a comment, key point, or
resource (etc) it is automatically posted to the meta team dialogue
directly above it.
In a meta team, members have full voting rights on all content in the
meta team dialogue. Content that gets endorsed by 50% of the
constituent base team members is automatically posted to the meta team
dialogue directly above it.
There are several questions and challenges that will need to be worked
out in practical experiments.
1. Will enough team members vote often enough that this process will be
dynamic and useful? If not, each team may need to elect a foreperson to
speak on their behalf in the meta team directly above.
2. Within meta teams, is it better to (A) aggregate the votes of the
constituent base team members directly, or is it better to (B) count the
majority vote of each constituent team? (A) would allow a minority
opinion to be recognized while (B) might encourage more team
deliberation on the issues. (Imagine 40% of each team supports option
2, but the majority supports option 1. In (A) 40% of the votes in the
meta team would be for option 1 while in (B) 100% of the votes in the
meta team would be for option 2.
3. How do teams respond directly to other comments in the meta team? It
is easier to see how to simply post comments (like this email list which
is not threaded). It is a bit more difficult to post replies to
specific comments/content in the meta team.
4. Can the base teams react quickly enough to maintain a dialogue in the
meta teams, or will the meta teams be primarily about aggregating the
votes of their constituent base teams?
Brian Sullivan wrote:
> A "base team" is group of actual participants, and this forms the base
> of the pyramid.
> A "meta-team" consists of all of the members of the constituents teams
> below it in the pyramid.
>
> meta level 2
> / \
> meta level 1a meta level 1b ...
> / | \ / | \
> 20 20 20... 20 20 20 ....
>
> Meta level 1a membership includes all of the actual team members below
> it. ... Likewise, Meta level 2 will consist of
> of the actual team members below it, in this case the actual members are
> 2 levels down.
I take it the meta progression (upward) is two-fold, toward:
i) a consensus, having the agreement of more and more members; and
ii) the integration of the content, contributed by the members below,
into a single, coherent consensus document
To readers of this thread, I'm a member of a research project team that will
involve 150 citizens from around Australia. As Brian knows, we are very
positive about applying CE. I thought I'd jump in with some comments,
interleaved below.
[I tried to post this yesterday, but I think Do-wire forum crashed and has had
to be restored with a few msgs missing...]
<blockquote>There are a few scenarios that will need to be tested.
<snip>
</blockquote>
My reading is that the two scenarios that Brian proposes differ in important
ways. First, when can the aggregation by manipulated, and also can it be
handled directly or only through lowest-level activity?
IMO, a simpler sequential approach is to wait until the lower-level group has
finished their activity. At that time endorsed key points get promoted to the
metagroup. (Is the metagroup created and downlinked by a process designer or by
the participants?) I would suggest that the foreperson, to use Brian's term,
either gets nominated through personal endorsement (just like content) or the
system can recommend a foreman based on both endorsed contributions and
generous endorsement activity. The metagroup starts up as a separate
deliberative flow once it receives a certain threshold of subgroup promotions.
(Not sure what to do with later promotions, though).
On the other hand, the promotion could occur dynamically as key points receive
sufficient endorsement. Attention to the metalevel occurs live, in parallel.
Content activity remains at the bottom group level. I see this as problematic
as I doubt that the automated result can be a coherent, synthesised
aggregation. If a group of forepeople are nominated in the end to wordsmith
whatever bubbles up, you are no further ahead than the sequential method.
So I'd recommend combining the two. CE could provide a read-only metalevel view
of well-endorsed points, thus promoting cross-pollination of ideas across all
lower levels. But the process should be sequential, in that each subgroup
should finish its deliberation, finalise its points and then promote both the
points and a foreperson to the next level. The metalevel stops being read-only
and begins to allow editing when it has enough promotions. The whole process
could be symmetric all the way up the structure, but of course at higher levels
it will tend to be fine tuning.
<blockquote>Once the key points have been agreed to, there can be a process of
editing it into a coherent document by a nominated team. The editing
process would be transparent so endorsed comments would arise to
influence the editing process as necessary. Finally, the document would
then be deliberated by the teams and put to a vote by the constituent
team members. If there is a strong minority opinion, they similarly
create a minority opinion document.</blockquote>
A deliberative process is designed to get past the majoritarianism that
produces winners and losers.
I wonder whether key point voting is necessary. After all, you have the
endorsements that took them to the top. Surely a polarised situation would
become evident early and key points on each side would bubble up as they
should. I think a single output document can hold multiple views. However,
through the aggregation process, common ground between them could be
identified. For example, each point could be qualified to apply only to certain
situations. I don't think there should be an expectation that every question
taken up through CE is going to lead to consensus.
I believe the whole membership should simply be asked to endorse the final
document as a whole.
<blockquote>In the end we have not only a document(s), but a complete record of
the
process through which the ideas and document evolved, clear statements
of minority views, and the record of endorsements for the underlying
principles as well as the final document.</blockquote>
I think this is one of the clear benefits of having a structured aggregation
method. I big criticism of processes like AmericaSpeaks or even World Cafes is
that the work of a "theme team" to aggregate is not transparent and might not
even follow qualitative research practice. That the aggregation would in fact
be done by participants rather than process experts is very, very appealing.
What do you think?
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?
Hi Michael,
I like your star-pattern of flow, as it doesn't symbolically
privilege the meta-groups.
But I don't agree that CE should generate a constellation of
documents that require aggregation through explicit voting. As a
medium for online deliberation, I don't believe that CE should be
fundamentally based on the primary tool of majoritarianism, that being voting.
Also, participants need to feel comfortable with the process and
their place in it. If it feels instead like a competitive
"marketplace of ideas", we will see aggressive behaviour that will
threaten the inclusive ideal of the system.
A centering flow not only helps idea movement towards possible
consensus, but also provides a predictable path for nominated
stewards (aka forepersons).
Ron Lubensky wrote:
> But I don't agree that CE should generate a constellation of
> documents that require aggregation through explicit voting. As a
> medium for online deliberation, I don't believe that CE should be
> fundamentally based on the primary tool of majoritarianism, that being
voting.
Is it voting, Ron, that ought not to be fundamental? Or is it
majoritarianism? Voting is fundamental, certainly. Without voting,
it would be impossible to quantify the consensus. (One consensus, one
position, would be just as good as another.) And consensus is the
primary aim of the process, I assume.
Majoritarianism is unwanted, I agree. Wherever it occurs, it can only
hurt consensus formation. If a majority, for example, were to
suppress the voices of a dissenting minority, the discussion could no
longer proceed on a rational footing. In the process I proposed,
majoritarianism cannot occur. No majority ever overrules a minority,
and all minority decisions (even individual decisions) are immediately
actionable. Further, no minority action can ever be erased, or
undone, except by the actor herself. (No other collaborative medium
offers such strong protections of minorities, as does recombinant
text. It was originally designed for creative artists.)
However, in your design sketch for CivicEvolution, there are places
where majoritarianism threatens. There any places, for example, where
a majority overrules a minority, and the process then moves on to the
next stage. In moving on, if the minority position is then untenable
(unactionable) it is effectively suppressed. And if a majority (or
agent of the majority) can erase the work of a minority, then this is
suppression, too. CivicEvolution definitely favours *action* by the
majority. Actions of the majority are favoured in the elevation of
content and actors to the meta-levels. This is not allowed to the
minority. This is one place (fundamental to your process) where
majoritarianism holds sway.
> Also, participants need to feel comfortable with the process and
> their place in it. If it feels instead like a competitive
> "marketplace of ideas", we will see aggressive behaviour that will
> threaten the inclusive ideal of the system.
I agree, and for additional reasons. I agree, because an unforced
consensus depends on rational discourse (as we are enjoying here).
And rational discourse could not be maintained if the discussion were
to become tainted by economic interests (as one finds in a competitive
marketplace, or in the headquarters of a political party). Nor could
rational discourse be maintained if the discussion were to be
manipulated by political powers (as one finds in the administration of
a government, or a business firm).
The process I suggested is free of economic interests, of course.
True, there is a competition among ideas. But the basis of that
competition is *reason*. As long as no external forces interfere with
the discussion, then it will be more-or-less rational (depending on
the capabilities of the participants). In the normal course of that
discussion, ideas that are reasonable will out-compete those that are
unreasonable. (I have the impression that you hope CivicEvolution
will foster a similar competition.)
As well, the process I suggested is free from political power. There
is no scope for coercion through the exercise of authority,
priveledge, group pressure, and so forth.
However, this last point is not true of CivicEvolution. Your design
sketch appears to be that of a virtual bureacracy, organized for the
manufacture of an artificial consensus. I say 'artificial', because
it will be influenced by the management hierarchy; it will be
influenced by the administrative rules, and the privledges of the
specialized members; and it will be influenced, especially, by
pressures to conform with the team. Individual members will be
reluctant to hold up the work of the team, even when they disagree
with it. (If a participant feels like a member of a bureacracy, or
like a worker on an assembly line, then she'll rush to finish the job.
Other considerations will take a backseat.)
The process I suggested is, I think, a viable alternative to your own
design sketch. It is also radically different, which makes the
comparison interesting.