Instead of knocking on a colleague’s door or calling over the cubicle wall to air out an idea, Fried says, we should be using a chat tool to flag him so that if he is heads-down getting his “real work” done, he needn’t feel obligated to engage in our latest Big Idea.

Fried believes his company’s chat application (BaseCamp) is the answer to interruptions because unlike calling over the cubicle wall, chat tools allow  coworkers to decide whether they want to engage now or later. If my colleague doesn’t have time right now to humor me, he can ignore my request until he does.

Fried is right in saying that it’s hard to put off or ignore a knock on the door or a call over the cubicle wall. Where he’s wrong is in the assumption that the right to ignore an immediate request doesn’t extend to the telephone. Actually, ignoring an instant request to talk is what voicemail is for. Even a call from the boss can go to voicemail if I’m in a meeting with our customers or our community contributors. Most of us won’t leave many people hanging to satisfy one person, even if that one person is our boss. And most bosses I’ve encountered are humble enough to agree that they’re not more important than a meeting room full of people. I’d guess that most employees are just as likely to ignore a phone call as a chat message.

The most telling aspect of Jason’s post is his assertion that unplanned requests for instant feedback can be fueled by arrogance. Such a request says “My agenda is more important than yours, so drop what you’re doing and listen.” Calling meetings on short notice or popping up at a colleague’s cube just anytime to air out ideas are bad habits.

I say this as a repeat offender. In my early days in management, I was entirely oblivious that my interruptions were bad ones. Even today I welcome cubicle interruptions from coworkers and instigate them myself. What Jason’s post helped me see is that when I want to brainstorm a new idea off the cuff, I need to do it first through chat so people can choose whether to engage now or wait till they are at a stopping point later in the day. Or even tomorrow.

Lately, I’ve been airing out more ideas using chat first. But I needed someone to call me out virtually in order to reinforce why this is a good idea and why I need to make it a more consistent part of my work ethos. So thanks, Jason, for hurling that stone into my glass house. I need that once in awhile.

Krispy Kreme doughnuts are such a success that fans camp out overnight for a store opening as if it were the release of a new Star Wars movie. In Creating Customer Evangelists, Ben McConnell and Jackie Huba attribute this success partly to the fact that Krispy Kreme stores feature their stainless-steel assembly line as part of the “experience.” This mystique — this feeling that the shiny Krispy Kreme machines are making something for you right now — makes Krispy Kreme special. The doughnuts are warm because they popped out of that magical machine not yesterday, not a few hours ago, but right this minute.

I think wiki evangelists can learn from this.

Wiki content, by its very nature, is fresh. Contributors add hundreds of edits and scores of new articles per day. Most wikis have special pages that link to the newest edits, but these special pages are buried. Many wiki communities run projects where multiple authors play various roles (researchers, subject matter experts, copy editors, etc.) and assemble articles in a process resembling an assembly line. On an active wiki, you can bet something was authored just minutes ago, like a doughnut Krispy Kreme dropped fresh out of the oven and handed to you while still warm. And yet most wikis don’t make this just-out-of-the-oven freshness obvious.

While a MediaWiki site’s New Pages or Recently Edited Pages section shows the latest edits, driving customers to these articles wouldn’t be effective marketing because most of the articles listed there are stubs. They’re not among the wiki’s better articles. But something I’ve noticed in FamilySearch Wiki is that when an article hits a certain number of edits — say 100 or so — it starts to become pretty engaging.

Sure, sites like Wikipedia have sections for Featured Articles and What’s New, and these are certainly worth creating on any wiki. But wikis need a feeling of every-minute freshness long before their contributor communities hit the critical mass required to maintain Featured Articles or What’s New sections. Newer wikis need a programmatic way of featuring not just new content but new, mature content. Featuring content that has not only received recent edits but that has also received enough edits to make it interesting gives  customers a feeling that there’s a quality article coming off the line each hour or even each minute.

So the question is How can our wiki automagically show a conveyor belt full of well-written articles — a list of articles which are pretty engaging and which have reached that threshold within the last few hours or minutes? Should a wiki have a frame that lists the subject lines and first couple sentences of such articles? Could the frame be called something like “New Edits” or “Recent Writings?” Is there an easy or bot-driven way to include such a pane in a wiki, particularly in a MediaWiki site?

What do you think?

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.

