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

[Nick Bachmann]

Kevin P. Fleming wrote:

> Josh Roberson wrote:
>
>>  Got any suggestions?
>
This has probably been the most useful comment of the thread, because it 
actually has something to discuss rather than vague generalities.

> Well, many projects use their -dev lists to actually propose, comment 
> on and hash out new features, so that they don't get put into the 
> "tracking" system until there's a base of support and usually some 
> code behind it. Asterisk is the only project I've ever participated in 
> with a (nearly) silent -dev list, and all the discussions happening on 
> IRC or non-public channels.

I think a lot of people will agree that -dev is underutilized.  My own 
theory is that people stay away because of too many accidental posts 
here (i.e. -users problems).  I'm not sure what the solution to that is, 
but that's my opinion.

> As a starting point, I suggest changing the policies to say that:
>
> - if you are requesting a feature and not providing code to implement 
> it, post it to -dev first; if there is no response, then you are alone 
> in your request and will have to implement it yourself. If there is a 
> response, keep the thread alive and try to get some input/involvement 
> to get code produced; when that has happened, or is about to happen, 
> THEN (and only then) post a feature request in Mantis with a link to 
> the -dev thread that had the discussion.

I think what we really need, to augment this, are some "feature 
ombudsmen"--developers (or at least people who understand the code and 
what is/isn't feasible) who can be advocates for certain new features 
[and I suppose by proposing them I've just volunteered myself :-)].  
Perhaps a new feature request would require ombudsman approval before 
going in Mantis?  The idea would be that the wheat could be separated 
from the chafe for requests so that interested developers would have a 
more important list of things to do than random requests for "add a new 
feature to app_dial that will be important to at least three people."  
If you have one of those kinds of features, you can develop it yourself, 
of course, or pay someone to do so.

> - if you are requesting a feature _and_ providing the code, post it on 
> -dev first anyway, understanding that it will not be accepted or 
> merged by just being posted on -dev, but that you can get a wider 
> audience for your patch(es) and find out how much support there is for 
> your enhancement. 

Where we really need this is on non-trivial changes, to say: "is there a 
better way to do this?" rather than on more minor feature additions.

> Once you have learned how much support there is, THEN post it in 
> Mantis, again with a link to the -dev thread.
>
> If these policies were in place, then the only features that would be 
> posted directly to Mantis would be those that are providing the code 
> _and_ are not likely to require a discussion amongst the community (in 
> other words, one or two bug marshals and Mark will be able to resolve 
> it because it's simple/obvious/RFC compliant/widely supported/etc.). 

I think you're in the right direction here with where we need to go.  
Hopefully, people in this thread will come up with creative and 
constructive ideas rather than flames*.

Nick
(irc hermie)

*find me on irc and I'll tell you my "arguing online" one-liner.