Wednesday, August 18, 2010

Using Wikis: Project Process (Details)

Content collection, draft, stakeholder review

  • Contact the sources/SME who will help you define the key talking points
  • Create the structure aligned to similar deliverables already created
  • Create your first draft
  • Validate the talking points and the draft with the key stakeholder for text content
  • Clean up the content with the new data from volunteers and the stakeholder review
  • Send the wikipage to the copyeditor for the first review 
Note: Although, I prefer the industry standard of one copyediting cycle per product,  for the Bookshelf project I added two copyediting reviews because I had concerns around quality of the final product. Here are the reasons for that concern: 1.In the Wikipedia/Wikimedia world, everyone is encouraged to access the page and edit content to help improve the article. 2. The project team, including the writers and copyeditor are geographically distributed or working in a remote setting. 3. English is a second language for a couple of writers and a key content stakeholder. 


  • Ensure the writer follows the writing guidelines. Help the writer understand by explaining what and why the change was made so it is easier for the next time
  • Ensure that the deliverable is aligned to the design standards established for the project
  • Contact the Project Manager to define and establish standards for new styles
  • Best practice: Writer to not touch the content till copyediting is complete
  • Best practice:Writer to direct the community to Discussion page for any other edits or comments (and not edit the page directly while the copyeditor is reviewing the page)

Final stakeholder review

  • Give a heads up to the key stakeholder on the day when you will have the content ready for review (maybe a week in advance)
  • Best practice: Highlight specific areas you want the key stakeholder to focus on. For example, you added a new topic since the last revision
  • Ensure that your deliverable is ready, final, and of a quality that you might want it to be printed (you do not want to change the text too much once the key stakeholder has given a final approval)
  • Implement stakeholder review and send for copyediting
Also published here.

Thursday, August 12, 2010

Using Wikis: Project Process

In my current role as the Project Manager, Bookshelf (Wikimedia Foundation), we use wikis (obviously!) for project management, content development, and testing. As we charged ahead with the first deliverable, I found myself struggling to define a project process that included the Wikipedia community (particularly in content development) and manage risks associated with everyone editing the same content with the need to control the overall product quality and minimize communication overheads between teams. 

Here is the summary of the overall project process that I created and currently use (think funnel):
Step 1: Content collection, where everyone is welcome to edit, contribute, and help us define the content elements for that deliverable. The project team needs your perspective and knowledge (and access to information sources)
Step 2: Structure and initial drafts, where the page is edited by the copyeditor, writer, and the key stakeholders. Everyone is welcome to review the page but please use Discussion to post your comments and ideas.
Step 3: At this final stage, only the copyeditor and the lead writer edit the page.
For all the stages, you will find the writers/leads on the deliverable communicating with you using a banner at the top of the page.

Why this process?
We are trying a fine balance between leveraging crowd knowledge and ensuring high quality of deliverables.

  • Project process, schedule, managing risks and stakeholder expectations: Project Manager
  • Deliverables: Lead assigned to each solution
  • Wrting styleguide: Copyeditor
  • Design: Graphical designer
Also published here.