Hi Herbert, >> 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. > While we are at the topic of issue status I would also suggest to > replace WORKSFORME with NOT_REPRODUCABLE. This might be discuss-worthy. Why do you think it would be better? > 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. > 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 ... >> 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 :-\ Ciao Frank -- - Frank Schönheit, Software Engineer [email protected] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
