FrontPage SiteMap RecentChanges HowTo Blog

Matching Pages:

RSS

Egypt, Anniversary of Revolution of 23 July

WikiBasedDecisionMaking

Wikis are good at collecting things. People contribute, talk, rework, edit – information is accumulated and improved. This makes wikis good knowledge repositories.

Wikis often lack good support for discussions, however. Newsreaders use elaborate technology to filter groups by topic, subscribe to groups based on rules, scoring posts based on authors, keywords, threads, message-ids (eg. to detect follow-ups to your own posts), catch-up, marking and saving of articles, copying them to local groups, etc. Wikis usually lack these features; instead, wikis use the list of “recent changes” to monitor discussions, amongst other things. See RoleOfRecentChanges for more.

Furthermore, wikis intrinsically have a few features that make it harder to argue a case: Sometimes it touches upon many issues (copyright and licenses), and discussing it wherever it seems appropriate will lead to a discussion spread over multiple pages, complicating matters. See ForestFire for some background.

When an opposing view-point is not spreading like a forest fire, but consesus is not reached, things can settle down if all parties use a NeutralPointOfView, or all parties involved can create their respective pages to describe their point of view (also known as EnlargeSpace). Either way, there is no conflict resolution.

Wiki-based decision-making is hard.

When things do not settle down, and difficult decisions need to made, it is often easier to just skip the entire thing and do it; WikiEmigration is the natural result. This works when ProcessOverhead is low. This is also why voting doesn’t work. Voting is a way of making the decisions, but the loosing side need not adhere to the result of the vote if the process overhead is slow. They can just StartAgain.

In this situation, your options are:

Overall wiki situation:

Decisions about the content dominate wiki communities. The need and the ways to reach consensus about the content make wikis so interesting. But other decisions increasingly become important: visions that form the social system, admins needed for spam blocking, rules to form constitutions. Many wikizens feel a new depth of reflection. Thinking AboutDecisions in general may become a topic for many wikis. If better solutions than in real life are found, thinking AboutDemocracy and its rules and institutions will follow.


CategoryWikiConflict

Discussion

There are two situations here; making decisions about a wiki, and making decisions with or through a wiki. The stuff about copyright and the ease of StartAgain are unique to decisions about wikis; the rest are problems with making decisions through wikis.

Here is some more stuff to be worked in (about making decisions through wikis):

On a wiki, it is hard for the community to follow a common agenda. Someone may make a proposal on some wiki page, but there is no guarantee that the rest of the community will even read the proposal. A way to get more people to read it is to reserve some pages for “important things that everyone should read”. However, there is still the significant problem of people who are away for a few weeks. In addition, unless some sort of an explicit list is created, it is hard to measure when people have read a proposal. At what point can people assume that enough people are aware of the proposal?

Even if one could be assured that everyone had read a proposal, it may be hard to interpret their response. Does silence mean that they disagree with the proposal? That they don’t care either way? That they haven’t made up their mind? That they feel strongly, but think their point of view has already been expressed adequately? Or just that they haven’t yet chosen to speak, even if they have a strong point of view?

After the participants have ascertained what the other participants think of a proposal, some sort of discussion usually ensues. Often, compromise proposals and counter-proposals will be offered. Each new proposal requires a new round of waiting to make sure that enough of the community has seen the new proposal.

The above concerns, combined with the “glacial” perception of time in wikis (see WikiNow), tend to make decision-making take forever. First you have to get the community to look at a proposal; then you have to figure out what people actually think of the proposal; then often a new proposal is made, and the entire cycle must repeat.

Potential solutions

It seems clear that some system of WikiVoting is needed in order to gauge the attention and reaction of the community to any proposal. This voting may be non-binding, intended only as a method of communication, rather than a method of making a decision (see RatingAsContent). Combined with an email list for notifying people of impending proposals, this may enable faster decision-making.

In additon, there are still two processes that a community must define: a way for someone to add a proposal for the agenda for discussion, and a way for a decision to be made. Those issues are not specific to wikis.

BayleShanks

Make a “votes” server. Make it so you can log into it, and register a vote. Have it publish HTML fragments for both presenting results, and for collecting results. Users have a password that they use to key their vote in. Users also have a username associated with the password, used for presenting results of the vote, which must be unique to the votes server. Publish an event to OneBigSoup:DingDing when a vote is made, or when a vote is proposed. (A subscription to the web server could make a note for your OneBigSoup:PersonalLogServer.) Have meta-data attached as necessary. Publish information by the OneBigSoup:nLSDgraphs system, so there’s ready access to the information as desired, from whichever language.

I’m trying to figure out how to plug the OneBigSoup:UniversalLineInterface into this, but I’m just not seeing it- votes are something where you sort of NEED a password, and you don’t necessarily want to say your password publicly in an IRC room. Ah, but then of course- you COULD put a line interface into a web form, or issue the line from the command line- yes, that’ll do: You could also hook the ULI up to this, so you can just say “vote (password-of-voter) (id-of-vote) (id-of-selection)” into the ULI, and the vote registers. ;) Because ULI is (usually) REST-based, you can just just put an ULI form on a web page, and everything’ll work out okay.

OneBigSoup. :)

There are several ways to verify unique votes even when (most) communication is through a public IRC room.

(brainstorming)

  • Every day, the vote server invents a completely random string (today’s random string), and publishes it publicly somehow.
  • Each voter makes up their own random string for each vote and also fetches the vote server’s “today’s random string”.
  • The voter calculates a confirmation sum = sha-2( (id-of-vote) (id-of-selection) (voter’s random string) (voter’s secret password) (today’s random string) ).
  • The vote server watches IRC for votes of the form (name) “vote” (id-of-vote) (id-of-selection) (voter’s random string) (confirmation sum).
  • The server does the same calculation the the voter does, and compares the sha-2 in the message with the one it calculated.
  • The vote server replies with one of “validated!”, “sorry, something got corrupted in transmission”, or “Hey! you already voted (id-of-vote) (previous-id-of-selection)!”. (So, should only the first vote from that person count, or only the last vote?)
  • Somehow, the vote server closes the id-of-vote and refuses to accept any more votes on that particular issue (perhaps a fixed 3 weeks after it first sees a particular (id-of-vote) … or some other way).
  • Anyone can ask the vote server at any time for the current totals on any particular id-of-vote, what today’s random string is, or a list of ids of currently open id-of-vote and when they will be closed.

This protocol assumes:

  • good-enough random number generators
  • the passwords and random numbers are long enough to prevent guessing
  • Only one voter and the vote server know that voter’s password (previously communicated over some other, private, communication channel)
  • Somehow, the list of passwords in the vote server is limited to the people who are allowed to vote – no more, no less.
  • enough bandwidth that all valid voters can send a vote to the vote server, even if someone is flooding the channel in a denial-of-service attack.
  • hopefully no man-in-the-middle attack blocks people who vote “the wrong way”, or sends out his own “current totals” that trick people into thinking the results were different.
  • it’s OK that everyone knows exactly how everyone else voted.

… there’s also a way to tweak this into a protocol that keeps it secret which way each person voted … Actually, no, that additional requirement opens up many more vulnerabilities. Avoiding those vulnerabilities requires far more than a “tweak”.

A protocol like this is a technological solution to a small part of the problem. The bigger social part of the problem still remains.

The fact that most elections are conducted under the auspices of an Electoral Authority is often overlooked. The presence of a “neutral, third party” makes it possible to use a simpler system in which the use of the Public hash of the Vote + the Public hash of the ballot can actually be published to allow the Voter to confirm that his vote has been counted and that his choice has been correctly recorded, without compromising the secrecy of the vote. I expect this will be used in a significant percentage of the internet voting that I expected to see in the 2014 municipal elections of Ontario, Canada.

Many elections have 2 seemingly contradictory requirements:

  • a voter is able to prove to himself that his selection was included in the final vote total.
  • a voter must not be able to prove to a vote-buyer that he really did vote the way the vote-buyer wanted.

It’s pretty easy to satisfy only the first requirement, not the second one (such as the protocol I sketched above). It’s also possible to satisfy only the second requirement, not the first one (this is true for the vast majority of voting systems).

As Hans pointed out, one way of fulfilling the first requirement is a trustworthy (and trusted) neutral third party that controls the chain of custody and the final counting.

I remember being surprised to learn that it is possible to satisfy both requirements simultaneously without such a third party. I’ve heard of about 6 such systems – “end-to-end auditable voting systems” – and I would be fascinated to learn about any other such system. As far as I can tell, the first such system was invented in 2006 – perhaps because previously, people didn’t even try to invent such a system – because, like me, they assumed it was impossible.

I fear I am drifting a bit off-topic here. I’ve written up what little I know about “end-to-end auditable voting systems” at http://cryptodox.com/Vote . Is that the best wiki for discussing this sort of voting technology?

Thanks, David. I found this http://cryptodox.com/Vote link interesting. I’m not at all sure how I would answer your question about it being the best wiki for a discussion of voting technology, though.

A few “Observations”…

  • Given a reliable way of confirming the identity of a Voter and confirming eligibility to vote, Voting systems become very much simpler to implement.
    • At the current rate of technological evolution, reliable identification is inevitable in the relatively near future five5 years + or - three, depending on “early adopter” rates for the various methods and broader societal and political acceptance rates)
    • Hence, internet voting is ‘imminent’ (I expect to see a significant change in before the ‘event’ (vote) after the current one).
  • Client-side wiki solutions like TiddlyWiki (especially with its recent introduction of “slices” … Name + Value tuples … provide MicroContent data repositories that can be “read” and computationally processed using the “expert systems” inference engine approach as well as the traditional procedural approach of hierarchical IF statements.
    • It then becomes practical to think of an “infinitely” large set of IF(…)s that are simply pooled “blocks of MicroContent” (e.g. tiddlers) and plugins (methods) to process them automatically. Effectively, this becomes an automated, contributor controlled, WikiBasedDecisionMaking engine that can be used quite nicely for…
      • Voting
      • Personal Programmed Trading (based of RssFeeds)
      • … For fans of Laugh Ins Arte Johnson, try to hear my heavy german accent as I say “Very intereting”. :-)

EditNearLinks: WikiEmigration EnlargeSpace RssFeeds ForestFire NeutralPointOfView RoleOfRecentChanges RatingAsContent

Languages: