The latest bug report that I created just came up in UNCONFIRMED status. Has this been implemented now? What's the new workflow?
If it's possible, it'd be nice to have bug reports created by developers (as opposed to users) be automatically confirmed to NEW status, but I can live with the extra work if it makes it easier to track bugs which haven't been triaged/acknowledged. Tom On Sun, Sep 21, 2008 at 9:53 AM, Tom Morris <[EMAIL PROTECTED]> wrote: > On Sun, Sep 21, 2008 at 5:51 AM, Linus Tolke <[EMAIL PROTECTED]> wrote: > >> Are you saying that you have gotten the change in issuezilla to work as you >> want in the ArgoEclipse project? > > If you're asking about getting bugs created in the UNCONFIRMED state, > no, I haven't actually implemented this. All the information that I > have on it was included in the email quoted below. The help text said > that it's only for people creating bugs who don't have the right > privileges. I haven't yet gone through to figure out how to remove > the privileges from the default Observer role. If I decide to use a > different bug reporting system, I probably won't invest the effort in > trying to figure out Collabnet's IssueZilla system. > > Tom > >> >> >> 2008/9/20 Tom Morris <[EMAIL PROTECTED]> >>> >>> 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] >>> >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
