simple-scan-team team mailing list archive

[Robert Ancell <robert.ancell@xxxxxxxxxxxxx>]

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.

-- 
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