The Wiki’s purpose is threefold (at
least as currently identified):
- Gather
feedback more powerfully than a mechanism such as email. Authors can
attach comments to a page, but also add/modify the page directly. Actually
changing content to describe an idea is more powerful than just describing
the idea. Email only provides the later.
- Identify
process patterns. Patterns are generally not discovered by discrete
descriptions. They emerge by abstracting common elements from specific
examples. Often those examples don’t explicitly describe those
abstractions. A Wiki can make patterns more apparent by showing them “in
use” with commentary and context. Code “smell” is an
example of this, where users can’t quite explain how they know some
code is bad, but they can give examples, build on top of existing issues,
talk around and over the problem, etc.
- Empower
practitioners to create content without the need to learn Composer or to
worry much about metamodels and such. Process engineers can take these
Wiki enhancements and add them to the process through Composer.
- Jim
____________________
Jim Ruehlin, IBM
Rational
RUP Content
Developer
Eclipse Process
Framework (EPF) Committer
email:
jruehlin@xxxxxxxxxx
phone:
760.505.3232
fax:
949.369.0720
From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] On
Behalf Of "Scott W. Ambler" <swa@xxxxxxxxxxxx>
Sent: Monday, August 07, 2006 8:05
AM
To: "Eclipse Process
Framework Project Developers List" <epf-dev@xxxxxxxxxxx>
Subject: Re: [epf-dev] How to
access the OpenUP Wiki
On Fri, August 4, 2006 6:19 pm, Peter Haumer said:
< snip>
> In the same call we define a process on how to use the Wiki with the
> public,
Is the goal of the Wiki just to be able to gather input from the public
from a single source (e.g. we have a Wiki set up on the web which anyone
can post to) or is it something that we can publish to (e.g. instead of
generating straight HTML pages, we generate Wiki pages).
If the latter, it seems to me that we need to be able to support a range
of Wikis.
> how to harvest feedback, assign responsibilities (e.g. discipline
> owners harvest from their disciplines), when and how generate Bugzilla's,
> when to upload new versions of OpenUP to the Wiki, etc.
Shouldn't the Wiki just link to the current download page to keep it easy?
> We write up an introduction page for the public wiki experiment explaining
> the scope and communicating the usage model to be posted in the Wiki as
> well as EPF homepage.
Make sense.
> We clean-up the Wiki, upload the latest OpenUP version, and announce the
> Wiki experiment to the public
The Wiki needs to be as easy to use as possible. If we're only using it
to gather feedback, how is this any better than a mailing list?
- Scott
Practice Leader Agile Development, IBM Rational
http://www.ambysoft.com/scottAmbler.html
Refactoring Databases (
http://www.ambysoft.com/books/refactoringDatabases.html
) is now
available.
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
