RE: [epf-dev] How to access the OpenUP Wiki

[Per Kroll <pkroll@xxxxxxxxxx>]

I added 1. and 2. in the list below,
and I consolidated and edited the previous five into 3, with some supporting
bullets.

1. Rapidly gather useful feedback by writing comments associated around content (lock content from editing)
2. Build communities around key content areas (lock editing to be centered around dedicated topics)
3. Rapidly gather useful feedback by directly editing process content
4. Create process content without learning the metamodel or Composer

• Faster turnaround from idea to documented process
• Enables a team to e.g. make a defined process, such as CMMI, more concrete by adding relevant guidance
• Capture process related experience through harvesting
  • Continuous process improvement
  
  Cheers
  
  Per Kroll
  STSM, Manager Methods: RUP / RMC
  Project Lead: Eclipse Process Framework
  Rational Software, IBM Corp
  408-342-3815
  
  
  
  Jim Ruehlin/Irvine/IBM@IBMUS
  Sent by: epf-dev-bounces@xxxxxxxxxxx

  08/08/2006 06:16 AM

  Please respond to
  Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>

  
  

  To	epf-dev@xxxxxxxxxxx
  cc
  Subject	RE: [epf-dev] How to access the OpenUP Wiki

  
  
  
  
  
  
  You’ve provided some very interesting insights, Onno. Based on what you wrote, here’s a potential list that we could present to introduce the benefits of using the Wiki tool with OpenUP:
   
  1.        Increase process performance with timely and specific guidance.
  2.        Improve process customization by easily documenting the actual process on top of the defined process.
  3.        Capture process related experience through pattern harvesting and process-related experiences.
  4.        Rapidly gather useful feedback by directly editing process content. (is this part of 1  & 2?)
  5.        Improve process content without learning the metamodel or Composer (is this part of 1 & 2?)
   
  It seems like this list (or one like it) would be useful to people who were evaluating whether to use OpenUP with the Wiki. Comments?
   
  Regarding #2 above, is Onno’s distinction between actual vs defined process one that we should elaborate on in OpenUP process guidance? Perhaps in some guidance about how to use OpenUP?
   
  - 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 "Straaten, Onno van der" <onno.van.der.straaten@xxxxxxxxxxxxx>
  Sent: Tuesday, August 08, 2006 1:14 AM
  To: "Eclipse Process Framework Project Developers List" <epf-dev@xxxxxxxxxxx>
  Subject: RE: [epf-dev] How to access the OpenUP Wiki
   
  What helps me think about purpose, usage of Wiki technology, is scope. Within my company we found it usefull to distinguish two: project and enterprise. Now of course there is also the OpenUP community, the internet public and maybe more? An interesting idea was discussed yesterday of offering this as a internet service, so there would be no need to install software for EPF users to have Wiki functionality.
   
  More in scope of the project or enterprise is I think that it can help raise the ability to perform a process because guidance can be added quickly and by everyone.
   
  Another interesting viewpoint is I think the distinction between standard processes and defined processes as described in CMMI. Maybe for instance OpenUP is a standard process that is described at a more general level that may not be directly usable to perform a process, or put in another maybe better way, to have a good ability to perform it. A Wiki can help when elaborating the process description so that the resulting defined process can be performed. And Wiki in this respect means quick changes and improvements and fast acceptance.
   
  What I also like is that is a good tool for capturing process-related experiences. When starting from a standard process such as OpenUP or the RUP it can help bridge the gap between the process description and the actual processes.
   
  Best Regards,
  Onno
   
  .
   
  
  

  ---

  
  From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Ruehlin
  Sent: maandag 7 augustus 2006 17:28
  To: epf-dev@xxxxxxxxxxx
  Subject: RE: [epf-dev] How to access the OpenUP Wiki
   
  The Wiki’s purpose is threefold (at least as currently identified):
   
  1.        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.
  2.        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.
  3.        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
   

  This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

  _______________________________________________
  epf-dev mailing list
  epf-dev@xxxxxxxxxxx
  https://dev.eclipse.org/mailman/listinfo/epf-dev
  --=_alternative 0048F012882571C4_=--_______________________________________________
  epf-dev mailing list
  epf-dev@xxxxxxxxxxx
  https://dev.eclipse.org/mailman/listinfo/epf-dev