Bugmasters/Meetings/2013/Mar7

March 7

Stuff that got done!

• Bugzilla 4.2 upgrade and move. Yay, thanks dkl, glob, fox2mike, and sheeri!
• Bugzilla data is/will be available quarterly thanks to mhoye, gerv, dkl
  • Temporary home of data dump: http://people.mozilla.org/~mhoye/bugzilla/

Ongoing activity

• weekly bug days
• bug days focused in specific area, every 2 weeks

• Make templates for focused bug days
  • Screen reader and [accessibility bug day], Tues. March 12
  • inviting people individually, blogging, accessibility devs
  • advice on bug days. asa ran general ones, early days, easy pickings, go from 800 unconfirmed to 300. More targeted sounds good.100-200 bugs, limited scope, is good. ask ashughes.
  • show group how to read bugs. go through examples. through skype or vidyo. (screencast would be good)

• Closing out older bugs - mass close pilot program
  • kevin suggests 1 or 2 weeks before close.
  • filter out anything with patches or testcase, meta,
  • search mozilla.dev.planning or dev.apps.firefox lists for past discussion.
  • ask gerv
  • show list of bugs to component lead (and peers) first before starting process
  • particular commenters who have touched the bugs
  • start with, stay out of toolkit, core. try firefox module leads

• Putting links to documentation into Bugzilla component descriptions.

Stuff that needs doing

List yourself after an item if you would like to do a bit of work on it!

• Start tagging unconfirmed bugs with some bugmaster tags
• Identify bugs likely to be easier to triage.
  • confirm-wanted -- this one I'd like to feed into bugs ahoy
  • steps-wanted -- also possibly good!
  • testcase-wanted, regressionwindow-wanted
  • kbrosnan and bsmedberg ask, Is this useful?
  • And, When is it useful to ask for safe mode/new profile? Some triagers ask for it with a needinfo from the bug reporter when it's not the best first response for that particular bug.
  • Meeting participants feel that triagers carefully reading and understanding the bug is important (and maybe not always achieved...)

• Develop triage guidelines for specific actions and modules.
  • Good example - B2G/QA/Triage page's keyword listing.
  • Work with a particular module owner and peers to find out what they need

• Describe various common bugmastering tasks, with good examples.
  • Add them here: https://wiki.mozilla.org/Bugmasters/Guide/Responses

Projects for the future

• VM image of bugzilla.mozilla.org with sanitized db
  • for community developers to contribute extensions
  • for researchers
• Canned comments extension
• Conversion points chart - refine it. https://wiki.mozilla.org/Contribute/Conversion_points#Other_project_areas (Will work on this in Toronto with Marcia/ashughes)
• Code-triage extension; sign up for periodic triaging invite email with a random bug from an area you choose (as with GitHub projects and CodeTriage.com)
  • kbrosnan suggests a web app that gives you 5 bugs, smaller chunks to work with. Take bugs ahoy and fork it?
• What tools would help the people already doing lots of triage?

Thoughts & discussion

What else would you add to this discussion?