Some thoughts...
On Sat, Apr 4, 2009 at 4:23 AM, Rajko M.
It appear, from many posts on mail lists, as urgent need to organize effort on bug solving, so I propose to create team of people willing to work on that.
Purpose: Helping developers in bug handling. Picking issues on bugzilla, mail lists, forums, and working on them in cooperation with developers.
Advantage: Friendly bug reporting for users. Lesser load on developers for trivial tasks to triage bugs and ask users for often asked information, education of users what is necessary.
Task on hand: Actively ask people that already report bugs to join team.
I'm not sure on acceptance of BugBuster term, so I didn't create wiki page.
I agree with the whole idea, and I think my initial bug reporting would have been better for all concerned if I'd had someway say 'Can you do x then y then z....', or had a gui that collated 'commonly useful data' fro me to submit with the bug report. It does seem that for this exercise to be most effective and least burdensome, missing links are data and some tools to help this workflow: - data: - Bug reporting volunteer's hardware profile, c.f. smolt, but this data would not be anonymous - Bug reporting volunteer's installed packages profile - Bug buster volunteer's hardware profile - Bug buster volunteer's installed packages profile - tools: - Code to match reporter with buster(s) according to profile data. Probably done server side. - A distributed issue tracking application, i.e. a 'git-for-issues'. See ditz (ditz.rubyforge.org) and ditz-commander (code.google.com/p/ditz-commander), others...? - A GUI BugBuster issue submission application (this does all the (esoteric) data collection in the background, e.g lsmod, etc.) Possible workflow: - Similar to Smolt: At install time a user gets asked if they want to help 'bust bugs'? Clear and prominent info is given about lack of privacy and what is involved. E.g. "If you submit an issue a volunteer will see your system info (possibly some of your data?), and you may be invited (by an automated service) to join a public forum discussion of this issue, but the volunteer won't have any of your contact details." - A problem occurs. - The user opens a g|kbugbuster GUI, fills in what they are prompted for. The bugbuster app gathers other useful data (cat /proc/cpuinfo, etc.). - User is shown data to be submitted and asked to confirm. - User data is used match (tough?) to volunteer(s) - the matching code is where the most value could be added to the current process.... - The reporter can see if any volunteer match thier hardware/software profile, given an estimate of avg time to have an issue 'adopted' by a volunteer (so they can decide what the next best move for them; wait, google, etc.) - If a volunteer adopts an issue, they do so via the g|kbugbuster gui. Remeber they are using a distributed issue tracker. If they can replicate it as a bug they can submit to Novell's bugzilla. - If volunteer needs to contact the reporter to clarify/resolve the issue then the bugbuster server sends and invite to both to join a public forum thread (created automagically on a dedicated openSuse forum?) to discuss the issue. Other volunteers might chime in, and there is a public record of lessons learned. Apart from the distributed issue tracker, assuming ditz is suitable, some development of the tools and server side code would need to happen. If this worked it could substantially increase the quality of Novell's bug reports. It'd also give Novell a more efficient and robust de-bugging process, so perhaps they'd see value in getting such a effort kick-started? HTH Mark
-- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org