Many new contributors look through our google issue tracker to find an
open issue, then start working on it. One person recently did this,
sent in a very nice patch, but then it turned out that the issue
(which I had added) was actually invalid.
This is extremely unfortunate, to say the least. It is also
unfortunate that we do not have the resources to review all issues to
make sure that they are valid so that we can avoid this in the future.
Even long-time contributors like me (8 years) can be completely wrong
about issues, so I guess that the only way to be certain that an issue
is valid would be to have a panel of developers review items, so that
if one or two developers were wrong, the majority opinion would
(hopefully) be correct. We have 535 open issues; there's no way we
can review that many.
The "good" news is that issues which contain sample code and incorrect
output are easy to check. If you are familiar with the type of
notation involved, and if the sample code (compiled with the latest
development release) produces bad output, then you can be fairly
certain that the issue should be fixed.
The bad news is that other issues have no easy way to check if they're
actually good or not. This includes most "frog" issues.
I don't really know how to resolve this. There's a certain "chicken
and egg" problem -- there isn't much incentive for main developers to
spend hours discussing issue reports which might not be looked at for
years. But of course, that attitude hardly encourages new
contributors to work on those issues!
My only suggestion so far is that we become more active with the idea
of mentoring new contributors, as discussed here:
http://lilypond.org/doc/v2.13/Documentation/contributor/mentors then, whenever a new contributors is thinking about tackling a
potentially invalid issue, the mentor will step forward, pester
lilypond-devel into seriously reviewing that issue and deciding if
it's actually valid or not.
If you have other suggestions, please make it. I'm not feeling well,
so I may not be thinking clearly about this problem and might have
missed an easy solution.