This is a problem with any predominantly volunteer coding project: people do what they want to do, based on what they think is important. (Tim and Brion aren't volunteers, but then, they usually still decide what to do by themselves.) Look at the amount of angst happening in something like Mozilla's https://bugzilla.mozilla.org/show_bug.cgi?id=45375, say, with 306 votes. Developers haven't stopped by to do much of anything except deny version-blocking requests.
No, people are not going to tell you when they aren't interested: if they aren't interested, they *won't* tell you anything, which is how you can tell. If they're interested, they'll comment and assign the bug to themselves. It would be rather pointless to have a horde of developers say that they're not interested, on almost every single newly-submitted bug (of which there are what, ten to thirty a day, with something like five or ten active developers?).
Bugzilla has nothing to do with the issue either way. The issue is that there's limited manpower, and it's not necessarily assigned based on what the community wants, as some would like.
On 9/23/06, Tim Starling tstarling@wikimedia.org wrote:
Perhaps it's reasonable to expect us to check all the newly-filed bugs,
Or maybe to occasionally glance over standing bugs with patches attached, and submit if they're not too complicated to quickly and easily test. Or to look at some of the bugs with relatively many votes from time to time and implement any that would be relatively easy. Or something. Looking at new bugs might not be the best solution, since those are as often unimportant as old bugs.
This description can then be referenced in direct requests to developers via IRC, email or the mailing list.
Which only work because of lower load, needless to say. If more and more people start using those methods, they'll start to get tuned out as well. There's merit to saying that developers should assign no weight to personal requests made on IRC or similar media, but rather make their own evaluation of the worthiness of standing issues, looking at them organized by things like vote number and whether patches are provided so as not to have to look at the masses of dubious or niche requests. This focuses effort to fulfill feature requests along more productive lines than giving it to those who happen to go on IRC rather than Bugzilla.
But of course, all that is up to each dev to choose. Because MediaWiki is (almost entirely) a volunteer project.