[
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
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