simple-scan-team team mailing list archive

[Michael Nagel <ubuntu@xxxxxxxxxxxxxxxxx>]

** Description changed:

- 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.
+ 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?

-- 
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:
  Fix Released

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://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?

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