Simple Scan triaging

[David Tombs]

On 11/29/2011 06:15 PM, Michael Nagel wrote:
> Hi there,
> 
> I am writing to this list because I would like to hear your opinion regarding the following problem:
> 
> I am triaging the bugs filed against the simple-scan package and the Simple Scan project itself. There are a lot of bug reports like [1] (randomly picked that one) where the hardware is not supported properly. Either it is not supported at all, or some features (ADF, ...) are missing. These bug reports do not bring forward the development of Simple Scan, but on the contrary clog the bug lists and slow down development progress. Keeping them is thus not worthwile in my opinion. (Note: In general I think not all bug reports should be accepted/kept. I prefer a deliberate decision with explicit downsides/compromises to the implicit decision to do nothing and avoid all downsides -- you do not get upsides that way, either.)
> 
> Different stakeholders are involved in these bug, namely the original reporter, the Simple Scan developers, the developers of SANE / other involved software, and other users owning the same hardware. Keeping these reports open helps none of them and harms some of them. The following approach would be much better for everyone in my opinion:
> 
> 1) closing such bugs in a timely manner
> 2) pointing to a wiki where general tips about scanners can be much better maintained. might be an adapted version of [2]
> 3) structured information about what hardware works with what settings should be kept in a database (in the weak meaning of the word, might e.g. be another wiki page). might just be [3]
> 
> - The original reporter benefits from 1) because he no longer is ignored for some years. The reporter hopefully benefits from 2+3) as there is the chance (s)he gets the scanner to work.
> - The Simple Scan developers benefit from happy users and from more helpful bug lists, letting them concentrate on the real issues in Simple Scan.
> - SANE / other developers benefit from 3) because they get much more concise and structured information. See the following section about forwarding bugs.
> - Other hardware owners profit from the database as well, because they can easily find out what hardware can be recommended to buy (use case 1) and what can be expected from a given piece of hardware (use case 2a) and how to get the most out of a given piece of hardware (use case 2b).
> 
> About forwarding such bug reports to e.g. sane-backends: I think it is monkey business, like some European countries moving around atomic waste that nobody wants but that does not vanish. It would just create the same situation we have with simple-scan now for sane-backends in some time. Someone has to accept responsibility, make the though decision (see above) and "solve" the issue.
> 
> Additionally, these bugs are often reported by new users, very vague and to not include enough technical detail. I am sure there has been some discussion how to handle that kind of bug reports, as Ubuntu continues to attract more and more non-technical users that cannot and/or do not want to contribute low-level.
> A pointer to such discussion would be very welcome!
>>From my experience those users are mostly thankful for some timely, helpful and honest reply, even if it boils down to "yes, we know, but sadly it will not be fixed soon -- if you need a solution right now and you cannot code: I am sorry to tell you, but your only option is to buy one of the better supported scanners. More info: see wiki: ..."
> Once again: if the bug report is just another data point saying "does not work" it is better off in the device database.
> 
> 
> 
> Then, even trickier, are the crashes of Simple Scan (or more likely: SANE/something down the chain) that depend on the use of certain hardware (with bad drivers). To be honest, nobody will look into these issues because of a bug report. Either someone knowledgeable will look into such an issue because he is personally affected or because someone (s)he knows is affected.
> But the mere statement that Simple Scan crashed (typically via an apport report) will once again lead to rotting/stale bug reports, where developers benefit from just deleting it and non-technical users benefit most from a timely pointer to the wiki and the database where they can get a tip how to maybe get it working. One prominent tip should read: "If you need a solution right now and you cannot code: I am sorry to tell you, but your only option is to buy one of the better supported scanners. More info: see wiki: ..."
> 
> 
> 
> What do you think about the suggested approach? Do you have experience with similar cases?
> 
> Best Regards
> Michael
> 
> PS: over all that closing of bug reports we should not forget that:
> - of course there are some high quality bugs related to scanner hardware, that can help improving the situation. I do not want to blindly close all bugs.
> - the general situation regarding hardware support for scanners is somewhat sad :(
> 
> Context: Simple Scan internal discussion of this topic: https://bugs.launchpad.net/simple-scan/+bug/896729 (case "c)" is what this mail is about)
> [1] https://bugs.launchpad.net/ubuntu/+source/simple-scan/+bug/674817 
> [2] https://help.ubuntu.com/community/ScanningHowTo
> [3] https://wiki.ubuntu.com/HardwareSupportComponentsScanners
> 

Hi Michael,

I am not an expert triager, but I do agree with a lot of your points.
Good thinking.

For a small improvement, adding an "unsupported hardware" message to the
canned responses[1] (and Firefox extension) would certainly save some
time. Ideally, however, this canned response would be accompanied by a
standard triaging practice for unsupported hardware bugs but I am not
sure if that exists.

Thanks for the email,
David