From MozillaWiki
Jump to: navigation, search

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

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

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?