If users are most prone to discovery just before they take action, they take action right after discovery. (Um, sure, Mike. Duh. So what?) It follows, then, that if community builders want to convert their site’s reader/consumers into contributors, their best shot is to do it at the very moment when the user sees the value of the site. So how can community builders know when that moment is occurring in the user’s mind?

Thousands of people register on FamilySearch Wiki without ever contributing content. There’s no good reason for this — registration doesn’t open doors to greater functionality — but there it is. It seems an easy thing to assume that registered users should be more easily converted to contribute content than, say, unregistered users.

There’s a mantra in marketing that it takes less energy to retain a current customer than to win a new one. And Web 2.0 mavens like Ben McConnell of Creating Customer Evangelists say that going the extra mile to dazzle customers is what converts them to evangelize a product.

Sunir mentioned that one way to know when the customer understands the value of the site is when he “starts taking actions that fit the mental model.” The only such action our customers do that our system reports to us is registration.

….So why don’t we dazzle them at the moment they register?

I don’t mean we should try to dazzle them with some automated message from the system. The idea an automated message would dazzle anyone is laughable. But human interaction? That’s different. I can’t think of a Website that has ever tried to engage me with human interaction at the moment I registered. That would knock my socks off. Is there any better way to show users they’re valuable? Is there any better moment to get their first impressions of a site, see which parts of the value proposition they are catching, and discover and walk them through the barriers that would otherwise prevent them from contributing? Using this method a high percentage of newly-registered users could be converted to contributors in a matter of minutes.

Obviously, this method of conversion is labor intensive. It doesn’t scale. However, given the reports that the lion’s share of Wikipedia edits are made by a core of a few hundred authors, a method of converting consumers to contributors doesn’t necessarily have to scale very much. In our case, it would amount to less than ten thousand chats or phone calls a year. To an organization like ours that has a sizeable call center, that’s not such a big deal. And there’s no reason we’d have to contact every new registrant — consistency in user experience is wildly important when you’re giving something to customers, but when you’re trying to help them give to you, there’s less need for consistency.

What would the call or chat sound like?

1. Thank the customer for registering.
2. Ask the customer whether she registered in order to contribute information.
3. If the customer would like to contribute or isn’t sure if she has enough expertise to do so, help her contribute something simple.
4. Ask the customer about the projects she’s working on that relate to the purpose of the site. Guide her to information on the site that will help her do a project.
5. If the site fails to produce the content the customer wants, guide the customer in creating a request (wiki stub or forum query) for that content.
6. Thank the customer and terminate the call.
7. Monitor the forum thread or wiki stub. If the requested content doesn’t appear within 24 hours, gather it, post it, and notify the customer that it’s there.

You just created a customer evangelist.

What is a wiki?

Wiki. A short, sweet, strange word whose form matches its meaning — a Web site you can edit without being a programmer. A site where average people like you and me can write things to help other people. A place where we can share information and even collaborate on articles that make us each look smarter than we are alone. A paradise for people who seek information. A wiki community can deliver and revise more research advice information for more users in more languages.

Challenges in the traditional approach

To see the potential of FamilySearch Wiki, it helps to explore the challenges an organization faces in offering free research advice worldwide when they try to do it the traditional way. Prior to the creation of the wiki, five barriers challenged our organization’s potential to provide genealogical research advice worldwide. The first is that publishing research advice for every part of the world is an enormous task. Our publications – paper and digital – covered only about half the world’s countries. Latin America, Africa, the Middle East, the Pacific Islands, and Asia were not fully covered. Somehow, we needed to find a way to cover more of the world.

The second challenge we faced in offering research advice worldwide is that the number and variety of our writers’ assignments prevented us from revising our content rapidly. Many of our publications – including paper research outlines and Research Guidance — were five to ten years old. In a world where new genealogical records are released online every day, we needed a way to revise content faster.

In order to provide research advice for more areas and revise that content faster, we would need more authors. As big as the FamilySearch organization is, our mandate sometimes seemed overwhelming. We simply didn’t have enough employees to do the job. And given budget constraints, we needed to find a new source of authors outside our employee pool.

