Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [epf-dev] Validating Method Content

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

 

Back to the top