I’ve been reading things people report in Bugzilla for years. How I feel about this now is that there are really several, entirely different things that we presently lump under “bug”. For example, I think it’s pretty clear that someone’s random ideas for a change to the design are totally different from say identified code regressions, which are in turn different from proposed patches.
Given that I am only one human and can’t respond to every bug, much less actually fix them, I’ve had to invent a prioritization mechanism. Note this is in my upstream GNOME role – I do work on Red Hat Enterprise Linux too, and there my priorities are obviously influenced by customers, management etc.
My goal in upstream is simply to make good Free Software. Thus, prioritization I’ve settled on looks something like this:
- Is the bug reporter an important Free Software contributor to anywhere in the stack? Then the bug is important. If they’re also an engineer or knowledgable tester, then things are ideal because I can expect them to try things out and help me debug.
- Is the bug a valid regression with enough data to debug it? For example, “I upgraded from GNOME 3.0 to 3.2, and application foo crashes with this stack trace…”. Then it’s important. Ideally it’s bisected – something I’d like to make easier for both developers and testers.
- Is the bug something embarrassing? For example, badly leaking memory. Then it’s important.
Obviously, a bug could be all three of these things – e.g. a Mozilla hacker could report a regression in GNOME that causes us to leak memory. Then it’d demand a reply =) Things beyond this though get fuzzy. One thing that’s important to keep in mind is that GNOME does not have a business model that scales directly per user. Someone new using GNOME doesn’t necessarily mean there are more people working on it able to respond to, diagnose, and fix bugs. This is why as upstream, I focus so much on the things above – Free Software contributors (in some form) and unintentional regressions.
Why regressions? Well, I obviously have no obligation to someone who just happens to use and deploy my software for free – it’s not like we can e.g. work perfectly on all hardware in all situations. But it important for anyone contributing a change to the FOSS pool to make sure that while their change may take a step forward, it’s not taking two steps backward somewhere else.
I apply that rule strongly even to myself – while I don’t personally care about OpenBSD, I took the time to diagnose a regression I introduced, following the principles above. Hopefully others feel the same!
Colin Walters 
I completely understand why you prioritize the way you do. Nonetheless, because we might be missing useful data if it comes in the form of ignored bad bug reports, I figure this also highlights the usefulness of bug triagers who turn bad bug reports into useful ones that include valid steps to repro, etc. Not your role, since you don’t have time, but someone’s…
That’s a good point – the bug reporter has donated their time to my project by the act of reporting.
The problem though is that there can be easily orders of magnitude or more difference in time to report a problem, and to debug and fix it. Reporting a crasher bug may only take 5 minutes. Relatively easy ones might average say an hour – but that varies significantly. Tracking down a hard one can be days.
Ideally GNOME bugzilla would communicate this kind of thing clearly. Mozilla is a bit ahead of us here – their bugzilla does explicitly split out “I have an issue” and “I have an idea”:
https://bugzilla.mozilla.org/enter_bug.cgi
Aha, now I see why you always respond to my bug reports so promptly!
Now you’ve also made me feel guilty about the times when my responses to your comments on bug reports were slow. 😀
that’s perfectly your right and you have your perfectly good reasons too, but like this you evaluate more the man than the ideas and you consolidate more and more the leadership against the community.
this tendency is more and more evident in open source.
I bet if idea will come with a patch, it will have chances to get into upstream fast.
Usually ideas in any bugzillas starts with “Feature YY of app X is a bloody mess and terrible sux to live with so here is my brilliant idea…”
There are bad ideas with code and good ideas without code. Personally I can’t code, but I can think.
Your image of the average gnome-lover, caricatural but not that wrong, highlights one thing: the person (stile, kindness, attutude) matters to devs. It’s true indeed that many of bug/wish reporters are very rude and presumptuous, and this is absolutely a bad thing, but I can assure that devs can be rude as well, or, say, have the power to say “No. Closed.” without giving any account on something. So, we’re not talking about judgeing quality of ideas.
A good overall practice is to not give the chance for frustration, through keeping open the dialogue, not being too conservative, not takeing much controversial decisions despite the contrariety of a wide range of your userbase.
As Linus said “The other thing—and it’s kind of related—that people seem to get wrong is to think that the code they write is what matters, No, even if you wrote 100% of the code, and even if you are the best programmer in the world and will never need any help with the project at all, the thing that really matters is the users of the code. The code itself is unimportant; the project is only as useful as people actually find it.”
This post is public so it has implications, so let me just say: Do not throw the baby with the bathwater.
Gnome Lover.
Only somewhat related, but: do you have any hints how to improve chances that a new feature (including patch) is applied in Gnome? I’m not an important Free Software contributor, the feature request doesn’t fix anything “embarrassing”, and it’s not a regression… Yet it would be nice to get this feature in.
In many cases it looks like upstream maintainers are overworked with the amount of bugs (or are tired of working on the particular package), so even complete patches might linger in Bugzilla waiting for a first reply. I’m wondering if you have any hints how to improve chances of getting a reply or review at all.