> 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
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)