A Suggestion Regarding Bugzilla
Rob Cozens
rcozens at pon.net
Mon Feb 27 12:20:26 EST 2006
Morning All,
It occurs to me that, to be the kind of conscientious Revolutionist I
descried in Re: On the Democratic Operation of Bugzilla, I must
essentially revisit all items that have my votes, review all
outstanding items in BZ, reallocate my existing votes, and allocate the
majority of my "uncast" votes to outstanding issues.
A. If I attempt to go down that road, the reality is that I will
probably skip items in categories I don't care about. For example:
1. I use SDB for my database needs; so I won't be voting for
SQL-related issues
2. I write my own resizeStack handlers; so the Geometry Manger won't
get my votes.
B. Viewing each bug report and enhancement request as a discrete issue
runs counter to real-world software maintenance procedures. Generally,
bugs and enhancements are not addressed discretely in FIFO or some
other ordinal method, rather they are grouped into logical working
units. In other words, one does not work on one particular issue in
the Geometry Manager, then a revDB issue, then another Geometry Manager
issue; but rather one groups all issues related to a particular
component, evaluates the time required to address each issue in
relation to the severity of the bug or importance of the enhancement,
determines which of the issues will be addressed in the next update,
and then addresses issues component-by-component.
Granted it would be more work for RRLtd, and BZ may not support it; but
might people be encouraged to vote if they were given _groups_ of
related issues as RRLtd would propose to address them to vote on en
masse instead of giving thumbs or down to every single item?
Rob Cozens
CCW, Serendipity Software Company
"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."
from "The Triple Foole" by John Donne (1572-1631)
More information about the use-livecode
mailing list