[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [epf-dev] Validating Method Content
- From: "Chris Sibbald" <Chris.Sibbald@xxxxxxxxxxxxx>
- Date: Mon, 10 Jul 2006 13:45:10 -0400
- Delivered-to: email@example.com
- Thread-index: Acah8HIAlxTzpdX9SjCxBlWQfBQIDwCVnTYQ
- Thread-topic: [epf-dev] Validating Method Content
This looks like a reasonable process. In fact, it is
pretty much the process I have been following for the RM and CM
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
Perhaps we should establish review boards for each
discipline/package to perform the final validation?
When would the bug be "closed"?
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).
Senior Software Engineer
IBM - RUP Team |
07/07/2006 09:34 AM
Eclipse Process Framework Project Developers List
|[epf-dev] Validaitng Method
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
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
- 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
- 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
We should also have some kind of acceptance test where all
content is reviewed for spelling errors, consistency, globalization
What do people thing? Would this be more effective than what
we have now, or can this plan be made better?
Ruehlin, IBM Rational
Eclipse Process Framework