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