simple-scan-team team mailing list archive

[Michael Nagel <ubuntu@xxxxxxxxxxxxxxxxx>]

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 a working scanner
- all of the above information in an up-to-date, understandable, searchable database

I will wait for some input from the Bug Squad and then write a draft of
a reply+wiki page.

Missing firmware installation: good point, I will keep that in mind.
Scanner driver in separate thread: that will improve the situation (as in: work around the worst symptoms) for people where the scanner works but crashes randomly. It will not help at all in cases where the scanner is completely unsupported/not detected.

Hug Day: I think that is a good idea. Let's wait until some meta
problems have been sorted out so we can get the most out that day! And
of course this requires some commitment from Robert, because juggling
around the bugs is all good and nice, but in the end it's a bit
pointless if there is no one who knows the code and can make definite
decisions. But if he is in, and some problems are solved, let's do it!

Schedule: wait for possible feedback here -- ask the Bug Squad -- write
draft for a reply in the bug reports and a wiki page.

-- 
You received this bug notification because you are a member of Simple
Scan Development Team, which is the registrant for Simple Scan.
https://bugs.launchpad.net/bugs/896729

Title:
  Problem Management

Status in Simple Scan:
  New

Bug description:
  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?

To manage notifications about this bug go to:
https://bugs.launchpad.net/simple-scan/+bug/896729/+subscriptions