Problem Management

[Michael Nagel]

The message for tickets concerning hardware issues for future reference:

==============================================================
Hi there,

thank you for filing this bug and showing your interest in Simple Scan!

This seems to be a Hardware Issue, i.e. Simple Scan does not support your scanner perfectly -- or possibly not at all.

Unfortunately such problems happen more often then they should, and while it might indeed be a problem with Simple Scan, in our experience, most of the time it is not.
This is why we prepared a check-list at [1] that will let you find out whether or not it really is a problem with Simple Scan and what your options are in either case.

Please read that list and tell us how you decided to proceed. I will set this bug to "Incomplete", so a friendly robot will expire this bug in 60 days if you do not respond. However, we would really prefer to hear back from you!

Best Regards
Michael

[1] https://help.ubuntu.com/community/SimpleScanHardwareIssues
==============================================================

Lacking any other discussion platform this bug report shall be used to discuss how problems/incidents/bugs/issues/tickets should be managed for the Simple Scan project.

With the current situation I see two major problems:
1) lack of manpower to fix the problems -- beyond the scope of this discussion, although all & any support is highly appreciated!
2) unclear organisation of bug reports -- *this shall be discussed here*

a) lots of duplicate bugs not merged -- I am working on this. I tend to rather merge bug reports too aggressively than too careful, because right now, Simple Scan suffers more from scattered information that from bugs that "slip through" because of incorrect merging with a (only seemingly) related bug.

b) lots of bugs lacking important information -- I am working on this. I go through bugs and try to improve them, especially by reproducing them and/or getting additional information from the original reporter. If this information cannot be provided, I advocate to close these bugs. "Bad bugs" take away manpower from good bugs, and there is not nearly enough manpower. This does not mean I want to dismiss all feature requests or stop accepting bug reports from users knowing less about the inner workings of Simple Scan. However it does mean that some bugs should be rejected for lack of quality.

c) "my scanner does not work" bug reports -- In my opinion we should not accept such bugs if it is not proven by the bug reporter that the problem is not with SANE and/or his/her scanner driver. We should provide them with some helpful explanation why Simple Scan probably is not to blame, and where they can more realistically get help. Just letting the bug report rot does not help anybody (the reporter does not learn anything, and our list gets clogged); it is better to tell the hard but honest truth -- that we cannot help them, that if it worked in the past, the safest bet is not to upgrade all six month but to use a LTS release, that if they try for the first time that there is a chance they can get it to work with another driver, but the SANE people are a better contact than we are, and that if they really need a working scanner they should buy one from a list of devices that are known to work. That may sound harsh, but we should work on a text that does not sound harsh or bitter, then most of the people are thankful for a honest and timely reply.

d) too similar feature request -- while for (well described, see b)) defects I think there should be one bug report per problem to keep track of the debugging progress/process, I think for (vague) feature requests it is better to have one ticket about "area 51 needs to be improved" and then some ideas like "build a road, plant a tree, and fix the drain" instead of three tickets "build a road in area 51", "plant a tree in area 51", ... because anyone working on area 51 will see the ticket and after he finished his work, the situation will have changed and the other bugs are probably obsolete. Also this will increase signal-to-noise ratio for the remaining bug reports.

e) Simple Scan upstream vs. simple-scan Ubuntu package -- in my opinion we make our lives harder by following a process that is designed for big packages like e.g. LibreOffice, where upstream development and packaging are somewhat different tasks, involve different people, where there are different versions of the software that are actively maintained... by tracking some bugs upstream, some in the package, some in both places, ... we increase the noise, lists become less clear, we get distracted PLUS we need to do the work to correctly track the flow of the fixes back into the packaged versions. I suggest all bugs should be forwarded to the upstream project, because we can be happy if the bugs are fixed there at all. Right now not even this is guaranteed. Only if this works "too good" we should care to incorporate these fixes into the existing packaged releases and keep track of what patch went into what release already. We can keep the bug tracker for the package for everything concerning the packaging and Ubuntu integration and as a first point of contact for users filing bugs (via apport) and the "c)" type of bugs. When forwarding bug reports to the upstream project, I don't think we should files it as "also affects" and then wait until it is fixed there, and then later when the release with the fix hits Ubuntu set it to "Fix Released" but just set the project to simple-scan, stop duplication and save us some work. I am willing to accept another (the "official") workflow here, too, but I think it is counter-productive.

Any comments regarding this nice wall of text?

[Marcel Stimberg (marcelstimberg)]

Hi Michael,

