Jim Henderson wrote:
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.
There is already some sort of screening/triaging happening, but I don't know the process nor the people ionvolved. Can anyone from SUSE or Novell help? My reports are frequently forwarded/rerouted/assigned by someone called Kun Kun Zhang.
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.
We have got to have something like this already - it's not exactly new stuff. Maybe in the support data base? -- Per Jessen, Zürich (8.0°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org