Inky Fingers - the Perils of Collaboration

As part of the European Public Services 2.0 initiative that I am involved in, we used the mixedink tool, but we had quite a few problems. The creators of the tool were very helpful and clearly if we choose it, it was because we (and in particular me) were very impressed with the idea behind it and the way it was developed. You can see the output from the exercise here and my initial comments on that output and next steps here. Interestingly, it looks like we will now move to a conventional wiki to complete the final version of the declaration. So what went wrong?

Well, there were some minor technical and user-friendliness issues, but these are only to be expected in a new tool, so I am sure they will be eliminated. A more significant issue, however, was that people found it difficult to interact with the underlying process. What attracted me to mixedink was my sense that wikis work well for lists (where each element is fairly independent) or for fairly factual things, but work less well for crafting a document which is intended to be a coherent whole and have maximum impact. Mixedink seemed to offer a better way forward because if you and I differ on the style of the document or how to make it most impactful, we can each draft a version and then see which garners the most votes. On a conventional wiki the fear would be that you and I would engage in a permanent battle as I sought to make the document more formal sounding and you sought to make it more funky (or vice versa).

In fact, combining drafting and voting proved difficult. The more versions we had the more confusing it was for the participant. This also meant that we had no confidence in the outcome of the rating process. If one version had 10 votes and someone came along and improved the wording in a few places, even if the new version was manifestly better, there was no guarantee that 11 people would come along, notice that there were two very similar versions and then compare the two and vote for the superior version. So, in practice, I suspect it was pretty random which versions got read and which versions got votes. We also had to encourage people when doing a new version to somehow explain or highlight what was new about it. But this was not built into the tool, so again was rather hit and miss.

If I was doing it again, this is how I would like to do it. Stage One: Publish an Initial Version with request for comments and ideally with the comments being rateable and perhaps displayed in order of current votes. Obviously people would have to be encouraged only to put forward one idea per comment. However, this approach should mean that anyone coming into the process would immediately be invited to agree or disagree with the most popular comments on the initial version that had been made up to that point in time. Stage Two: Publish a Second Version taking on board as many of the comments as possible with comments given an importance commensurate with the number of votes they got. Allow comments again as in Stage 1 but encourage people to make more concrete suggestions (e.g. delete para 2 or replace sentence 3 of para 4 with "..."). Stage Three: Publish Third Version based on feedback on a wiki to allow the group to do any necessary fine-tuning. (Obviously to simplify the process either Stage 2 or Stage 3 could be dropped). Would this be a better way for a group to collaboratively produce an open declaration as we are trying to do?