Why quality plans should use wiki's

I'm writing up a lot of information in the Project Dune wiki and start to realize the potential and importance of the wiki itself. I have been browsing wiki's for some time, but now is the first time I am actually editing a lot of pages.

The Project Dune wiki is about software quality and has two main purposes. It documents the project and it documents consolidated knowledge about quality.

As I go through the pages, I experience the difference between a site with static information that is maintained by a number of editors versus a site that has freely editable information with a couple of access constraints. So when a reader can become an editor at the touch of a button, it gives the feeling (and potential) of participation. This is important for a human being and for companies to generate a sense of identity.

When a company would use a wiki to document quality plans and use the discussion and talk extensions, consider the difference in attitude that the engineers would have on the quality policy and plans (in the case of companies where only managers are owners of the policy and dictate it 100%). The question is not so much that engineers must have made a contribution on the wiki. The difference is the possibilityto suggest changes to the policy immediately and do so on the record in public.

But I don't think the wiki is immediately sufficient. I've worked in some companies that have a very archaic view of the quality plan / policy. It is probably comparable to code crush, which is when a developer becomes highly defensive against any proposed changes on the code and may get furious when he finds out that someone else messed about in the implementation. Even though the statement is often made that it's totally open and we're willing to change, it doesn't necessarily apply in practice.

It shouldn't be like that. We should consider the quality plan and policy an adopted approach documented and taken by all participants (certainly in the case of the wiki). In this view, the quality manager, managers and people that make decisions become stewards of this information. Their role isn't to judge content, it's to take care of it and continuously ensure that the group as a whole steers the quality plan and policy to better definitions.

Consider opening up your policy and plans to your internal engineers. Trust them to be able to apply common sense (or make sure they receive additional, adequate training to make better decisions). You might also want to back up your wiki with discussion forums. This way, any doubts on the policy can be cleared by other participants with the added benefit that it can also be used to document certain conversations and retain that knowledge.