Confirming bug reports: Some of the things we see

[Rob Weir <ro...@apache.org>]

I'll probably turn this into a wiki page once we're in agreement, but
I wanted to get some feedback, especially from the "old timers" on the
project, how to treat the common categories of imperfect defect
reports we receive.

1) Obviously, a well-written defect report that describes how to
reproduce the problem, and where the steps work as described, for
those we simply mark the defect as "confirmed", indicate our test
platform and maybe adjust the severity as appropriate.  We're done.

2) In some cases we need to stare at the bug report a little longer,
but we figure it out eventually.  We do it like #1, but maybe add some
additional explanation in the comment, to make it easier for the
developers to reproduce the problem.  Maybe we attach a test document
if that would save time for them.

3) In some cases we see a bug report where the user misunderstood a
feature.  The user is obviously incorrect and the thing they are
reporting is "working as designed".  In such cases I add a kind note
explaining that this is working correctly, point to documentation if
readily available, and mark the bug report as Resolved/Invalid.  It is
"Invalid" because it is not a bug.

4) In some cases the reporter of the bug gives partial detail, but not
enough to reproduce.  We need more info from them, maybe their
document, maybe more details.  In that case I request more info in the
comment field and set the "needmoreinfo" keyword.  I'll then wait a
couple of weeks -- no rush -- and if the user has not provided the
needed info, then I'll close the bug as Resolved/Irreproducible.  If
more info comes later we can always reopen it.  But we don't want to
keep unconfirmed bugs in the queue forever.

5) In some cases you see a report that is giving a vague report of a
crash, but absolutely no useful detail on what caused it. They are not
reporting on an action that crashes OpenOffice.  They are merely
saying that there are "random" crashes.  I send these users to the
support forums and close the issue as Resolved/Irreproducible.  But
I'm open to persuasion if someone thinks they should be marked as
Resolved/Invalid ???

6) Similar to #5, in some cases it is clear the user is looking for
support.  They are asking "how to" type questions.  Or they are
expressing urgency, "Please help quickly, since my paper is due on
Monday".  Do them a favor and send them to support and then resolve
the issue per #5

7) In some cases the report is not really a bug, but a request for an
enhancement or even a new feature.  I leave these unconfirmed but
change the Issue type field from "Defect" to "Enhancement" or
"Feature".

Any other common cases we should talk about?

-Rob

Re: Confirming bug reports: Some of the things we see

[Andrea Pescetti <pe...@apache.org>]

Rob Weir wrote:
> I'll probably turn this into a wiki page once we're in agreement, but
> I wanted to get some feedback, especially from the "old timers" on the
> project, how to treat the common categories of imperfect defect
> reports we receive.  ...
> Any other common cases we should talk about?

8) Valid bug reports that apply to older versions of OpenOffice but not 
to the current one, for various reasons (including bugs related to 
components that have been replaced in the meantime), We should resolve 
them as INVALID (or WORKSFORME?) and instruct the user to download a 
current version, or that anyway no bugfix releases are planned for the 
3.3.x and earlier series.

9) Bug reports that apply to anything else than this project, be it 
extension packages (including bundled dictionaries) or derivative 
products, or upstream components. It is complex to understand what to do 
here. When possible, I close them INVALID but include a link to the 
relevant issue tracker. When not possible... well, this is an 
interesting issue. Surely they are INVALID, but if someone reports a bug 
in the French dictionary we should ideally have a way to inform the 
maintainer. For the time being, one would need to open the extension 
package, lookup the relevant maintainer and e-mail him in private.

Regards,
   Andrea.