Hello,
Chris asked me to put the procedure below
in diagram form, so here it is. This is just a start – I’m sure
there are details to add and ambiguities to address.
Note that it only provides a structure for
identifying when method content is “done”. There are no specific
criteria for measuring that content is complete, such as following the authoring
guidelines. This is something we should define soon.
The diagrams also don’t explain when
a Bugzilla entry moves from Verified to Closed. This is another issue we should
probably discuss.
Let me know if you have any questions
about the diagrams.


____________________
Jim Ruehlin, IBM
Rational
RUP Content
Developer
Eclipse Process
Framework (EPF) Committer
email:
jruehlin@xxxxxxxxxx
phone:
760.505.3232
fax:
949.369.0720
From: "Chris
Armstrong" <chris.armstrong@xxxxxxxxxxxxxxxxx>
[mailto:"Chris Armstrong" <chris.armstrong@xxxxxxxxxxxxxxxxx>]
Sent: Monday, July 10, 2006 6:01
AM
To: Jim Ruehlin/Irvine/IBM
Subject: RE: [epf-dev] Validaitng
Method Content
Jim, seems like this makes sense. Any
chance you could put together state machine and activity diagrams for this?
Might be cool to include this in change request/PM guidances somewhere... Oh,
and you misspelled "validating" in the subject (just validating email
content)... :-)
Chris ~:|
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Ruehlin
Sent: Friday, July 07, 2006 11:35
AM
To: epf-dev@xxxxxxxxxxx
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