first of all: Thanks for taking the initiative and putting this effort into improving the state of simple-scan!

I think some of these issues could and should be discussed on the Ubuntu Bug Squad[1] mailing list[2] as similar problems exist for other projects. Some short comments from my side:

Regarding b) (bugs without enough information): I'd recommend to simply follow the usual bug triaging workflow[3], i.e. add a comment stating what information is missing and change the status to "incomplete". If no answer is provided within 60 days (I think), the status is automatically set to "Expired".

Regarding c) (bugs about "scanner not working"): I agree this is a huge problem and I think it would make sense to discuss this on the bug squad mailing list and document the result somewhere so that other triagers know about it. BTW: In addition to not being about simple-scan, many of these bugs are not even bugs but just resulting from missing a firmware installation. I think it might be useful to have a generic blurb for copy&pasting mentioning the help/wiki for scanners and convert the bug into a question.

Regarding e) (upstream vs. Ubuntu bugs): I'd strongly advice against marking bugs "invalid" just to lower the noise. This introduces all kinds of problems: Users won't find the bug report, when they search the Ubuntu bug tracker (which is what they do, normally), they don't see the bug if they report it via apport, etc. Last but not least, getting an email with status change something -> invalid is always unpleasant for users and might stop them from reporting further bugs (that said, getting no response for years is not any better...). Again, I think this should definitely be discussed on the bug squad mailing list so that fellow triagers do not revert status changes of each other (like I did with yours on bug #789762 ;) ).

Oh, one more thing: Cleaning up the simple-scan bugs might be a nice task for a Hug day, actually!

[1] https://wiki.ubuntu.com/BugSquad
[2] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
[3] https://wiki.ubuntu.com/UbuntuBugDay

[Robert Ancell (robert-ancell)]

It all sounds great to me. Note that for c there is a difficult but possible technical solution in bug 564357 that may reduce this problem.

[Robert Ancell (robert-ancell)]

Note for e) there is potentially value in having both as this means new bugs reported against Ubuntu can at least see existing bug reports and detect duplicates. I'm not sure if that's still true with recent Apport releases however. I heard at the last UDS the Software Center project said not tracking in both was a huge improvement. I'll support whoever is doing the triaging as to what the best method is.

[Michael Nagel (nailor)]

Wrap-Up:

a) duplicates: the situation is mostly under control. From now on incoming duplicates should be merged directly.
b) incomplete: standard triaging will be applied, and these bugs will expire and disappear from lists eventually
c) --below--
d) similar requests: this really is not so much of a problem
e) upstreaming: ok, I am convinced we should apply standard procedure here. I would try to achieve that all Ubuntu bugs are forwarded so the upstream bugs are a superset of the Ubuntu bugs and searching there will find any particular bug.

c) "my scanner does not work": I will forward this to the Bug Squad.
Some notes from my point of view: Right now I think closing the bug and pointing them to some friendly and helpful page in the wiki is the best thing we can do. There are four stakeholders in such a bug report:
- the original reporter: he does not benefit from the bug report being open. Honestly his problem will probably not be solved, and even if I is solved, then it will not be solved via that bug report. Pointing him to the information in the wiki in a timely manner is that best he can expect to happen.
- simple-scan developers/triagers/supporters: we most certainly cannot fix his problem, and honestly, personally I am not interested in that aspect of Simple Scan support. Getting that bug report out of our way and pointing him into the right direction (the wiki) is the best we can reasonably do. Sad truth.
- other people owning that particular piece of hardware finding that ticket via google: they are better off with the wiki and/or some kind of hardware database that can tell them what they can expect from that scanner and get advice on what scanner they should buy instead. That kind of data can better be presented in a table than in an unstructured accumulation of old&stale bug reports.
- sane/related developers: they don't profit from these bug reports, as these reports are far too vague and need a lot of polish before they could be of any use to the sane/driver developers. Moreover, I do not imagine there are lots of programming imps going through these lists of nonworking scanners fixing as many as they can. On the contrary, I imagine the few people capable of writing these drivers know very well what devices work and don't work, and do not have unlimited time/resources, and in the time they have, they write drivers for hardware they own or for hardware their peers own, but not for some cheap scanner someone in the Ubuntu bug-tracker wrote about. Sorry for exaggerating... but there is some truth in it somewhere.
Thus I do not think forwarding these "scanner is not recognized" bugs towards sane-backends (that should be the next source package on the long way simple-scan -> sheet of paper in the scanner) is worthwhile. In my opinion it is monkey business similar to what some European countries are doing with atomic waste right now.

