Hi Chris,
Verification is problematic for us. In my
example I’m taking for granted that Verified is equivalent to a unit
test. The content correctly describes what it should. This should be tempered
with the notion that the content shouldn’t just be pie-in-the-sky ideas,
but things that have been found to work in the real world. One informal review
and a formal review with 2 others seems like it would be sufficient, but others
may think differently. Perhaps there’s just some controversial content
that needs a wider review before it’s verified. Either way, I think
review boards are a good idea. It would be more efficient than trying to find
some reviewers every time you write content.
We also need the equivalent of an
integration test. I think this would be the broader review you mentioned. The
content/structure needs to be checked for consistency, e.g. content in
different method elements don’t contradict each other. But I think this
is outside the context of fixing a single Bugzilla entry.
Perhaps “closed” should reflect
that the content has been added to the main branch of CVS. This may be
equivalent to Verified at the moment. But if we change our CM structure in the
future to have an integration workstream, it might be handy to use Closed for
that. Just an idea.
- 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 "Chris Sibbald"
<Chris.Sibbald@xxxxxxxxxxxxx>
Sent: Monday, July 10, 2006 10:45
AM
To: "Eclipse Process
Framework Project Developers List" <epf-dev@xxxxxxxxxxx>
Cc: External Chris Sibbald
<csibbald@xxxxxxxx>
Subject: 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
_______________________________________________