FamilySearch had a fourth challenge related to the second: the process of adding content to FamilySearch.org was relatively slow and complex. Research Guidance was essentially a static project that had not been enhanced since 2001. The process of updating our research outlines was also slow. Approvals, meetings, stylistic guidance, editing reviews, rewrites, budgeted funds, and programmer time were all needed to change anything on our Web site. If we wanted our content to remain relevant, we needed a way to speed up the writing and publication process from months to minutes.

Finally, we had a challenge in languages. Although there is no shortage of language experts at FamilySearch, we generally published research advice only in English. So if we published a research outline for a Latin American country, we did it in English. This made sense when most of our customer base was English speakers, but that was changing rapidly. We needed to offer content in many more languages.

Possible solution: a community model

Faced with these five challenges, FamilySearch leaders began to ask some questions. In review, we needed a research advice solution that would allow us to cover more of the world, revise content faster, engage more authors, quicken the publication process, and provide content in more languages. Looking around, we noticed that content-rich Web sites were achieving these aims with a “Web 2.0” approach – one in which corporations teamed with volunteer communities to write content.

Many eyeballs make any bug shallow

Perhaps the best example of a content-rich Web 2.0 site is WikiPedia. It is obviously popular – number nine on the Internet – but studies also show that its information rivals the accuracy of Encyclopedia Britannica and the journal Nature. But writers are only human. Mistakes do happen, so it’s also good to know that when people post erroneous information on Wikipedia, it tends to be corrected quickly. The idea behind the success of Web 2.0 sites is best described by a mantra of the volunteer community that developed Linux: “Many eyeballs make any bug shallow.” The idea turns the traditional method of programming and content publishing on its head: Instead of employing just a select few professionals to develop a product, open the development process to a wider group including the volunteer community. If you attract enough volunteers, they will feed off each other to innovate faster, notice and correct errors faster, and thus quicken the pace at which the product is improved. This theory has been proven with open-source software like Linux and Firefox, as well as Web 2.0 content sites like Wikipedia.

Milestones: the current state of the wiki

So FamilySearch aims to leverage the power of the worldwide genealogical community to revise research advice faster, cover more of the world, engage more writers, quicken the publication process, and deliver content in more languages. These are big challenges, so it will take time. Even WikiPedia took years to grow into the powerhouse it is today. Although the wiki will take time to arrive at its projected destination, it is on the right track and has reached some important milestones:

1. It has a simple authoring tool that allows anyone to contribute content.
2. It can scale to accommodate any size of contributor community.
3. It allows users to update content in minutes rather than in months.
4. Its research advice is already more current than that on FamilySearch.org.
5. It now has content regarding parts of the world that FamilySearch was never able to cover before, such as Latin America, India, and China.
6. Volunteer contributors are significantly enriching content on many topics, such as American Indian research.
7. The wiki is drawing highly knowledgeable writers from outside of FamilySearch’s employee pool – people like David Samuelson, a freelance professional genealogist, and Blaine Bake, creator of the Western States Marriage Index.

“Now I know where I can publish”

Probably the biggest victory of FamilySearch Wiki is the way it empowers writers to quickly publish helpful content for others. Jimmy Parker, retired manager of the Family History Library, probably said it best. When he heard about FamilySearch Wiki, he said “This is great. I have three file cabinets full of information I’ve always wanted to publish. Now I know where I can do it.” Professionals and volunteers find that publishing research advice on the wiki is fast and easy. In five minutes, you can add information that other genealogists can use immediately. Contributors get instant gratification, and users get the free genealogical advice they need. This focus on rapid, community-based authoring is why FamilySearch Wiki is already starting to deliver research advice faster, in more languages, to more of the world.

“The web is like a vast library in which the books are completely randomly arranged, each book has a predefined space on the shelf but there is absolutely no categorisation. Search engines such as Google act as librarians to help us find the resources we want, but in a most bizarre way. A web search engine is like some sort of autistic genius with an immense memory and perfect recall of the words in each book but absolutely no idea what they mean.”

“So instead of being able to ask Google to direct us to the section on advanced bungee jumping techniques or DIY space exploration, we have to think of some words that are likely to appear in the books we want and then wade through all of the irrelevant rubbish that happens to contain the same words in the hope of finding something useful.”

Having explained how the primitive Web works, Gledhill goes on to explain the Semantic Web:

