Meta-Tool

[David Bovill]

Friedrich - I agree with the logic, and the pragmatics with what you say
below from a theoretical perspective.

However, for I'd suggest that this may be entirely missing the argument I am
trying to make with regard to why (accepting what you say below), it is
still worth exploring some common technical ground between implementations.

The suggestion I make is for a very different purpose. I am not being as
ambitious as to try to map results I just want to be able to display each
LD's different results given the same rough base community / data) - rather
I would actively *encourage* each LD system to come up with different
results in order to create the choice and diversity upon which we can build
a rich set of LD decision making tools. Some will be better for certain
circumstances some others.

What I am arguing for is a practical form of integration between systems
which maps to the human issue of getting users to use a system. For that
there is still common ground that all LD implementations can benefit from,
and that common ground can be more than simply using open ID so that users
can more easily move from one web application to another.

We also need users enough users, debating an appropriate issue in which LD
makes sense. I've seen the following happen a number of times now:

   - a LD software project inspires a number of developers
   - A small group, collects around each implementation
   - Discussion is mainly around theory and implementation
   - Interface and users lag behind
   - Small groups of users do not benefit from LD and revert back to simple
   non-delegated systems
   - The various LD implementations do not gain traction

To counter this I am proposing, that we look to come together to market the
concept of LD together. We look to fund raise for trials together where
possible, while allowing each implementation to go for its own funding and
community projects, and we look to provide a forum where we can collect rich
test data (live and archived), and allow a wider audience to compare
different LD implementations.

Finally I'd argue for a common import export format that minimizes the
trauma of moving between one implementation and another, and maximizes our
ability to run a practical trial in which several implementations take part.

With regard to the aspiration that each LD implementation can inter-operate
in some way with regard to actual decision making - vote mirroring or other
- I'd suggest that something on those lines may emerge later down the road
given, successful cooperation between LD implementations along the lines I
am suggesting. I would suggest that that may be more likely by mirroring the
results of a group represented by members of a particular implementation,
rather than each individual, and mirroring those - but I'd agree with
Friedrich to put such speculation off for a while, and see if there were a
more practical basis for cooperation which concentrated on the real world
problem of not having users and resources to do a big enough test project.

2009/12/6 Friedrich Lindenberg <friedrich at pudo.org>

> Hi,
>
> I like all the talk about push v. pull and how we can create a large
> platform, but I still fear that from a very practical standpoint,
> we're going down a wrong turn here. It comes down to this point:
>
> > Martin Häcker wrote:
> >> ... But in the end, each voter casts one vote for one issue. (Does
> >> this leave preference based voting methods out?)
> >
> > Maybe we can get away with vote translations like the following:
> >
> >  * From ranked to single (R->S), the autocaster takes the top-ranked
> >    R as the single choice S
> >
> >  * From single to ranked (S->R), it marks the single choice S as the
> >    only choice on ranked ballot R
>
> First, you'll have to realize that this is really different data,
> using different levels of measurement and different semantics. It's
> not like twitter and Facebook, where both have activity streams and
> thus you can make some kind of bridge. The answers you get are
> actively dependent on the type of voting system used in the
> application. Voting for or against something is subject to strategic
> considerations and there is no perfect system to circumvent that.
> There is near certainty that if you piped all the data from system A
> to system B without adding any votes in B, both systems would come up
> with completely different results (For this to happen you don't even
> need to do mapping between preference and majority voting, all you
> need is to map between two methods of counting either).
>
> If you do any kind of mapping here, you'll start to actively construe
> voter decisions. YOU CANNOT DO THAT. Asking the voter one question and
> then using that data to answer a completely different question is
> essentially fraud. I've sat in a lot of lectures on media market
> research, a pseudo-science aimed at selling ad space to potential
> advertisers. Even they wouldn't get away with this kind of data
> mangling. Any LD implementation that is intended to retain some kind
> of respect both on a theoretic and a practical level should actively
> try to keep this from happening, down to the level of shutting down
> API access.
>
> So: voter mapping: sure, proposal mapping: yes, graph mapping: maybe,
> but mapping between voting systems which differ even in the slightest
> way: do not do that. NEVER.  No amount of XMPP will fix that. Let's
> rather think about how we can link debates, link arguments, link
> users, and maybe even build little questionnaires incorporating the
> different polls open on an individual issue.
>
> Sorry about the rant, but this point is crucial and it needs to be
> generally accepted.
>
> Cheers, Friedrich
>
> --
> Friedrich Lindenberg <friedrich at pudo.org>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.reluk.ca/list/votorola/attachments/20091206/1744c002/attachment-0006.html>