Feeds:
Posts
Comments

Archive for August, 2009

I have a learning to share with those of you who are interested in…

  1. best practices regarding community governance and how to run a community writing project efficiently;
  2. how the U.S. Census and U.S. Vital Records wiki writing teams on FamilySearch Wiki are doing;
  3. an executive decision made yesterday which should help our the U.S. teams avoid unnecessary re-work.

Until yesterday, I didn’t understand why Wikipedia leaders are wary of a straight vote to decide issues. Now I understand why they value consensus significantly higher than majority, and why sometimes it’s even necessary for Jimmy Wales to make a ruling as “Benevolent Dictator” <g>.

According to U.S./Canada research consultants, a lot went well in Sprint 1. They built a meeting area, started standup meetings and post-scrums, started learning scrum through practice, and learned a lot about communicating and working as a team. One thing that consultants felt could be improved, though, was that we need to churn less and execute more. Part of the excessive churning was caused by often reconsidering what information to show in an article and how it should be presented. Should we lay out census links to different sites in a table or in paragraphs? Should we include only one type of link to an Ancestry.com census, or include three links leading to Ancestry’s Library account access, personal account access, and Institution account access?

Wiki teams do most things democratically. So when we have an idea of how to lay out an article, we present it to the team for feedback before replicating our idea on, say, 50 state census pages. The decision to replicate the idea across many pages hinges on a vote. In the beginning of Sprint 1, we were basing decisions on a majority vote. That’s fine when you want to get an initial decision on whether to replicate a new idea across 50 pages. But we learned that once an idea gains initial majority support and is replicated across many pages, it’s time to forget about majority votes and start thinking about consensus.

So why does majority rule bow to consensus after a stylistic idea is implemented? Because the opinion of the majority changes constantly. Projects gain new authors over time. In our census project team’s case, new research consultants began to be freed up from other assignments, making them available to work on the wiki. So in this case, an idea to include three types of links for Ancestry.com censuses based on the different accounts a patron might be using won majority approval initially, and was implemented over 50 pages dealing with census records in various states. But as the project team gained members, the majority shifted the other way. The majority opinion now was to include only one Ancestry.com link for each census, and have that link lead to another page where links to the three kinds of Ancestry.com accounts would reside.

If approved, this new decision would force us to redo all the 50 state pages we’d done on the census, as well as forcing us to create 50 new pages with the various Ancestry.com links. We’d done this kind of back-and-forth revising on two other issues during the sprint, and it was killing our forward progress. It seemed like every time the project gained another one or two contributors,  the majority opinion on some style/layout issue would change, and we’d end up reworking a lot of articles. This waffling and constant re-working of articles was bad for morale and performance, so something had to change.

That’s when it hit me: Wikipedians have expressed reservations about straight votes and majority rule. And although I don’t remember them really saying <why> straight votes and majority rule don’t always work, experience was teaching us the “why.” If all a community needs to force a stylistic change over many pages is for the majority opinion to turn, all one needs to do is to bring in more contributors to change the vote. Thus the majority opinion on a hot issue will change back and forth many times as new contributors (voters) engage the project. One possible solution might be to demand that only one vote takes place on each issue, or to require that an issue can have only one vote per year. However, limiting the frequency of votes on an issue can stifle essential changes that have incredibly broad support.

That’s where consensus comes in. Once initial majority has been reached on the style/layout/information of a large body of articles, it’s time to discontinue rulings based on majority and start requiring rulings based on consensus. After we’ve written the first draft of 50 state articles, a 5% shift in majority opinion should no longer compel us to change all those articles. That is inefficient – it forces change too frequently. After a collection of 50 similar pages has been written, if the community wants to change how the articles are presented, they need to reach not just a majority, but a consensus. A consensus shows much stronger support for change, and will tend to prevent rework except in cases where change is essential.

So what percentage of the vote is needed for a consensus? Wikipedians say it varies according to the issue. But what we’re trying in U.S./Canada is a 70%/30% split. If we’ve written 50 state census pages a certain way and someone wants to change the style, they need 70% of the voters to agree with them before the change will be made. Hopefully this will quell a lot of unnecessary re-work of articles while allowing changes that are essential and truly supported by the bulk of the community.

Read Full Post »