Policy wiki

The term ‘wiki’ is used to describe a piece of software that allows multiple, dispersed authors to edit the content of web pages. This software is used to make collaborative documents, as it allows users to comment on and change one another’s text, with strong protocols around visibility of the history of changes and/or versioning. It can also be a database for creating, browsing, changing and searching information (for example, https://wikipedia.org).

Wikis are great tools for building a community and ensuring transparency around the creation or updating of a document. They usually have a range of controls that can mitigate the perceived risk of open collaboration, such as approval workflows, obscenity filters, and the requirement that users create an account and/or be verified.

Wikis can be useful in the confirmation stage, to enable feedback and edits in relation to an existing document or piece of policy. However, while they can be great for building a document from scratch within a trusted group, when working with the public, having something which is reasonably formed provides a better starting point.

Collaborative document creation can be a lengthy process. If you are pressed for time, this might be appropriate for stakeholders but not for use with the public.

Immediate

• Enables broad public feedback.
• Improved transparency of decision-making.
• Enables feedback from dispersed geographic areas.
• Allows the loudest opponents/proponents to feel like they have been heard and have contributed.

Long term

• Improved reception of the final output.
• Better-aligned solutions and language.
• Increased levels of support and enthusiasm for the project.
• Better relationships between the project team and key stakeholders.
• Higher degrees of participant satisfaction and trust.

• A policy wiki requires intensive moderation – if you don’t dedicate someone to monitoring and responding to feedback, a few negative interactions between participants can snowball, putting off other participants and, in the worst-case scenario, generating negative press.
• Lack of representation. If your audience is digitally savvy, wikis can be a great tool. However, if you want a representative sample of a population with diverse technical abilities, you may need to couple this with in-person events, to make sure everyone has the ability to contribute.

Beforehand

• Identify a suitable technology partner to host the wiki.
• Determine a communications strategy, including what the domain name might be and where participants will find information about your project.
• Plan any security, workflow and user-registration requirements that you need early on.
• Draft and upload all documents.

During the process

• Carefully moderate the conversation, including acknowledging and accepting contributions, and rejecting and conscientiously commenting on contributions that aren’t suitable.
• Continue to work on the document as a project team, demonstrating both transparency of process and how you expect others to work.
• Add comments to your own changes so that participants can see your process in action.
• Add supporting documents and links to other material as needed, in order to resolve or legitimise decisions and change rejections.

Afterwards

• Consider adding an acknowledgements section to the final report or document that includes all of the ‘authors’ who edited the report (you may need to seek their permission first). This will ensure they feel like they were part of the delivery team and had some impact on the outcome.