Help:How to Run or Manage a Wiki Project

This page is for compiling best practices on running a wiki content barn raising.

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
As I look through the topics pages linked from the Maryland Barn Raising page, I'm seeing a close 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 we 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. 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 you require 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 re-write large groups of pages over and over as majority opinion shifts back and forth. Instead, 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.