You must log in to edit PetroWiki. Help with editing

Content of PetroWiki is intended for personal use only and to supplement, not replace, engineering judgment. SPE disclaims any and all liability for your use of such content. More information

How to Manage a Wiki Project

Jump to navigation Jump to search

A WikiProject is a collection of pages or activities devoted to helping to grow and develop the wiki or add content to a specific topic or subject in the oil and gas industry.  With a WikiProject, you can:

  1. Bring groups of people together to work on a project
  2. Separate out the work that needs to be done
  3. Give instructions that can always be updated within the wiki
  4. Find the best ways to communicate with each other

A WikiProject is a community venture in which contributors work together to create a collection of pages devoted to a specific topic or family of topics within PetroWiki. WikiProjects consist of project pages, which enable the management of the work, and content pages, which provide petroleum engineering guidance. All known WikiProjects are listed at [[1]]. This page is a collection of best practices about how to launch a wikiproject and organize a team of contributors to write the associated content pages.

Define the project, then recruit

A wiki project is defined on a project page, which documents a project's scope, assignments, and progress. Many wikis contain chicken-and-egg discussions about which to do first -- recruit a team or create the project page. Creating a project page first helps to define the scope of the project and possible assignments. Knowing what you want volunteers to do is very helpful when recruiting them because that helps you to recruit for specific skill sets. It also helps prospective volunteers commit with confidence, knowing that the tasks waiting for them are a good fit for their skills.

Components of a project page

Some possible components of a project page are:

  • A proper title (see Creating the project page below).
  • A welcome to new team members.
  • Usernames of each team member. These usernames should be links to user pages or user Talk 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.)
  • Links to any communication tools the team will use (like Online Community, Skype, or Adobe Connect.)

Creating the project page

If you would like to create a new project, follow the naming conventions for WikiProjects to help make your project easy to find:

  1. The name of the project should begin with the word WikiProject followed by a space.
  2. After the space type in the name of the project. Example: WikiProject Hydraulic Fracturing
  3. Be sure to add the new project to the list below, under the subject heading that is related to the new project.

People propel projects

Successful projects aren't launched just by creating a project page. A project isn't a project without a group of contributors. If you want a project to succeed, recruit a group of dedicated people who will commit to adding content on a regular basis.


Project volunteers may play a variety of roles. (Note these are not system roles requiring specific system permissions; these are socially-defined 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.

Be a friend -- communicate often

A wonderful way to make teammates feel appreciated is to look for them on the system and continually ask whether they have any questions. It doesn't even matter if you know the answers -- you may just help them get answers by routing the questions to the right people. There are many tools you can use to communicate with other contributors:
Discussion Tab
Discussion Tab
  • The Discussion tab attached to a project page is a convenient place to discuss ideas for the project.
  • Various wiki groups can utilize SPEConnect to collaborate if they would like. [SPEConnect]
  • Traditional methods such as phone or e-mail or chat.

Finding your teammates

One way to find your teammates is to add links to each of their Talk pages to the project page. When you leave messages on their Talk page, the system will send them an e-mail to notify them.

To find who is contributing to the wiki at any given moment, you can:

  • Click Special Pages on the navigation bar.
  • Click Recent Changes to see who is doing all the latest changes on the wiki. Or if most of your project contributors are new to the wiki, you can go to User Contributions, enter in a date, and click Show contributions of new accounts only.

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 on a similar subject wikiproject, see [[2]].

Have writers periodically report percentage of completeness

Project leaders find that it is useful for team members periodically report their progress. 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.


When regarding an article, each writer's idea of "complete" is different. For some, a wiki article will seem ok and to another author the article will seem lacking content. Some will use headings; some will link to many useful Websites; some will research exhaustively; some will link to webpage rather than creating a short synopisis of the information; 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 above mentioned 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 need some fixing and fix them up?

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 the basic info to be included, assign specific subsections to individual members so the whole page insn't too much and a final person to do a quick review for completness. When working on sub-sections - have the indiviudals 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 completed pages such as references, cross-linking, images (with permissions) etc., so there is a specialist adding content to pages that knows the territory well.

All can edit the same content as sometimes experts miss the most obvious information regularly. This is the purpose of the wiki that everyone who has something to add will add their content and this is how the wiki will continue to grow.

Make assignments more granular than "Revise Page X using Template Y"

It is more effective when contributors are given smaller assignments and more detailed than "Revise Article X using the headings on page Y." A successful suggestion for volunteers is this:

  • Creation of tables for Gas Turbine Meters. The request for volunteer "x" to assist on this project could be made on thier user:talk page under the heading "Need your assistance, X"

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 feeling as if he is being stalked. It breeds some resentment and defensiveness, even if User B is adding good content 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 new content rather than following User A's contributions and fixing them. There is a lot of new ground to be planted in the wiki; a lot that has never been developed; a lot of places, topics, and subjects that have never been written about. It's easier to keep everyone happy if contributors aren't made to feel like someone is watching and policing all their contributions. In order to keep all contributors happy, it is sometimes necessary to tell a contributor "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. This equally applies to wikiprojects. Each project should discuss and potentially adapt a project management style that works best for them.

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

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. There are many platforms available that make virtual meetings easy to conduct.

See also

When your project is complete, or needs to go inactive; please update the following link [Need page created]