So nobody benefits from these bug reports being kept open. Everyone would benefit from:
- fast answers
- information on what to do when a scanner stopped working (regression)
- information if one can expect a given scanner to work (and how to get it working)
- information on what scanner to buy to get...

[Michael Nagel (nailor)]

https://lists.ubuntu.com/archives/ubuntu-bugsquad/2011-November/003552.html

[Michael Nagel (nailor)]

I brought this up in the Ubuntu Bugs meeting on IRC:
http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-11-30-18.00.log.txt

Results from my point of view:
- a wiki page should be created (see next comment for a draft) where reporters of type-c bugs can be linked
- probably a page like https://wiki.ubuntu.com/DebuggingPrintingProblems should be created
- apport package hooks might be utilized to discourage the creation of c-type bugs and to influence what information is included in the bugs created
- micahg is of the opinion that unresolved bug reports should never be closed in order to clean up. mere configuration support requests should be transformed to questions.

[Michael Nagel (nailor)]

Title: Simple Scan Hardware Issues

Hi there,

why did you come here? Let us guess: you wanted to scan something and „it just does not work“. You filed a Bug Report in Launchpad and someone helpful sent you over here...

You want to get your scanner to work, or to get all features (such as an automatic document feeder) to work. We want to improve Simple Scan and make it an even greater application. Let me explain why your original Bug Report does not help either of us and what you can do to get your scanner to work:

Why does your original Bug Report not help us?
To understand why, you need to know something about Simple Scan: Simple Scan is a simple program -- that is what it makes so great -- that does not do the hard work itself. No, all the hard work is done by libsane, which is sometimes called sane-backends.
Quote of the day: “If I have seen further it is by standing on the shoulders of giants.” (Famously used by Isaac Newton).
Whenever you use Simple Scan and instruct it to look for scanners, Simple Scan in turn instructs libsane to look for Scanners. Whenever you use Simple Scan and instruct it to scan a page, Simple Scan in turn instructs libsane to scan the page. So if something fails, there are two possible reasons:
a) the instructions sent by Simple Scan sent are incorrect
or
b) the instructions are correct but libsane just messes up.
From experience we know that b) is way more likely than a). Note: when we blame libsane we have to add that they are doing awesome work over there and they could (rightfully) blame the manufacturers for making their work excruciatingly difficult.

So, bottom line: this probably is not a problem with Simple Scan itself and Simple Scan and its developers cannot make your scanner work.
 HOWEVER -- we are nice people and really want to help you and support the developers of libsane. So read on...

Another famous saying: “Trust, but verify.” (Famously used by Ronald Reagan)
You should verify that what we told above is indeed correct. Luckily this is easy because the awesome developers of libsane also created xsane. xsane is an (a little bit) ugly and overloaded scanning program -- that is why we created Simple Scan -- but it is mighty powerful. And moreover, just as Simple Scan it uses libsane to do the hard work.
There are again two possible outcomes:
a) if everything works with xsane, the problem is within Simple Scan and we will look into it
or
b) if things are broken with xsane, the problem most certainly is in libsane
In either case: read on to find out what you can do!

What can you do to get your scanner working?
While we do not believe that Bug Reports saying no more than “ScanComp Scantist does not work” will lead to any improvement of the situation, we do believe this information is highly valuable. The information that a scanner does work -- and with what settings -- is even more useful. That is why there are “databases” collecting this information. They are located at https://wiki.ubuntu.com/HardwareSupportComponentsScanners and http://www.sane-project.org/sane-backends.html and store that information in a structured manner that is much more useful than a Launchpad Bug Report.

So, first of ...

[Michael Nagel (nailor)]

Hi Robert, I would put the above text into the Ubuntu wiki and set all relevant bugs for the Simple Scan project and the simple-scan package to Incomplete and link them to that text. Most of them will then probably expire, and some will be pushed to sane-backends. Do you approve?

[Michael Nagel (nailor)]

More on apport hooks by Brian Murray: https://lists.ubuntu.com/archives/ubuntu-bugsquad/2011-December/003557.html

I'd suggest we look into those hooks later, but create that wiki page soonish, as soon as Robert gives his go :)

[Robert Ancell (robert-ancell)]

I approve. Nice work!

[Michael Nagel (nailor)]

Wikified version of the message:
https://help.ubuntu.com/community/SimpleScanHardwareIssues

I updated the message displayed when filing a new bug.

I will (when I find the time) go through existing bug reports, set them to Incomplete and link them to that page.

[Michael Nagel (nailor)]

mostly done