Help:How to Run or Manage a Wiki Project

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

Project page
Create a project page to help define the project scope and its components, track progress, and foster communication between team members.

Components of a project page

 * A welcome to new team members.
 * Usernames of each team member. These usernames should be links to user pages or user discussion pages.
 * Scope of the project.
 * Major components of the project.
 * Orientation challenges that will help new users learn the rules of the wiki and how to use the authoring tools.
 * Tasks that need doing. (Include a way for users to check off the tasks they've completed)

Virtual meetings
A wiki team is usually spread across a wide geographic area, making face-to-face meetings impossible. But many project teams find that periodic meetings help them make better progress on a project.

Software
Several free or low-cost Web-based tools allow groups to hold virtual meetings using their computers and phone lines.


 * Yugma allows up to 20 users to meet virtually for free. If you have tried Oneeko, share your thoughts on its performance on this article's discussion page.
 * Oneeko is an inexpensive tool ($50/yr. for the instructor) that allows screen sharing, chat, shared markup, whiteboarding, file transfer, and Web cam support for up to 8 people. Oneeko requires no download. If you have tried Oneeko, share your thoughts on its performance on this article's discussion page.

Recording meetings
If you can, record or at least take minutes of meetings. Recordings make it easier to:


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

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 coach, coordinator, or moderator, this person is knowledgeable about the subject in question. The team lead usually has a legacy of knowledge he desires to leave to the community, and could use some help fulfilling other project roles.

Project = people
Successful projects aren't launched just by creating a project page. 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, begin by finding a group of dedicated people who will commit to adding content on a regular basis.

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. For a list of orientation challenges used in one project, see WikiProject: Rural Records of the Southern United States.

Have writers periodically report percentage of completeness
Project leaders find that it is useful for team members periodically report their progress. (For example, see the Indians of North America project.) This allows team members to see how the project is progressing overall. This yields a sense of group achievement, and can motivate team members to contribute more to "keep up" with their teammates.

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

Measuring 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 Page 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.

Watch for "edit stalking"
Each contributor has strengths and weaknesses. Some contributors focus all their efforts on watching the contributions of others and adding value to their articles. If User A writes several articles and User B systematically jumps in and edits several of them, this can leave User A a feeling as if he is being stalked. 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 towards 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.