Re: [epf-dev] Bugzilla use

[Per Kroll <pkroll@xxxxxxxxxx>]

Ricardo,

this makes sense to me. I think we want
to avoid duplicating information in a spreadsheet, last time was not a
success, and not because of lack of trying... :)
We should check with other teams if
there are solutions to the burndown, sizing and estimating problem used
by other teams.

Also, do we need to worry about having
releases / iteration that are potentially different from the tool component?
They are on 1.0, we are on 0.9. The Component field can be used to filter
out, but I wonder if we need to put an "O" into the TargetM field,
so we have "O1.0", "O1.0.1", "O1.0.2", etc.

Also, we should update the Components
to call out each indivudal process component. So, rather than havgin Content
as a component, we should consider having OpenUP as one component, and
XP as another component. If we have DSDM or XP content written as extensions
to OpenUP, I suggest that the component that work belong to is OpenUP,
so the base will determine the component work is assigned to, not the origin
of the source IP.

Makes sense?

Cheers

Per Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp
(M) 408-219-2963

Ricardo Balduino/Cupertino/IBM@IBMUS
Sent by: epf-dev-bounces@xxxxxxxxxxx

10/17/2006 07:33 PM

Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>

To	epf-dev@xxxxxxxxxxx
cc
Subject	[epf-dev] Bugzilla use

Hi OpenUP committers, 

I was revisiting Bugzilla to do bug triage after our 0.9 release. After
a bit of investigation through the Bugzilla help and checking with the
Composer team, I found we were misusing the Version field in Bugzilla.
This field if for the version where you found the bug, not the version
where you plan to deliver the fix. Sadly, we're not going to revisit the
200+ bugs we already dealt with for Release 0.9 :-)

Now, I'd like to throw out some ideas for a more consistent use of Bugzilla,
thus leading us to better assignment of tasks and status reporting.

For the current 76 bugs in there (status varying from NEW to VERIFIED)
and new to come, the Version field should be set to 0.9, and the Target
Milestone could be set (initially) to 1.0 (which is the next planned OpenUP/Basic
release. 
We would interpret this as being our Work Items List: you file a bug (or
enhancement) against the current version, it goes to the list, and it is
prioritized/assigned to the current release (being worked) or future releases.

Then, as we move through the iterations, this Target Milestone field would
show what iteration, in that particular release, the element is planned
for. 
For example, a bug is assigned to : 
        - Target Milestone 1.0.1, 1.0.2, etc. (meaning
release 1.0, iteration 1, 2, etc.) OR 
        - Target Milestone 1.0 - I1, 1.0 - I2, etc
(I kind of like the first notation better) 

This information would help us to generate a report showing the Iteration
Plan. Unfortunately, I don't see any easy way to extract burndown information
in graphic format as we used to have in excel sheets, but the source of
information is (officially) one, so no maintenance overhead. To be fair,
there may be some ways to show what has been fixed, resolved, closed in
a given period of time, like the report we have available in the OpenUP
downloads area of EPF web site. 

Please, let me know if you have ideas or comments. If you like it, I volunteer
to change these fields in Bugzilla in the next few days. New additions
should then follow this proposition. 
Does it sound like a plan? 

Cheers, 

Ricardo Balduino
Senior Software Engineer

IBM - RUP Team | EPF Committer
www.ibm.com/rational
www.eclipse.org/epf_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev