Hi All, 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 It appears that this is largely based on the stock tigris tooling. Currently, at argouml, we have: New 934 Started 45 Resolved >1000 Verified 55 Closed >1000 The subversion.tigris.org project also use the tigris issue tracker, but they seem far less bothered about verifying/closing issues: New 526 Started 27 Resolved 2129 Verified 2 Closed 218 subclipse.tigris.org even less so: New 70 Started 8 Resolved 710 Verified 1 Closed 4 I understand that the reason for verifying/closing issues has to do with quality assurance, and I don't doubt that having a process where a second person reviews a supposed fix is a good way of ensuring that issues are indeed fixed. However, I do also notice that: - users are probably not concerned in a particular issue once the problem appears to have gone. - users probably judge the quality of the overall product on the number of outstanding bugs rather than the formal closure of historic bugs. - developers are evidentially more interested in fixing problems than verifying them. - some issues are very hard to verify and as a result remain in the database forever. - we are not building a space shuttle. So I am questioning whether verifying issues at all is a valuable process. For a life-critical system, such a workflow would be ideal, as you would need to ensure that problems were really being solved, but is this applicable to ArgoUML? The evidence above suggests that other projects do not want to use the Verify-Close parts of the tigris workflow, yet they are still successful projects (arguably more so than ArgoUML). I also notice that tortoisesvn.tigris.org now use an external issue tracker. In my workplace, we use trac, which by default omits the 'verified' status, and instead reporters tend to re-open issues if they are unsatisfied with the fixes (they do after all get automatically cc'd when the issue is marked as resolved). Perhaps our verification time would be better spent on other things than verifying issues. Maybe we could only make Verify/Close a requirement if the project manager specifically requests it, e.g. for a particularly stubborn bug or an important feature. Maybe we could just automatically close issues that have been resolved for one whole stable release cycle. I strongly feel that the simpler processes are, the more likely they are to be used, and the more useful work gets done. If any flexibility is offered with the new tigris set-up I think we should review the workflow, and if not we should definitively decide what we want the workflow to be. The cookbook and reality differ at the moment. Regards, Dave --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
