[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