Help:How to Run or Manage a Wiki Project

From FamilySearch Wiki
Revision as of 19:30, 19 March 2010 by RitcheyMT (talk | contribs) (added components of a project page)

Jump to: navigation, search

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. It is helpful, then, that free or low-cost Internet tools exist that 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.

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

Experience in early projects on FamilySearch Wiki show that successful projects aren't launched just by creating a list of pages within a topic 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, 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 here, see WikiProject: Rural Records of the Southern United States.

Record 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.

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.

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.

See also

Wikipedia's guide on how to run a project