We will also have the chance to do other customizations, for
instance to
the workflow (as an example, we'll be able to solve this
NEW/ACCEPTED/STARTED problem by having a dedicated ACCEPTED issue
status).
+1 for adding an ACCEPTED status different from a STARTED status.
Phh ... I meant *replacing* STARTED with ACCEPTED :)
It would be well possible (in the sense: BZ supports this) to have
both
STARTED and ACCEPTED. However, this would be a change to our
workflows,
and what I am mainly looking for is where we can adjust BZ to our
current workflows, not where we can adjust our workflows to the
possibilities of BZ. The latter is definitely interesting, too, but
out
of the scope of the IZ->BZ migration.
Having a status of ACCEPTED would match to a workflow where a
developer first acknowledges an issue, that the information provided
is sufficient and that its target milestone and priority are
reasonable. Unless it is a high priority issue it gets rescheduled
until it is gets back on top of the priority queue where it should get
a status of STARTED. So ACCEPTED and STARTED are different steps and
should be treated as such.
While we are at the topic of issue status I would also suggest to
replace WORKSFORME with NOT_REPRODUCIBLE.
This might be discuss-worthy. Why do you think it would be better?
Because a lot of issues have a status WORKSFORME for most users.
Reproducing an issue is then hard work: it may require checking on
different platforms, testing in various locales, setting up a debug
environment, isolating the problem down to be reproducible reliably,
installing additional components, etc.
A status name NOT_REPRODUCIBLE means that none of the testers can
reproduce a problem. A status name WORKSFORME would suggest that the
issue can be marked as resolved if any tester does not experience the
problem directly. We should not encourage that kind of (sloppy)
testing by allowing a WORKSFORME status.
Also split DUPLICATE into
DUPLICATE_ISSUE and DUPLICATE_ROOTCAUSE because very often fixes non-
trivial root causes solve issues that are quite different from the
reported issue.
DUPLICATE is a special state, which is treated specially in BZ in some
places. Adding an arbitrary other, non-special state is easily
possible
(BZ has built-in support for this), having two such special
DUPLICATE-statuses, however, would require some effort to customize
BZ.
While I think I see your point, I don't think that it is worth this
effort.
I see a lot of issues with the status DUPLICATE closed without any
thought or testing put into this. This would be fine if an issue is
reported multiple times. But there are also issues that deserve
additional testing because they are so very different on the surface.
The second kind of issues often have a common root cause.
Maybe this distinction is only interesting to us developers in the
core layers of OOo code, though. Solving root causes of problems there
often solves a lot of scenarios on different platforms in many
locales. Such issues could and should be tested individually.
Abnother aspect that is important to me is one of respect: When issue
reporters carefully research their issues and check for duplicates
before submitting their problems then having an issue resolved as
simple DUPLICATE is disrespectful of their contribution. And with
DUPLICATE issues regularly being closed automatically their valuable
insights and testing abilities get dismissed.
Refactoring code, performance improvements, supporting obsolete and
deprecated but still used stuff, etc. do neither deserve a
classification as DEFECT nor as FEATURE. Such changes should still be
tracked so one can read about their background, about design
considerations, limitations, testing hints etc. ENHANCEMENT is a good
name for such issues with such a status.
So two people raised their voice in favor of keeping ENHANCEMENT and
FEATURE distinct. While I doubt that many people really use those in
that sense, it's all fine with me ...
Good :-)
PATCH, then, could effectively be a TASK with an attachment of type
"Patch".
In my opinion PATCH should never have been an issue type. A patch
is a
change for either fixing a DEFECT, for providing an ENHANCEMENT or
implementing a FEATURE, but in itself the status was just confusing.
The more since you could have FEATUREs or ENHANCEMENTs or DEFECTs
where
somebody attaches a patch.
The only reason for the existence of an issue type PATCH is that it
allows to treat those issues which *start* as patch differently. In
fact
the only treatment (which I know) is the statistics Bernd mentioned.
However, one could argue that the goal of the statistics - to track
how
long a patch lingers without any attention - is not met, anyway,
when we
do not track patch attachments.
I'm still in favor of removing PATCH, but I think there might be too
much resistance from the statistics-fans :-\
With an explicit patch flag which is orthogonal to the issue type even
fans of statistics could be happy.
---
Herbert Duerr
[email protected]
Registered Office: Sun Microsystems GmbH
Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Commercial register of the Local Court of Munich: HRB 161028
Managing Directors: Thomas Schroeder, Wolfgang Engels
Chairman of the Supervisory Board: Martin Haering
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
