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.
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.
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.
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.
There are several ways to verify unique votes even when (most) communication is through a public IRC room.
(brainstorming)
This protocol assumes:
… 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:
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”…
