That need to close bugs?

[Aaron Whitehouse]

> What is the rationale behind skipping closed bugs in a search? I've
> been burned by this in the past.
>
> I can understand why the QA guys or the even developers would want
> this but for a user, who is actually making the effort to not only
> report a bug but to search for dups first, why would they want to
> ignore closed bugs? Closed bugs often contain exactly what that user
> needs - a workaround or a timeline for the fix to be released,

As has already been pointed out, if a user is filing a bug then this
isn't a problem. If you try and file a new bug with summary "broken",
the list suggests bugs that are Fix Released, Invalid etc. If there
are closed, duplicate bugs, they should be suggested by Launchpad when
the user tries to file it.

I file quite a lot of bugs. Now and again I will file a bug and forget
to include something. Most people mark it as Needs Info/incomplete and
explain what is missing. Some give excellent guidance in typing in the
correct commands etc.

It drives me batty when somebody closes the bug. It also drives me
batty when people misunderstand my problem and duplicate it against
something that isn't related. Without people doing these things,
however, the rest of my bugs would not get fixed as quickly.

We are lucky enough to have a wide range of skills in Ubuntu
volunteers. A few have the ability to fix the bugs that come up in the
products. More have the ability to help people refine their bugs. When
a dev gets home from work and sits in front of their computer for a
couple of hours helping Ubuntu, the bugs need to be ready with
everything that they need.

Lets take an extreme example. Say my mother has an obscure set-up and
her machine doesn't boot at all with Ubuntu. She files a bug saying
"Ubuntu doesn't work". Now, in an ideal world, a triager will help her
through turning that into a detailed report with logs, step-by-step
reproduction instructions etc. But say that the world isn't ideal. Mum
decides Ubuntu is silly and goes back to Microsoft, never looking at
Ubuntu or Launchpad again. Do we really gain anything by having a dev
look at "Ubuntu doesn't work" every day for the rest of all time? How
about 50,000 "Ubuntu doesn't work"s?

There has been excellent progress in projects like
AutomatedCrashReporting. Things like that make it easier for people to
give useful information when they aren't computer literate.

We have too many bugs and not enough people able to fix them. Those
people should be focusing on well-documented, prioritised bugs. If we
ever have more developers than bugs, we can afford to have the
developers chasing people and having incomplete bugs open.

I suppose:
1) When I (as a fairly competent user) file a bug, I need to make sure
that I give all the information that I can;
2) When people are triaging, they should probably try to get the
information that is needed from the reporter before they close the
bug;
3) We could free up the people doing these mundane tasks:
[RFE] Malone should email, then close bugs for inactivity
https://bugs.launchpad.net/malone/+bug/141199
and
[RFE] Email inactive bugs a month after a release
https://bugs.launchpad.net/malone/+bug/141202
and then the people that were doing those tasks could instead help
people complete their reports; and
4) If your bug is a duplicate of a bug that isn't complete, complete it!

A great start would be:
Allow product-/package-specific bug-reporting guidelines
https://bugs.launchpad.net/malone/+bug/43893
as it should dramatically improve report quality. I've been using
Ubuntu since Hoary, but I still don't know when developers will want
the output of lspci etc.

My underlying point is that we all want Ubuntu to be bug-free. It
isn't and it isn't likely to be any time soon. While it isn't, we need
to focus our resources on things that are ready to be fixed. There is
nothing to stop having people trying to complete INCOMPLETE bugs by
asking questions, but confirmed, complete reports need to be the
priority.

A big thanks to all the people keeping the bug system going.

Aaron