Issue-Boundary
Thomas von der Elbe
ThomasvonderElbe at gmx.de
Sat Aug 8 03:38:38 EDT 2009
Mike wrote:
> > It took me long to find the point. But finally here it is:
> > The tree you show in Figure 17. Bridging consensus e.g. is actually not
> > really about different levels of abstraction. It is actually more or less
> > the same level.
Mostly I expect. And I guess that's true for all trees in normative
voting, but not completely (see 1).
> > When I looked at it, I always had in my mind the false presumption, that
> > the outer voters would vote more abstract and the inner ones more concrete.
Speaking of the outer voters: many of them *will* vote abstractly I
think. This connects with your Q (when we last spoke) about
auto-delegation. If my own vote for all tax-related issues is
automatically delegated to my accountant (as though I have an
accountant!) then that's a pattern of abstraction (1). There are
other patterns too (2, 3).
> > And this now has to do with the "multiple votes per issue".
> > The delegation I had in mind would more be like this:
> >
> > I give my vote to A because she says, she will make the neighborhood more
> > friendly for young families.
(1) Maybe all of your neighbourhood/community votes are automatically
delegated to her. Or maybe only some of them, manually. (So here is
the first pattern of abstraction again. Call it "procedural".) OK.
(2) Also, maybe A has drafted a "community development policy"
document, in which she outlines the rules for ensuring that all plans
are friendly for small families. The overall policy (community
development) is an issue, and maybe A has lots of votes for her draft
of that policy (small-family community development) because there's
lots of small families in the neighbourhood. So everyone *knows* that
this is the consensus policy (official or unofficial) for the
neighbourhood. The plan drafters know it too, and they take it into
consideration when opening development issues, and drafting
development plans. (Here is a second pattern of abstraction - a
policy. A policy is more abstract and general than other types of
norms, such as plans.)
> > A gives our votes to B, because he says he will make the park nicer and to
> > C, because he wants to plant more trees in the streets.
So those are two issues, park and tree-lines. B has a good
small-family plan for the park (according to A) and C has a good
small-family plan for the curbside trees. OK.
> > B gives his votes to D, cause she wants to build a playground in the park
> > and to E, cause he wants to build a little lake there.
Maybe that's not a good idea. Maybe B would be wiser to think of his
park plan as a master-plan covering the whole park. And D would be
wiser to think of her playground as a detail-plan - a separate issue.
B does *not* vote for D on the issue of the master-plan for the park.
B only votes for other master planners (as a delegate) or not at all
(standing as an end candidate).
(3) B instead *refers* to the playground from within his park
master-plan. He can either refer to a specific plan for it ("and over
here will go D's playground") or to the issue ("and over here will go
the playground"). The second choice seems wiser. B's master-plan
will be more acceptable to the voters if he allows the whole
neighbourhood to reach a *separate* consensus on the various details.
Whatever they agree to for the construction of the playground, or the
running track, or the chess tables, that's what B wants to build in
the various places assigned by his master plan. (Here is a third
pattern of abstraction - composition. Master-plans are composed of
detail-plans, by reference.)
> > D gives her votes to F, cause she wants to build a sandbox in the
> > playground and to G, cause wants to build monkey bars there.
> > F gives her votes to H, cause he wants the sandbox red.
Again, D should not vote for F or G. She should instead compose those
issues into her playground plan. At this level, it is her playground
plan that is master; while the sandbox, monkey bars, swings and
teeter-totters are all details and all separate issues.
F *does* vote for H, because F thinks H has a better plan (or is a
better planner) when it comes to the issue of the sandbox. This is
*not* an example of abstraction, because F will very likely paint her
sandbox red too (in her own copy of the plan) so there will be no
difference with regard to colour between the two plans (F, H). (The
tools to handle this back-flow of text, from candidate-drafter to
voter-drafter, is a big part of what I'm researching right now.) In
general, none of the sandbox drafts will be any more abstract or
concrete than the others - they will all be pretty concrete.
Nevertheless, many of the outer voters may be voting abstractly (1),
even for the sandbox. In the theory/scenario, for example, most of
the parents were voting for Hal, for abstract reasons of safety.
> > From abstract to concret.
> > And this delegation tree stands vertical on the tree in Figure 17. So its
> > more a like three-dimensional cloud of voters.
> > Only the deepest level is then about issues, the way you use the term,
> > right?
True, but only as regards procedural abstraction (1). That's the only
one that can be diagrammed as a single tree, in a single issue-forest.
The other patterns of abstraction (2, 3) are broken out as separate
issues.
Your inverted tree/diamond image is still compelling. Again, many of
the non-drafter delegates near the tree tops will be abstract,
policy-oriented delegates (like A) who collect votes and steer them
toward more concrete proposals. So there's abstraction in the tree
tops, and it may be especially dominant in the early stages of voting,
when there's little concrete to fasten on.
When we add a facility for multiple voting (or fractional voting),
those abstract voters will be able to choose multiple abstract
delegates. So maybe you give one vote (or half a vote) to A because
you care about small families, and another to Z, because he's on a
mission to integrate the poor neighbourhoods with the wealthier ones,
or some other such policy. So there's something of a fan-down at the
top edge of the tree (one to many, instead of many to one). OK.
(0)
/ \ 1
/ 1 \
/ \
/ \
/ (1) (0) (0)
/ \ 2 | 1 /
/ \ | / 1 (0) (0)
/ (0) (0) \ | / | 1 /
(1) \ 1 | \|/ | / 1
\ 2 \ | 1 (4) | /
\ \ | | | / (0) (0)
\ \| | 5 |/ | 1 /
1 \ (2) | (2) | / 1
(0)-----(3) \ 3 | | | /
\ 4 \ | | 3 |/
\ \ | | (3)-----(0)
\ \ | (0) | / 1
1 2 \ \| \ 1 | /
(0)-----(1)-----(6) (8) \ | / 4
\ 6.5 / \ | /
\ / 8.5 \|/
\ / (8)
\ /
(15)
Here I coalesce the two votes of the top voter when they flow together
at the root. Arguably then, she has no unfair advantage.
The two delegates she is voting for are probably abstract (like A and
Z), and therefore do not have drafts of their own. Otherwise, if they
were concrete, it would make little sense to vote like this. Even if
you liked two different concrete proposals, and wanted to use your
vote to push them both into the consensus draft, you'd be better off
concentrating on one at a time. First vote for the left draft until
its text is pushed to the root; then shift your vote to the right
draft, and push for it too. So you apply maximum vote force at any
given time, and have a greater effect on the shape of the consensus
text.
> > I think this sort of delegation is really important, because it can bridge
> > the two extremes: voting on every single issue I am interested in vs.
> > voting for 1 huge political party out of 2 (USA) or 5 (Germany).
> > Can this be realized through Votorola?
I think so. I don't think the separate issues are getting in our way
here. I think they are actually helping. And if problems *do* crop
up, then I think we're on pretty solid ground when it comes to solving
them - brainstorming the theory, or adding this or that technical
feature to the design.
More information about the Votorola
mailing list