Issue-Boundary

[Michael Allan]

Hi Thomas,

I think I figured out how to approach this topic.  I added some
definitions to the theory.^[1]  I was getting these confused:

  poll
    - a collection of votes for measuring the consensus or dissensus
      of voters with regard to a group of rival candidates
    - a collection of votes that are stored in a public repository,
      and from which vote counts are generated

  issue
    - the action that occurs in society as a consequence of a poll

  issue type
    - the category of an issue
    - the general description of an issue, such as provided by leader
      configuration

I now understand how the voters can range freely (just as you suggest)
without being constrained by arbitrary issue boundaries.  There's a
kind of trick to it.  We *do* impose boundaries on polls, but we do
not impose them on issues.  Issues have no formal dependency on polls
or their boundaries, except through the input of voters; and all of
that is freely changeable.  The poll boundaries only serve to allow
for the possiblility of consensus (and dissensus) in the first place.
They do not define the issue.

I picture a poll as unlabelled jar for collecting voter input.  There
are many jars.  New ones are freely available.  It makes no difference
which jar is chosen for any particular purpose, because all of them
are identical.  They differ only with regard to the voter input they
contain.

  poll
    - a jar for votes

  issue
    - the consequence of filling the jar, stuff that happens

  issue type
    - labels stuck on the jar (changeable, removeable)

All we are concerned with is how to move votes across a poll boundary,
whenever the voters want to change jars.  The reasons for wanting to
change jars are not technically relevant.

You wrote:

> For some reason I believed the procedural abstraction would be easier to 
> implement, if we had an issue-less medium.
> But I think, I was wrong. I missed something. The same problems will 
> have to be solved, just at a different point.

Answering in the context of the above definitions: We have an
issue-less medium already.  Issues and issue classification are
external to Votorola.

> Only one thing keeps me still thinking. It has to do with the procedure 
> to "merge issues". That would not be necessary in an issue-less medium.

We should read this as "to merge polls".

> > The problem I foresee is ...  ... The alternatives are hidden from
> > the voter.  Unable to see the rival candidates, she cannot make an
> > informed decision for one or the other.
> 
> That would only happen, if we use the filter to narrow.
> If we use it to wide, then drafts which are not related to our issue 
> would also appear.
> 
> But used in the right way, we would find exactly all those drafts which 
> are concerning the issue that interests us.
> We would even find the rival candidates, that use a different name for 
> the same issue. (Those which in the current version are hidden from the 
> voter, because they first need to merge their issue with ours.)

This is possible.  I was talking about poll boundaries above, but you
were more interested in issue-type boundaries.  Your classification
filters *can* range freely across poll boundaries, emptying the beans
from all the jars, and filtering them independently.

> For example: if we filter out all drafts tagged "Toronto" and "Municipal 
> Code Bylaw 583-2009"
> we will not just find the drafts with the headline "Greener Green 
> Roofs-Issue" but also the ones with the headline "Green 
> Roof-Amendment-Issue". Both are actually concerned with the same issue. 
> And a technical "merging of issues" would not be necessary. We would see 
> both, we could vote on both.

This is possible too.  The two drafts can be in separate polls, or in
the same poll - it does not matter - we vote for whichever we like.

> What now is the technically pretty important "Issue" would then just be 
> a much less important "headline".
> Since the people vote for the text and not for the headline, the 
> headline could be easily changed without asking your voters.
> And there would be a magnetic effect, which would naturally urge all 
> participants to cluster around the draft with the most votes and use the 
> same headline, because this way they are easier to find. And thats what 
> they want: being easy to find by new voters.

The issue (and issue type) is actually not *technically* important.
The issue type is just a bunch of labels that can be attached to
individual poll jars, or to groups of poll jars.  Some of those labels
will be internal to Votorola and re-writeable by the voters or leading
candidates; while others will be external, slapped on by various
independent classification systems.  So I think it works as you
suggest.

(There is no need for the voters to bunch up on single draft, though.
 The drafts in two tree-branches of the same poll can have completely
 different titles and contents, and still belong to the same poll.
 The poll boundary is strong enough to contain the tension, without
 rupturing.  This makes dissensus possible.  From dissensus, we get
 mutual understanding and the possibility of a real consensus.)

> To describe the same a bit more from your perspective:
> Lets keep the Issue-Boundary, but why not allow every participant to 
> easily take all his delegated votes and vote for another issue?
> 
> LOL, finally so easy put in one sentence.

You're right, that's all there is to it. :)  We should say "poll"
instead of "issue".  Then we just move the votes like beans, from
poll-jar to poll-jar.  This differs from my earlier suggestion of
manually copying them.  You picture an automated facility in which the
delegate copies all of her votes across the poll boundary, with the
same ease that she moves them within.

I think you also intend that the votes are *moved*, and not just
copied.  If one of the voters is already voting in the destination
poll (already has a bean there) then she ends up with two beans.  So
this would depend on allowing for multiple or fractional votes per
voter.  (That's a separate topic, still open to debate, but I think
your suggestion will also work with just vote copying.)


[1] http://zelea.com/project/votorola/s/manual.xht#Glossary

-- 
Michael Allan

Toronto, 647-436-4521
http://zelea.com/