“In information science… an ontology is a formal (and rigorous) description of all of the entities, relationships and rules within a particular domain of knowledge. The magical bit happens when you have created an ontology in a particular field. It then becomes possible for computer software to make logical inferences from real world information to ‘discover’ new facts which have not been explicitly encoded.”

Gledhill ends by predicting which fields will likely embrace the work it takes to create the semantic context that will allow their information to be more useful and findable. The Semantic Web, he says, “will be welcomed in any commercial field where the economic advantages of standardisation outweigh the benefits of confusing the opposition, punter [beginner user] or regulator.”

But until that happens, if you want to learn vicariously from the Web 2.0 books I’m reading, see my Twitter page at http://twitter.com/MTRitchey. When I read a Web 2.0 book, I mark it up quite a bit. Then each workday, I transfer my book notes to Twitter. When something strikes me as extra profound or as needing some synthesis into learnings and action items, I transfer it from Twitter to this site and start expanding.

Then, clearing my desktop bookshelf of items I rarely read so I could put these books there, I came across an American Library Association journal whose cover read “Shaping the Future with Student Interns.” I’d been grabbing the stack of ALA mags to put them in a closed overhead bin, and ironically, my morning paradigm shift had come from this six-word headline I was about to archive. Student interns. Read: No-cost, temporary employees burning to prove their mettle. We’ve got ‘em in a university nearby that acts like a feeder school to our corporation. I’ve used them before. They were great, and their effectiveness, semester by semester, has grown as the needs of our customers became clearer and our Website matured. And for some silly reason, as I struggled recently to determine ways to get more volunteers writing on our site, I completely overlooked them.

But interns — especially those from our feeder school — really know our content. They use it all the time. They understand how our library’s materials are organized and accessed. They’re young college students, so they understand Web 2.0. Most have a Facebook account; shop on Amazon, Ebay, and Craigslist; and participate in online forums. Many can write well. Each wants an internship whose assignments are measurable so that calculating success, or a grade, will be easy. Many would like to work for our department because they have declared a major (family history) which corresponds with what our department does.

So it’s no big revelation that an intern adds value to our project. The big question is why we don’t have them all the time, why we’re not always trying to get more, and why I didn’t immediately think of them when trying to figure out how to engage more contributors on our Website. And I suppose the reason for all these failures stems from two issues: First, the tour of duty for an unpaid intern is a bit shorter than the duration of a semester. We have them for only about three months, really. And the ones we get are required to work — hours. That’s a lot of turnover, and it takes effort to show an intern the ropes, train them how to use the system, provide follow-up coaching, design a project that’s big enough to keep them busy, and oversee their progress in that project. But judging from the content we’ve gotten from some of our interns, it’s all well worth it if you get the right interns and don’t just accept anybody who applies.

If interns are well worth the time they take to manage, then what’s holding us back from using several interns continually? Organization, really. We have nobody assigned to recruit, train, and direct interns each semester. It feels like a worthwhile assignment to make. Inasmuch as most of this workgroup’s employees are centered around developing a community of contributors around a knowledge domain, it feels like maybe each of them should be in charge of an intern each quarter. Having one person assigned to recruit interns for the whole team feels wrong, somehow — it feels smarter to have each community coordinator select and recruit their own intern so they can get the right person for the job.

The ALA journal’s article about interns yields something important to remember: That interns are there to learn. “The student who only does clerical tasks or low-priority activities during fieldwork may come away with a distorted view of the librarian’s role and reduced interest in remaining in the profession.” In other words, we probably shouldn’t employ interns only to write content. They should become involved with our product development scrums, design portal pages for a knowledge domain, get other sites to link to the content they create, monitor Web analytics for their domain, and survey users on what parts of their designs do and do not work. They could even design and create within their domain the reference-interview system I described in yesterday’s blog entry which helps beginners get the help they need without having to know genealogical lingo or research methodology.

The takeaway from this six-word journal headline that happily took over my morning: My team will have a meeting Monday. We’ll discuss the things each employee is doing that could benefit from an extra set of (intern) hands. If the list is sufficient to keep some interns busy with mind-growing assignments, employees will be assigned to recruit and engage some interns. If it works — if the ROI is indeed worthwhile, recruiting and managing interns will become a regular assignment for employees each quarter.

