Help:How to Run or Manage a Wiki Project

This page is a collection of best practices about running a wiki project.

Virtual meetings
A wiki team is usually spread across a wide geographic area, making face-to-face coordination meetings impossible. It is helpful, then, that free Internet tools exist that allow groups to hold virtual meetings using their computers and phone lines. One such tool is Yugma, which allows up to 20 users to meet virtually for free. If you try Yugma, please inform Ritcheymt how well or poorly it performed by adding a message on his user discussion page.

Roles
Wiki projects need people playing various roles. (Note these are not system roles with specific system permissions; these are social roles within a project.) Here are some possible roles or skillsets that project leaders might want to recruit for:

Volunteer: an entry-level member of the project, this person can handle simple assignments such as "copy and paste" tasks and adding links.

Googler: a team member who can do everything a Volunteer can do plus use search engines to find relevant Web sites and add links to those Web sites.

Researcher: A team member who can do everything Googlers can do plus be assigned to conduct research on a subject, make a list of references located, and recommend what should be written.

Writing Specialist/Editor: A team member who can do everything a Researcher can do, plus synthesize what was found by other team members into a succinct wiki page or section of a page. These folks are good at grammar, writing bridges between ideas, adding intuitive headings, etc.

Content Specialist: A team member who can do everything done by Researchers, plus review and recommend additional content.

Team Lead: Alternately called Master (as in Master Craftsman), Craftsman, Subject Coordinator, Subject Moderator, Project Coach, Coach, or Team Coach, this person is knowledgeable about the subject in question. This person usually has a legacy of knowledge he desires to leave to the community, and could use some help fulfilling other project roles.

Project = people
Early learnings from the Maryland Barn Raising and North Carolina Barn Raising show that it doesn't work to start a "project" just by listing on a table several pages that need to be revised or created. A project isn't a project without a group of contributors, which is to say that a project is a group of contributors. If you want a project to succeed, post it after finding a group of dedicated people who have committed to adding content.

Orient new contributors by issuing challenges
To orient new contributors regarding how to use the wiki technology and how to work in teams, issue them challenges periodically. Here are some suggested challenges:


 * 1) Register
 * 2) Edit your user page (teaches the basics of using the editing tool, plus the purpose of a user page).
 * 3) Send message to other users by editing their discussion page.

Record meetings
Recording meetings makes it easier to:


 * 1) Remember instructions given by team leaders.
 * 2) Remember technical tips or guidance given by wiki veterans.
 * 3) Review commitments made by team members.
 * 4) Review and troubleshoot dependencies and bugs.
 * 5) Document and troubleshoot bugs mentioned.

Have writers periodically report percentage of completeness
During a barn raising, it has been found that it is useful for writers to periodically report their articles' percentage of completeness. (See Maryland Barn Raising Tasks.)  This allows all involved in a barn raising to see how the barn raising is progressing as far as content addition is concerned.

Completeness: blood-rare does not equal well done
When regarding an article, each writer's idea of "complete" is different. Like a steak, a wiki article can seem fully cooked to one author and extremely undercooked to another. Some will use headings; some will link to many useful Websites; some will research exhaustively; some will link to OCLC/Worldcat rather than just citing Family History Library Catalog listings; some will add source citations; some will link to related articles; some will post queries on related forums and e-mail lists to get information from other experts. Some will do these things, and some won't.

So what's the solution? Is there a way to get writers to add the abovementioned value in every article? Is there a way to more accurately record a percentage of doneness for each article? Should a cleanup crew be held in reserve to go through articles that have been cooked blood-rare and tip them up to well done?

One possible solution is to work with several writers and see if they can form a team of sorts to add content. Find one writer that for example knows how to add OCLC/Worldcat info, another to add FHL calls, and maybe a third to add ISBNs once the technical issue with those is resolved, and so forth. Have theim do their work in no particular order, since there is no real need for one to 'go first' when editing a page. Still other teams could be set up to add specific content to pages such as references regarding land records, census data, probate, etc., so there is a specialist adding content to pages that knows the territory well.

This is not to say others can't also edit the same content. Experts will miss the most obvious information regularly. All this is to seed the wiki with content, and put 'meat on the skeleton' so to speak. Then everyone else who has something will add theirs, and this is how it will continue to grow JamesAnderson

Revision of long articles -- 1:1 correlation between # of edits and % done?
The topics pages linked from the Maryland Barn Raising page indicate that there may be a correlation between number of edits to a page and how close it is to being "finished." This is true with longer pages like Maryland Military Records, Maryland Societies, and Maryland Maps, not short pages like Maryland Bibliography. There may be some kind of ratio our community can use to calculate % progress on an article we must revise based on its initial word count before revision begins vs. its number of edits or character count of edits as the article progresses. Ritcheymt

Make assignments more granular than "Revise Article X using Template Y"
Barn raisings are most effective when contributors are given assignments smaller and more detailed than "Revise Article X using the headings on page Y." Two such successful highly-granular barn raisings completed by volunteers are these:


 * 1) Creation of tables for each state listing county creation dates and parent counties such as Maryland County Creation Dates and Parent Counties. The request for volunteer Dsammy's help on this project was made on his user:talk page under the heading Need your help, Sammy.

Limit the amount of cleanup contributors do to others' work
Each contributor has strengths and weaknesses. Some contributors like to watch the contributions of others and add value to their articles. This can leave the original contributor feeling like the cleaner-upper is "stalking" them. It breeds some resentment and defensiveness, even if User B is adding good stuff to User A's articles. If you get signals that this is going on, it's a good idea to redirect User B on creating a body of fresh, new content rather than following User A's contributions and fixing them. There is a lot of virgin ground to be planted in this wiki -- a lot of desert that has never been developed -- a lot of places, topics, and records that have never been written about. It's easier to keep everybody happy if contributors aren't made to feel like somebody is watching and policing all their contributions. In order to keep all the contributors happy, it is sometimes necessary to tell a contributor "Hey, why don't you write [New Content X] rather than dressing up [Someone Else's Content Y].

It helps to adopt a formal management process
Project managers in the professional world use formal management processes to help teams progress efficiently on projects. One popular management process, called Scrum, has been very helpful to employees in the LDS Family History Department. Agile vs. Waterfall: A Tale of Two Teams is an artful, 8-minute video contrasting the burnout, distraction, and stressfulness of waterfall management with the focus, motivation, productivity and high morale of the Scrum process. Scrum in under 10 Minutes is a short introduction to Scrum by Hamid Shojaee. Scrum is the WikiPedia article on Scrum.

Require consensus, not just majority, for many-page style changes
If you're running a project which requires a similar style or layout over many pages, arrive at the initial style for the first draft through majority vote. But after the first draft of these pages is created, require a consensus of about 70% for any subsequent change proposals. If adoption of a change proposal requires only a shift in majority opinion, and the topic at issue is a hot one, majority opinion will change back and forth many times as new contributors are added to the project. This forces the community to rewrite or restructure large groups of pages repeatedly as majority opinion shifts back and forth. Instead, after the original drafts are written, require a consensus of 70% before a sweeping style change is made. This quells wasteful re-work while still enabling the most essential changes to happen. For a more detailed discussion and use case, see Community Authoring, Consensus and Avoiding Re-work.