Greetings, I like the attempt to make it a little more visual.
The whole blocker logic doesn't quite fit, I think. Even before you decide if it is a suggestion (enhancement) or a bug (to be fixed), the notion of searching bugzilla for similar problems seems to be missed. And it is usually at that stage where you know if it is a blocker or not. If, for example, you can't even finish a fresh install, because the web installer loops, that's kind of critical, if not a blocker. The difference being whether there is an easy hack around. If a functionality that was working in the previous version stops working in this one, that's critical if not a blocker too. At bug reporting time, you usually know. Though, in some sense, there have been cases where a bugs severity has been elevated either by others testing, the QA folks, or the Release Maintainer/Manager. But a failure does not constitute a reason to increase the severity. https://wiki.koha-community.org/wiki/Development_workflow might be useful to confirm this too. Hope this is constructive enough to help improve your diagram. :) GPML, Mark Tompsett _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
