[Asterisk-Dev] Bug Tracker / Feature Requests (my take)

Mark Spencer markster at digium.com
Sat Jan 1 16:43:55 MST 2005


First, let me thank everyone who has been participating in this discussion 
-- and especially I want to thank all the bug marshals who devote so much 
time and energy to trying to manage the very difficult, sometimes tedius 
job, of maintaining the bug tracker.

My intent with this message is to share where I am with my thoughts so 
far.

1) Clearly the bug tracker is only useful as a resource when it serves the
the bug placers, the feature requesters, and is serviceable by the bug 
marshals.

2) The growth of number of people placing bugs is not necessarily in tune 
with those who are servicing the bug tracker.

3) Most bugs and feature requests are properly handled by the existing 
system, but clearly some things have gotten closed out or lost in some 
circumstances.

4) The more open tickets there are in the bug tracker, the more difficult 
it becomes for the bug marshals to see through the maze of "going nowhere" 
issues for those that really are ready for some activity.

5) Feature requests with no attached patches rarely go anywhere, and 
contribute greatly to #4.

6) As difficult as it is to try to keep up with the bug tracker, it is 
clearly more useful than any other system currently in place with Asterisk 
for the tracking of any issues.

7) Patches which fix bugs, features which are implemented and bugs which 
do not have patches all require substantial amounts of time and effort to 
get done.

8) Just because a feature can be done, even if it is supplied with an 
implementation, doesn't mean it should be merged.  Patches must be 
consistent with an overall architecture and also mindful of my strong 
preference for "simple"

9) Maximizing the performance of the bug tracker means to try to solve as 
many bugs and implement as many *logical* features as possible.

10) Bug marshals are a "scarce resource" compaared to those placing bugs.

11) Since the system is dependent upon the volunteer effort of bug 
marshals, the first priority is to cater to the needs of current and/or 
future bug marshals.  While I certainly value the opinion of those who are 
not bug marshals, I clearly have to prioritize the needs of the "doers" to 
those of the "talkers".  Even if we developed the perfect system with 
respect to the bug placer, if there are no bug marshals or too few bug 
marshals to serve it, it cannot operate and serve anybody.

12) Feature requests can sometimes be augmented by having bounties on 
them.  Having a centralized place for feature requests with bounties might 
help get them more visibility and get them translated into features with 
patches.

13)  Some feature requeests, even without patches, are fairly easy to 
implement and can be done fairly quickly.

So, generally I guess, my overall feeling is that the bug tracker should 
primarily be focused around things which are active -- primarily bugs and 
feature requests with patches.  It also seems like a good starting place 
for features even without patches in case they're very easy....

At some point though, there needs to be a way to both get them out of the 
way of myself and the other bug marshals when trying to work on higher 
priority bugs and features with patches and retain high S/N.  Likewise 
feature requests with bounties should be centralized so that people 
looking to add to asterisk but get a bounty in return can find them 
easily.

Clearly none of this is a specific recommendation or policy, but soon 
after I get back to the states, I'd like to try to come up with something 
that *is* concrete, so please continue your discussion and I hope I've 
added something.

Mark



More information about the asterisk-dev mailing list