Well, as I see it the details of a more general budget as in your example in ABC% where you turn C into X and Y is not really necessary. The detailed budget decisions will be taken by people who are interested in the detail budget.<br>
<br>About shifting the vote continuously... That is an issue we have talked about in my party, <a href="http://www.aktivdemokrati.se">www.aktivdemokrati.se</a>. We came to the conclusion that the vote should be changeable until either when people themselves agree on when it should be decided OR through a certain time constant that depends on the number of votes cast for and against OR when the parliament votes for it (if our party is a small party within the parliament). <br>
<br><br><div><span class="gmail_quote">2008/2/27, Michael Allan <<a href="mailto:mike@zelea.com">mike@zelea.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br> Martin Gustavsson wrote:<br> > -Maybe we misunderstand  eachother. The "median" result is exactly the<br> > middle result and NOT the mean result.  Therefor it will be accepted  as the<br> > most democratic. Trust me! Otherwise I would agree with you.<br>
 <br> <br>You're right, Martin.  My understanding of statistics is at fault.  A<br> median cannot be skewed by extreme values in the way that a mean can.<br> It's a good measure for the purpose you intend (budgetary decisions),<br>
 almost as good as an actual consensus.  (This is an interesting<br> scenario, not considered before, so I'll answer at some length.)<br> <br> An open budgeting election can be done (e.g. in Votorola) in a similar<br>
 fashion as an open policy, petition or legislative election.  The open<br> approach would have several advantages over the traditional<br> alternative of a dumb, closed poll.  In a closed poll, the electoral<br> authority drafts the question; and people fill in the answers.  Later,<br>
 they are told the results.  Open elections improve on this, as<br> follows:<br> <br> In an open election, the question (or framework) of the election is a<br> public *initiative*.  An electoral authority might pose the initial<br>
 question (just to get people started), but so might anyone else.<br> <br> Furthermore, voters are free to *rewrite* the question as the election<br> proceeds.  For example, consider an initial budget question that looks<br>
 as follows (the voter being expected to answer by filling in the<br> blanks):<br> <br>  A  ______ %<br> <br>  B  ______ %<br> <br>  C  ______ %<br> <br> As the election proceeds, we may discover answers that look like this:<br>
 <br>  A  ______ %<br> <br>  B  ______ %<br> <br>  X  ______ %<br> <br>  Y  ______ %<br> <br> <br> Not everybody will have the expertise to re-frame a question in this<br> way.  But for those who *do* (call them budget drafters), re-framing<br>
 the question is one way in which they can share their knowledge with<br> the rest of us voters.<br> <br> Nor will everybody have the expertise to fill in the blanks.  That can<br> also be a job for our volunteer budget drafters.  Other voters can<br>
 then choose among these drafters, with their variant drafts, and<br> select the one that seems most reasonable to them.<br> <br> Nor will everybody feel competent, even, for that choice.  How many<br> among us can make sensible budget decisions?  For those who cannot,<br>
 how can we participate effectively in the decision?  Open elections<br> solve this problem with a 'delegate cascade'.  The following is<br> extracted from the context of a legislative bill, but the reader will<br>
 see how it applies equally to a budget document.<br> <br>  <a href="http://zelea.com/project/votorola/a/design.xht#ca-culture-community">http://zelea.com/project/votorola/a/design.xht#ca-culture-community</a><br> <br>  ...consider an object of law: a legislative bill for tax reform.<br>
  Most residents are not actually going to read a legislative bill.<br>  (Even professional legislators often read only a summary.)<br>  Nevertheless, almost every member of the community does have an<br>  interest in tax legislation.  Consequently, they also have a<br>
  motivation to vote.  This poses no problem for the consensual<br>  medium, because it is a delegate cascade.  A typical voter who lacks<br>  the time and expertise to read a legislative draft will nevertheless<br>  have time to cast a vote.  She can do this in an informed manner,<br>
  for example, by voting for a friend who is better informed than<br>  herself -- perhaps a friend who is a tax accountant -- and has<br>  similar interests to her own.  By casting a vote on the basis of<br>  trusted and reliable information, such as this, she is making an<br>
  informed decision.  If she has doubts or questions, she can direct<br>  them to her chosen candidate.  By engaging her friend in dialogue<br>  and weighing the answers, she can decide whether to leave her vote<br>  in place, or to shift it to another candidate.<br>
 <br> You see when discussion comes in: *during* the election, not before.<br> This works because the election is a continuous, non-stop, never<br> ending process...<br> <br><br> > - Yes, before every vote there is discussion trying to reach better<br>
 > solutions and hopefully understanding and consensus and if this is not<br> > possible at least we always reach consensus about how to vote. We have done<br> > this so faar. It works good.<br> <br> <br>Nevertheless, it is an improvement to have a continuous election, a<br>
 continual discussion.  People ought to be voting, asking questions,<br> and shifting their votes accordingly, at their own convenience.  It is<br> easy for the electoral authority to calculate the results it needs<br> according to its own timing (e.g. annually for the budget), but the<br>
 election and the discussion ought to keep on going.  (In other words,<br> open elections are for communities.  They run on community time, not<br> political/administrative time.)<br> <br> > -Programming language?<br> <br>
 Java.  External interfaces (such as Web user interfaces) can actually<br> be coded in any language.  But the core of the system is Java.<br> <br> System administrators will also use scripting languages in order to<br> customize electoral services (elections and electoral register).  The<br>
 system will support a variety of common scripting languages.<br> <br> A script is how you could calculate a median.  This would only have to<br> be done if people failed to reach consensus.  The budget drafts<br> (expressing variant resource allocations, for which people vote) would<br>
 have to be composed in a *structured* markup language. (Like XHTML.<br> It's the latest standard, anyway, for all Web docs.)  You could easily<br> read and parse such documents with a script, and extract the values.<br>
 The script could also read the vote counts from the election.  It<br> could then calculate the median result.  The budget documents,<br> scripts, etc., on which the calculation was based would be public (as<br> are all electoral results) and open to independent verification.<br>
 <br><br> --<br> <br>Michael Allan<br> <br> <a href="http://zelea.com/">http://zelea.com/</a><br> <br> <br> </div><br><br clear="all"><br>-- <br>Peace vision -> More democracy -> How? -> <a href="http://www.aktivdemokrati.se">www.aktivdemokrati.se</a><br>