OK, so this is something I'd like to start trying to get my arms around so we can have a more comprehensive approach to dealing with bug reports and increase the rate of resolution as well as the follow-up rate when additional information is needed. It seems that we have a few areas that we should be looking at: 1. There should be some sort of "screening" that takes place before a bug is accepted - to ensure that the devs aren't seeing multiple copies of the same bugs. I think it's fair to say that those who write code would far rather *write code* than try to sort through duplicate bug entries. While it's likely there still would be dupes with a screening process, the incidence should be reduced. 2. There needs to be more of a "human" reply, especially on older bugs, that are being addressed. Looking at the current Bugzilla stats, I see that (for example) 12.1 has 183 bugs in a "NEEDINFO" state - there needs to be some sort of consistent follow-up to ensure that the info needed to fix the issues is provided, and if it isn't and the information can't be obtained (because the issue cannot be duped, those looking at it don't have the necessary hardware, etc), then the bug needs to be closed. 3. For older bugs, (such as on 10.3-11.3, which there are still open bugs on), a determination needs to be made as to whether the current supported releases have those issues, and if they do, the bugs need to be updated. If they don't, then the bugs need to be flagged in an appropriate way. 4. It would be extremely useful, I think - especially for the non-techie audience - to put some specific training together on things like (a) how to submit a bug and include the relevant information, (b) what to expect with your bug and how to monitor progress, (c) how to provide additional information when requested (and what to do if you've upgraded/moved to another version/changed distributions/decided to go back to Windows/MacOS/ whatever) so the bug can continue to be evaluated by those evaluating it. Ultimately, the goal of this project is to increase resolution rates, reduce the time to resolution as much as possible, and to visibly improve the bug resolution process so more people don't perceive (correct or not) that reporting bugs is useless because they don't get resolved (and actually, looking at the stats on bug status, I think it's pretty unfair to say bugs aren't getting resolved. I see, for example, that of the reported bugs on 11.1, for example, over 3/4 of the bugs are marked as resolved.) And overall across all releases of openSUSE, and SUSE Linux Professional/ SUSE Linux from 8.2 on, the bugs marked resolved are 13026/18285, which is nearly 3/4. 75% isn't bad (the Pareto rule is 80/20, and on 11.1 we're actually around 78% "resolved"), but I'm sure that if we can guide the process and streamline it, we can increase that. Of course those are just rough statistics and the reason bugs are marked as 'resolved' isn't included in that - and there is a further breakdown that can be done that might help identify trends that would be useful. There's clearly more that we should be looking at, but these four areas are a good place to start. For my own part, I'm willing to do more than talk and discuss the ideas, but it's going to take more than just one person working in his spare time to move this along. I also think something similar to this should be done for FATE, but that's perhaps a topic for another day. :) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org