Hello, ________________________________________ > But any interpretation of "priority" in the sense of "importance" seems > useless. We differ quite a lot in our opinions of importance. I suspect > Janek and I would rank issues in near-opposite order of importance. That > means that any importance-type priority estimated by the contributor who > opens the issue, won't really help other contributors decide what to work on > next. > > Probably, however, we would all sort issues into roughly the same types of > problems: > Regressions, crashes, incorrect output, ugly output, things that get in the > way of contributing, ... > > So, all we really need to do is make useful classifications, and admit that > we won't all agree on their relative priorities.
This sounds a bit like "let's drop 'priority' field and use labels only" :) ----- OK but it still doesn't get away from the 'when do we release the next stable release' question if we only have labels? When we don't have regressions only? regressions + crashes? Are some regressions more 'critical' than others (genuine question) ditto crashes? Also let's say I have 20 'ugly output' issues, how do I as a user show my preference for one or more of them so that a dev who has the skill and choice to work on any knows which one will benefit the project from a user's perspective? After all I see issues bumped 'down' because they seem to have been hanging about for 'ever' and no one shows an interest in it. So issues must also be able to be bumped 'up' right? Therefore Labels in this sense that are just descriptive don't help. James _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
