4 ms·

Better have fewer high quality bug reports than more low quality reports. The latter just teaches you to ignore them.

by xyzzyz 8y ago

Twirrim 8y ago
That falsely presupposes that only people with poor quality bug reports would be put off from reporting bugs due to the interface. I've known people who can provide high quality, detailed bugs, decide not to because the extra hassles in reporting to Debian just aren't worth it to them.
- geofft 8y ago
  And I've seen people who learn how to report bugs to the Debian bugtracker and then proceed to spend tons of time filing low-quality bugs now that they've acquired that skill, until (maybe) they get banned from the bugtracker. And I've seen Debian package maintainers fail to file bugs correctly....
- tedunangst 8y ago
  No, it assumes that quality ratio varies by reporting mechanism. 9 good reports and 1 bad report are better than 18 good reports and 82 bad reports.
  - geofft 8y ago
    That's subjective - I would much rather spend a few minutes sorting out the 82 bad ones than miss 9 good reports. (Actually, I would much rather have 18 good reports and spend several minutes trying to see if there's anything of value in the 82 bad ones: see for instance the high-school kid who found the Apple FaceTime vulnerability and who couldn't figure out how to report it.) One of the principles of the Debian Social Contract reads: We will not hide problems. We will keep our entire bug report database open for public view at all times. Reports that people file online will promptly become visible to others. Dissuading people from filing bug reports feels like it's not in the spirit of this principle. You're basically hiding problems because you don't think the problem reporter is worthy.
    - user5994461 8y ago
      If only it were possible to sort a hundred reports in a few minutes.
  - pbhjpbhj 8y ago
    Assuming there's no way to triage or filter?
  - pbhjpbhj 8y ago
    I guess if you want to discourage ordinary users then this is the way to go: You might have a massive problem with a default option, but it's not reported because the people savvy enough to handle the bug reporting can fix it themselves. But that might mean most people using your software are getting a bad impression and most ordinary users are put off. Depends on whether you're trying to create an elitist grouping or create something to fill people's needs. It's an interesting, though not unexpected, position that demonstrates technocratic societies can have the same problems of control of power that capitalist societies have; except instead of the elite controlling access to money resources, they control access to technological abilities: "fix it yourself" might be the parallel to saying to a homeless person "get a job". It's an interesting revelation to me of how a meritocratic society can fail to be egalitarian.
  - rleigh 8y ago
    Bad reports can be closed with a message. But you can't do much about good reports which never got filed because the process was unnecessarily complicated. There are tools like reportbug which already help to filter out inappropriate use by asking simple questions and doing basic checks. I'm sure that could be further improved to help triage and improve submissions.
geofft 8y ago
I don't think that's empirically true - plenty of projects that have easy bug-reporting mechanisms (e.g., "open an issue on GitHub") don't ignore their bugs.
shmerl 8y ago
I doubt making filing bug reports uncomfortable is increasing their quality.
420codebro 8y ago
God damn I hate this kind of attitude. Making your stuff hard to use / hard to access is NOT a virtue.
rleigh 8y ago
It's not just about "low quality" bug reports. The entire system is baroque and messy to use even for experts. I've been using it for 2+ decades now. As a maintainer, I frequently needed to change bug tickets. Tags, versions, dependencies, and other details. All need doing through the control@ email interface. Changes can take over half an hour to be processed and acknowledged. It's inefficient and tedious, and prone to error if there's a single typo. While I'm not a fan of web interfaces, bugzilla, JIRA, gitlab issues etc. are all a world more effective and efficient to use. The Debian BTS does what it does well. However, the other systems all do a much better job. The Debian BTS is a couple of decades past its prime. Nowadays we don't need email interfaces to services like this, we have much simpler and more immediate ways to talk to services, which are even easier to script for non-interactive use. Take a typical interaction. I need to respond to a ticket I didn't originally file or get CC'd on. With any other system, I'd log in, find the ticket, make a comment and any metadata changes, and press "submit". With the Debian BTS, I need to find the ticket, download the mbox mailbox by hand and open that in a mail client by hand, then find and reply to the relevant message(s) and make any other needed changes using the control interface. It takes much longer, and it wastes huge quantities of valuable time. It is not a pleasure to use. I can not understate what a huge time sink it is to use the Debian BTS to work with dozens of tickets every day. It's an exercise in frustration.
- shmerl 8y ago
  So why didn't it switch to a better system yet?
- j16sdiz 8y ago
  Why download the mbox? Don't bugnumber@bugs.debian.org work?
  - rleigh 8y ago
    Because you might need to reply to a specific email with all the same people CCd in who wouldn't necessarily be copied in by the bugnumber address. It also includes the appropriate message ID to make threading work. And you can quote the necessary bits to put the reply in context. The fact that you need to jump through these hoops to respond so that people will see your reply is another reason why it's a really painful and inefficient workflow.

