Re: Anyone using Wiki for collaboration?

[Megan Golding <mgolding -at- secureworks -dot- com>]

Thanks, Eric, for your ideas and thoughts on using Wiki in a corporate
setting. I have some additional thoughts, below.

On Mon, 2002-04-15 at 22:55, Eric J. Ray wrote:
> MG >* Documentation repository for project docs
> MG >  If you're writing project-related docs,
> MG >  then their home will be in the Wiki. For
> MG >  example, we'll store the release plans
> MG >  on the Wiki.
> 
> We do this--all project docs live in Wiki, and updates
> and maintenance is a collaborative task.

Our development process calls for about 11 documents per project,
starting with a Project Proposal and ending with Test Results and
Post-Mortem documents. Given that I work for a very small company,
keeping up with these documents is incredibly time consuming in terms of
the number of people available per project.

If a document misses even one update, my experience has been that people
will not refer to it again. The sentiment is something along the lines
of, "I'll go ask Bob about the Deployment Plan because I know the
document was out of date last time I checked."

When everyone on the team has the power to publish new information, the
likelihood of missing an update is decreased. Wiki provides us this
power with a pretty easy to use interface.

Since project docs are considered primarly for the development team's
eyes (plus a few other internal-to-the-company customers), we don't have
to worry about formal language, good writing, or even spelling. If
there's a problem with the docs, anyone can ask a question or even fix
the inaccuracies.

Empowerment -- turning consumers into contributors -- is the biggest
advantage Wiki offers us.

> 
> MG >
> MG >* Technical support knowledge forum. Because
> MG >  publishing to a Wiki is open to anyone and
> MG >  because there's almost no overhead in
> MG >  writing something up, I want to encourage
> MG >  our tech support folks to use the Wiki.
> MG >
> 
> Hmmm... I'd be leery of using Wiki for that, simply
> because there's no quality control. It's good
> for passing notes and/or working out a solution,
> but not as a repository.
> 

Good point, Eric. I hadn't dwelled on this thought for long...but it did
pop up early on. In my situation, the people working in support are a
small, relatively tight-knit team. Quality control over tech support
information isn't really a problem. In fact, your comment that Wikis are
good for "passing notes" is exactly how I think we'll wind up using it
for support situations.

My company is well-suited to the informal nature of Wikis. This is
probably not true in larger organizations.
 
> We also collaboratively develop white papers and other
> marketing collateral, use Wiki to help coordinate
> testing (e.g, with 24x7 testing efforts and group
> members spanning 8 time zones, Wiki provides a central
> place for the latest info), and even keep group
> vacation schedules and travel plans in it -- it's
> really invaluable.
> 

Vacation schedules & travel plans -- excellent idea! Testing
coordination -- also cool. As a matter of fact, we've worked in rough
test schedules to our project pages. This is mainly for the information
of people outside the development team and acts as an easy way to let
everyone know of our plans without sending a deluge of email to the
staff mail list.

Thanks again for your input, Eric. I now have a few more ideas for using
our Wiki!

Meg


-- 

Megan Golding (mgolding -at- secureworks -dot- net)
SecureWorks, Inc.

Women who seek to be equal with men lack ambition.
	-- Timothy Leary


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Free copy of ARTS PDF Tools when you register for the PDF
Conference by April 30. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com

Are you using Doc-to-Help or ForeHelp? Switch to RoboHelp for Word for $249
or to RoboHelp Office for only $499. Get the PC Magazine five-star rated
Help authoring tool for less! Go to http://www.ehelp.com/techwr

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.