Maybe they’re missing the point. A Web 2.0 site of a specific field like genealogy, I’m guessing, takes a long time to reach the point where it resonates with beginners. Genealogy is a skill. When people start out, they don’t know the lingo. What’s a probate record? They also don’t know which records will yield the information they desire about their ancestors. And as it turns out, creating the pages that will lead them from what they know (I want to find my ancestor’s parents) to what they need to do (search census, land, vital, and probate records of a specific jurisdiction) takes a long time. To get them from point A to point B you need to conduct a reference interview where you ask them at least three questions: their research objective (ancestor’s parents), the place (where the ancestor grew up), and the time period (when the ancestor lived). Each level of this question-and-answer tree represents a lot of possible answers your system must anticipate in order to guide the customer to the next step. With millions of places (record jurisdictions) in the world, it’s clear that a system that’ll help a beginner will take a lot of work to build. So if we content specialists listen to our marketing and instructional development colleagues and don’t let this site go prime-time until after we build something suitable to beginners, we may literally never get it built.

But as I said, worrying about the beginner segment of our market is missing the point. The point is that Web 2.0 sites’ bounce rate is 30%-50%, and our site is at 40% now. The site also averages above 600 unique visitors a day. Some market segment already finds the site interesting. Our top contributors — who have only been active for 6 months — have over 2,000 edits apiece, so they clearly think the site is worthwhile.

The people who find the site useful are intermediate and advanced genealogists — people who already know the lingo and have some clue what types of records will yield the information they seek. They use the site to find out where to find those records — and the site is positively rich with such information. Intermediate and advanced researchers don’t need millions of “reference interview” pages to guide them from a research objective to a type of record because they already know a few types of records they can use. They just need to know where to find these records, and that’s the thing our wiki does well.

As I’ve thought about what I should teach at this conference full of genealogists next week, I’ve been tempted to spruce up a bunch of pages on the site so I can show them some truly compelling content that they’d crawl through broken glass to access. Really, “spruce up” isn’t the right term. “Overhaul,” “remodel,” or “grow like a mustard seed” is more like it. To make these example pages have the effect I’d want would take enormous amounts of work. I’d work so hard on the content that I wouldn’t have time to prepare the lesson.

But when I reflect upon Carnegie’s words about teaching and doing, I’m reminded that although our site teaches how to edit pages, we haven’t yet really directed contributors in what we’d like them to do. We haven’t sold them on an idea that the site needs a certain flavor of page fleshed out and developed to its full potential, and that we really need them to engage in adding this specific information.

These people at the conference know about our site. We taught them about it during last year’s conference. Some, if not most, are already using it to access information. Most of them haven’t contributed. They think only an expert can contribute because a contribution must be a full-blown article. They don’t consider themselves experts, so they can’t envision themselves adding anything of value to the site. But each one has done some genealogical research, and in so doing, they’ve learned some hard lessons by experience. And if asked to help a friend or relative get started in genealogy, each one would probably convey that hard-won lesson to that relative. So really, all of them know snippets of information that would save someone else some time. Beyond that, they are also capable of performing a whole list of simple but useful enhancements to the site. Some can edit grammar or spelling. Others can create links between related pages. Others can link to archives, libraries, or digitized records already listed in an article. They can add headings to set off paragraphs, or add transitions between paragraphs. They can add pictures of places, or add information about genealogical news and events in their area.

So what these consumers of our site need to know is that they really have what it takes to contribute in simple but valuable ways. They also need a challenge to step forward and volunteer. They need a chance to commit themselves — to put their contact information on a piece of paper that says “Yes, I’ll help. Call me!” They need to feel safe — like they’ll get the help they need to get started. Whether this means I need to visit them at home, have them visit my office, or do a remote session via Adobe Connect where I can walk them through the processes of making simple enhancements to the site, that’s what I need to commit to do for them. If I do my job right, I won’t have to enhance the site before I teach at the conference. If I inspire them, show them they can make a huge impact by doing simple tasks, coach them in person so they can learn by doing, and then recognize their efforts, I’ll have a new team of people contributing targeted, strategic content to the site. I just need to quit wasting time writing site content and listening to Marketing and spend more time converting consumers to contributors and then guiding them in making the improvements consumers need. The takeaway?

1. Show consumers how they can contribute and that it’s easy.
2. Recruit consumers: Get a commitment.
3. Coach consumers 1:1 so they can learn to contribute by doing it.
4. Focus new contributors in providing content consumers want.