On Wed, Sep 10, 2008 at 5:54 PM, Dave Thompson <[EMAIL PROTECTED]> wrote:
> I'm wondering about the usefulness of our issue life cycle. > > Aside from reopened/unconfirmed issues, the usual workflow as defined in > the cookbook > (http://argouml-stats.tigris.org/documentation/defaulthtml/cookbook/ch09.html) > is: > > New > Started > Resolved > Verified > Closed I've tried a couple of times over the past three years to get some improvements on the other end of the issue life cycle. Perhaps it's a good time to attempt to get this fixed again: http://argouml.tigris.org/servlets/SearchList?list=dev&searchText=unconfirmed&defaultField=body&Search=Search (BTW, 3 year turnaround times is why I've completely given up on suggesting any type of process improvements) Basically the goal was to find some way to make sure that all new bugs get triaged in some reasonable amount of time (TBD) so that bug reporters perceived the development team as at least somewhat responsive. The triaging would make sure that the bug had the right priority and was assigned to the correct component. If everything was fine, then it would involve a simple ack to the user to acknowledge that we had accepted their bug report. Part of the problem is that we have a large number of components which are either unowned or owned by "developers" who have disappeared. If the bug reporter chooses one of these components, there's a very real chance that literally YEARS will go by before anyone even looks at their bug report. I recently looked at the Tigris issue reporting for ArgoEclipse because I want to choose a decent bug tracking system before we accumulate too many bug reports. As best I can tell, to get the UNCONFIRMED state to work, you'd need to remove the "Can submit confirmed bug reports" privilege from the Observer role. Also, the infrastructure that they have to make sure that bugs don't get lost (the "Whine" facility) doesn't really match up with the way the ArgoUML issue states work. Whine (optionally) kicks in when a bug has been in the NEW state for more than a certain threshold. This implies that the triage takes place during the NEW->STARTED transition when the bug is accepted, but we typically don't accept a bug until work actually starts on it. Another problem I see with the current system is the use of arbitrary bug priorities to trigger desired behaviors such as stop a release or force Linus to review a patch. I think it would be much better to not overload/abuse the priority in this manner. Also, a regression isn't, in my opinion, automatically a showstopper/blocker. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
