[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [epf-dev] Validating Method Content
|
My only comment on this is that we may
have things committed to CVS even before the Bugzilla entry is marked as
closed. That happens today.
If we tie these two (closing Bugzilla
and committing to CVS are dependent on each other), that means all contribution
should be attached to Bugzilla entry first (as doc or other format), then
go through all the review process (whatever the process we adopt), then
finally committed to CVS.
Does that affect our ability to make
things quickly available to a large audience or even the ability to 'test'
content and navigability directly into the tool or published web site?
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/10/2006 11:05 AM
|
Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx> |
|
|
To
| epf-dev@xxxxxxxxxxx, epf-dev@xxxxxxxxxxx
|
|
cc
| csibbald@xxxxxxxx
|
|
Subject
| RE: [epf-dev] Validating Method Content |
|
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
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
--=_alternative 00634016882571A7_=--_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
