not all bug reports are created equal.
some come from users that are best described as "innocent". some come from people who think they know what they are doing but don't. and of course, many come from people who do know what they are doing.
because of this the relative value of bug reports varies pretty wildly. often more information is needed from the reporter to bring a report up to par. sifting and sorting is usually a job for the bug triage person, but they are rare (and often odd, see exhibit 'a' for an example of what one might look like).
now, we have a few great triagers in the project (thiago, binner and maksim all spring to mind) but they also tend to be busy with things like writing source code. so what do we do? well, we could try and find some more bug triage type people, but my hopes for that are limited based on historical trends.
moreover, as you can see from the chart below (click for a larger version) we're fighting against a rising tide that's almost as scary as exhibit a (the black line is fixed bugs, all other lines are open bugs in various states):
this continuous creep, even in the face of the impressive black line of fixes, is a problem of success. we have more applications (which means more code) and more capabilities in our libraries (which also means more code) and more users than ever before. more code and more users equals more bug reports. now, we want more applications that cover the set of things people need and we certainly want more users but the resulting inexorable flood of bugs is something we could do with out.
so that's the problem. or, if you're more positive minded, the challenge. how can we answer? i started by saying that not all bug reports are created equal. i think we ought to start taking that into consideration.
if a report comes from a packager who is responsible for building and grooming kde for a distribution, for instance, that report is statistically going to have more weight for me than if it came from a random end user. this is simply because those packagers tend to have more knowledge and time to commit to the problem.
likewise, if a bug report comes from a kde developer, it will statistically have greater meaning to me. if a bug report comes from a well known bug reporter who has done a great job in the past with such reports, it tends to carry more weight for me.
given that most kicker bugs get reported repeatedly, i wouldn't miss that much if i kept my eye primarily on well known bug reporters such as those listed in the previous two paragraphs. i could dip into the "general" pool of bugs whenever i had caught up with those "trusted" reports or when i was looking for something less challenging or just different. note that things were pretty different a few years ago when we had both fewer users and a smaller code base, but today such a system would make me far more productive when combing through bug reports.
so i put it out there for discussion: should we have a stratified bug database system, where some people have a greater level of priority than others so that while everyone should still be able to report bugs, not everyone demands my attention equally? is bugzilla capable of this?
it's also slightly frustrating that there are OS vendors who package and ship kde, even as their default desktop, don't have a means to upstream bugs that are truly kde bugs and not just the result of their customizations. but that (distributed bug databases with push-button up and down streaming) is another story altogether .......