[FoRK] Wikis and other tools at work (was: why requirements docs suck)

Lisa Dusseault ldusseault at commerce.net
Wed Aug 27 12:26:07 PDT 2008

On Aug 23, 2008, at 7:16 AM, kelley wrote:

> But maybe these are biases that are getting in the way of me seeing  
> potential in wikis. Someone make the case. Convince me.

It's a commons problem.  Some commonses work very well, some don't.   
Passionate caretakers are often involved in a successful commons, as  
are community habits forged over long periods of time.  Bad actors  
make a commons harder to maintain.

In Wikis, the value comes to a community if the community invests in  
putting the value there.  But each person is tempted not to invest.   
The information *I* have to put into a Wiki provides little value to  
me there, I need to be aware of the value to others and willing to  
provide that.

There are a few ways to bootstrap to a self-perpetuating Wiki or other  
  - Give people something directly out of what they put into it.   
Flickr is a commons where I get a place to store my photos even if  
nobody else bothers to store their photos.  I can find my own photos  
with tagging even if nobody else uses tagging.  And when other people  
upload photos and tag them, I'm even happier.
  - Make it a deliverable for somebody.  E.g. for a documentation  
Wiki, simply take away the UserEd writers'  other tools and make them  
write for the Wiki first.  Eventually other people may contribute and  
reduce the expenditure required on dedicated UserEd people.

Making maintenance easier:
  - Make it streamlined and easy to maintain.  Make it soooo tempting  
to fix something wrong because it would be easy, rather than hard to  
fix.  Creating a new page should be a click (or equivalent).  Don't  
make any of this complex or involve steps or choices of templates or  
  - Keep ambitions in scope.  A brand-new Wiki of Everything Our  
Company Does Everywhere is too ambitious.  What's the most useful  
first piece.
  - Make it OK and easy to eliminate or push away cruft, outdated  
material, etc.  The spec I wrote for version 0.3 that never got  
implemented because we cut that part of the product?  That should go  
away and never be brought up in searches.  Even if I don't bother,  
somebody that sees that obsolete cruft pop up should be fully  
empowered to blast it away so that the next person doesn't need to.

Some of these lessons brought to you by painful experience at OSAF.


More information about the FoRK mailing list