Prioritizing bug fixes & improvements to D

[Walter Bright]

At the conference, I was asked in various ways how bug fixes and 
improvements are prioritized, given that so much needs to be done.

The short answer is, it's ad hoc. The longer answer is I have some vague 
notion of whatever bubbles to the top of a cost/benefit analysis.

The cost is how much work it is to implement plus how disruptive the 
change will be to others. That means that trivial issues with little 
benefit can get fixed quickly. An example of that would be something 
like a spelling error or an obvious one liner fix.

For more complex issues, I have to look at how much benefit will it 
produce. For example, a while back Don Clugston showed me that if 
certain improvements were made to constant folding of string literals 
were done, it would open the door to a whole new *class* of template 
metaprogramming capability. This made it quite a huge benefit, and so it 
bubbled up to the surface.

I also pay a lot more attention to issues people have that are blocking 
work they are currently engaged in, than to issues of "it would be nice 
to do this for other (unspecified) people." In other words, if there's a 
current, real live use for a change, and no reasonable workaround, it's 
a higher benefit for the cost.

Of course, sometimes it's leavened by just whatever catches interest du 
jour <g>.