Better have fewer high quality bug reports than more low quality reports. The latter just teaches you to ignore them.

by xyzzyz 8y ago

Better have fewer high quality bug reports than more low quality reports. The latter just teaches you to ignore them.

That falsely presupposes that only people with poor quality bug reports would be put off from reporting bugs due to the interface. I've known people who can provide high quality, detailed bugs, decide not to because the extra hassles in reporting to Debian just aren't worth it to them.

geofft 8y ago
And I've seen people who learn how to report bugs to the Debian bugtracker and then proceed to spend tons of time filing low-quality bugs now that they've acquired that skill, until (maybe) they get banned from the bugtracker. And I've seen Debian package maintainers fail to file bugs correctly....
tedunangst 8y ago
No, it assumes that quality ratio varies by reporting mechanism. 9 good reports and 1 bad report are better than 18 good reports and 82 bad reports.
- geofft 8y ago
  That's subjective - I would much rather spend a few minutes sorting out the 82 bad ones than miss 9 good reports. (Actually, I would much rather have 18 good reports and spend several minutes trying to see if there's anything of value in the 82 bad ones: see for instance the high-school kid who found the Apple FaceTime vulnerability and who couldn't figure out how to report it.) One of the principles of the Debian Social Contract reads: We will not hide problems. We will keep our entire bug report database open for public view at all times. Reports that people file online will promptly become visible to others. Dissuading people from filing bug reports feels like it's not in the spirit of this principle. You're basically hiding problems because you don't think the problem reporter is worthy.
  - user5994461 8y ago
    If only it were possible to sort a hundred reports in a few minutes.
- pbhjpbhj 8y ago
  Assuming there's no way to triage or filter?
- pbhjpbhj 8y ago
  I guess if you want to discourage ordinary users then this is the way to go: You might have a massive problem with a default option, but it's not reported because the people savvy enough to handle the bug reporting can fix it themselves. But that might mean most people using your software are getting a bad impression and most ordinary users are put off. Depends on whether you're trying to create an elitist grouping or create something to fill people's needs. It's an interesting, though not unexpected, position that demonstrates technocratic societies can have the same problems of control of power that capitalist societies have; except instead of the elite controlling access to money resources, they control access to technological abilities: "fix it yourself" might be the parallel to saying to a homeless person "get a job". It's an interesting revelation to me of how a meritocratic society can fail to be egalitarian.
- rleigh 8y ago
  Bad reports can be closed with a message. But you can't do much about good reports which never got filed because the process was unnecessarily complicated. There are tools like reportbug which already help to filter out inappropriate use by asking simple questions and doing basic checks. I'm sure that could be further improved to help triage and improve submissions.

geofft 8y ago

I don't think that's empirically true - plenty of projects that have easy bug-reporting mechanisms (e.g., "open an issue on GitHub") don't ignore their bugs.

shmerl 8y ago

I doubt making filing bug reports uncomfortable is increasing their quality.

420codebro 8y ago

God damn I hate this kind of attitude. Making your stuff hard to use / hard to access is NOT a virtue.

rleigh 8y ago

It's not just about "low quality" bug reports. The entire system is baroque and messy to use even for experts. I've been using it for 2+ decades now. As a maintainer, I frequently needed to change bug tickets. Tags, versions, dependencies, and other details. All need doing through the control@ email interface. Changes can take over half an hour to be processed and acknowledged. It's inefficient and tedious, and prone to error if there's a single typo. While I'm not a fan of web interfaces, bugzilla, JIRA, gitlab issues etc. are all a world more effective and efficient to use. The Debian BTS does what it does well. However, the other systems all do a much better job. The Debian BTS is a couple of decades past its prime. Nowadays we don't need email interfaces to services like this, we have much simpler and more immediate ways to talk to services, which are even easier to script for non-interactive use. Take a typical interaction. I need to respond to a ticket I didn't originally file or get CC'd on. With any other system, I'd log in, find the ticket, make a comment and any metadata changes, and press "submit". With the Debian BTS, I need to find the ticket, download the mbox mailbox by hand and open that in a mail client by hand, then find and reply to the relevant message(s) and make any other needed changes using the control interface. It takes much longer, and it wastes huge quantities of valuable time. It is not a pleasure to use. I can not understate what a huge time sink it is to use the Debian BTS to work with dozens of tickets every day. It's an exercise in frustration.

shmerl 8y ago
So why didn't it switch to a better system yet?
j16sdiz 8y ago
Why download the mbox? Don't bugnumber@bugs.debian.org work?
- rleigh 8y ago
  Because you might need to reply to a specific email with all the same people CCd in who wouldn't necessarily be copied in by the bugnumber address. It also includes the appropriate message ID to make threading work. And you can quote the necessary bits to put the reply in context. The fact that you need to jump through these hoops to respond so that people will see your reply is another reason why it's a really painful and inefficient workflow.