Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [epf-dev] Validating Method Content
Thanks Jim.
 
This looks like a reasonable process.  In fact, it is pretty much the process I have been following for the RM and CM content.
 
The only question I have is the last step(s) for moving the bug to "Verified".  I wonder if two reviewers is sufficient to provide enough viewpoints/perspectives, or if a broader review is needed?
 
Perhaps we should establish review boards for each discipline/package to perform the final validation?
 
When would the bug be "closed"?
 
Cheers,
Chris

From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ricardo Balduino
Sent: Friday, July 07, 2006 2:16 PM
To: Eclipse Process Framework Project Developers List
Subject: Re: [epf-dev] Validating Method Content


Thanks Jim for proposing that. It actually addresses the "time for review" I mentioned in the other email (before I saw this one:-))
Now, it's a question of who plays each role (author, reviewer 1, reviewer 2).

Cheers,

Ricardo Balduino
Senior Software Engineer

IBM - RUP Team | EPF Committer
www.ibm.com/rational
www.eclipse.org/epf



Jim Ruehlin/Irvine/IBM@IBMUS
Sent by: epf-dev-bounces@xxxxxxxxxxx

07/07/2006 09:34 AM

Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
To
epf-dev@xxxxxxxxxxx
cc
Subject
[epf-dev] Validaitng Method Content





Hello all,
 
The question of what “done” means in terms of method content has come up as we’ve been reviewing content this week. In other words, when can a Bugzilla entry be changed from Accepted (or Assigned) to Resolved, and then to Verified.
 
I propose the following:
  • A Bugzilla entry is Assigned to a content developer, who changes the state to Accepted.
  • The content developer writes content that is complete and understandable, following the plug-in authoring guidelines.
  • The content is committed and one person is recruited to informally review the content.
  • The reviewer checks for obvious errors, glaring omissions, and violations of the authoring guidelines. The reviewer reports the findings via email or comments on the appropriate Bugzilla entry.
  • The content developer makes corrections/improvements and commits the changes. The Bugzilla entry is changed to Resolved.
  • A formal review takes place with the content developer and two others (one of which could be the original reviewer). This is done via the phone.
  • The three parties can accept the content as-is, accept the content pending changes identified in the formal review, or reject the content. If rejected, the Bugzilla entry is changed back to Assigned or Accepted with comments as to why it was rejected.
  • If accepted pending changes, the content author makes the changes and commits them without further review.
  • The Bugzilla entry is changed to Verified after the content as been accepted (and committed if necessary).
 
We should also have some kind of acceptance test where all content is reviewed for spelling errors, consistency, globalization considerations, etc.
 
What do people thing? Would this be more effective than what we have now, or can this plan be made better?
 
- Jim
 
____________________
Jim Ruehlin, IBM Rational
RUP Content Developer
Eclipse Process Framework (EPF) Committer
email:   jruehlin@xxxxxxxxxx
phone:  760.505.3232
fax:      949.369.0720
 _______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev

Back to the top