[Asterisk-Dev] Features requests on bugs.digium.com

[Josh Roberson]

Darren Nickerson wrote:

> I think my point is that _nobody_ will ever manage feature requests in 
> any concerted way, and that this is OK. There needs to be a way for 
> someone to 'freshen' an issue if they hang working code on it though, 
> ... because it can become commit-worthy at that point. In the 

Which we currently try to do with our housekeeping reminders..  But 
after so long, without a response or update,  it will go stale, and in 
all honesty, we don't have the time to bring them current ourselves.

> HylaFAX project, we will often see feature requests being discussed on 
> the -devel list when they're that 'imminent', but I can see that 
> Asterisk will necessarily have many many more (possibly orders of 
> magnitude more) feature requests since it's evolving so rapidly, and 
> that approach won't scale. Like Kevin who posted a moment ago, I've 
> never encountered a developer community that does most of its work in 
> non-public channels that generate no historical record (IAX 
> conferences or IRC), or that berates people for contributing in the 
> "wrong" way, so I'm not entirely sure how feature requestors will get 
> the attention of the appropriate people without getting beaten up. I 
> think categorizing them in Mantis as feature requests is still the way 
> to go though, all one needs to sort out is the "path to commitment", 
> so that this is not a graveyard.

Valid point.

>> I completely agree with this.  I wouldn't see a repository for 
>> feature requests/enhancements as a graveyard - meerly another 
>> locaiton for advancement, and our current system as a place where you 
>> bring your bugs, and resolutions to bugs.   Perhaps we SHOULD look 
>> into a better method of bugtracking, perhaps, a new system (not 
>> mantis).  Got any suggestions?
>
>
> I'm afraid my experience is limited to bugzilla. Mantis seems much 
> more fully featured, and you seem to be making good use of its 
> capabilities already. Like I said, it seems to me that the category of 
> feature request, which is presently being used, makes this a non-issue 
> as long as it's deemed OK for them to stay there and there's _some_ 
> path for them to be committed when working code is there (and Mark 
> deems it commit-worthy).

The only issue with this is, we have no way to filter out the feature 
requests, if we're actually trying to deal with the bugs themselves, 
other than going from project to project.

>
> I understand your desire to separate them, but I think Mantis already 
> does that sufficiently well (as long as things are triaged correctly 
> when they come in).

Right.  Which is also becoming a problem, which is why we're so 
persistant on trying to gain assistance.   I think we just need to 
revise the whole system, and in doing so, address all of the issues that 
we're seeing with the current system.