Problem Management
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Simple Scan |
Fix Released
|
High
|
Michael Nagel |
Bug Description
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:/
=======
Lacking any other discussion platform this bug report shall be used to discuss how problems/
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?
Changed in simple-scan: | |
status: | New → In Progress |
importance: | Undecided → High |
assignee: | nobody → Michael Nagel (nailor) |
description: | updated |
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 /lists. ubuntu. com/mailman/ listinfo/ ubuntu- bugsquad /wiki.ubuntu. com/UbuntuBugDa y
[2] https:/
[3] https:/