Bugmasters/Projects: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 1: Line 1:
Here are some ongoing Bugmaster projects to help manage Mozilla bugs.  Each one will have bug days or events, to help its contributors work together.  "Triaging" a bug can mean a lot of different things depending on context. In general, it means adding more information to a filed bug.
Here are some ongoing Bugmaster projects to help manage Mozilla bugs.  Each one will have bug days or events, to help its contributors work together.  "Triaging" a bug can mean a lot of different things depending on context. In general, it means adding more information to a filed bug.


==Mentored Bugs Team==
Many developers tag bugs as good first bugs, or as mentored bugs. Some are tagged with both.
'''We are having a triage day in May 2013 to rummage through the mentored bugs!'''
* Sign up here: https://etherpad.mozilla.org/triage-mentored-bugs<br>
Currently, mentored bugs feed the [http://www.joshmatthews.net/bugsahoy/ Bugs Ahoy] site.
Good first bugs feed into [https://openhatch.org/search/?q=Mozilla openhatch.org]. (Out of date. Wrote to Asheesh, who is looking into it.)
Help maintain this list for contributors who are new to Mozilla development!
* Is the bug old and stale?
** Should it be closed?
** needinfo on the reporter, or mentor, or assignee?
* Is the bug current, and assigned, but the assignee hasn't touched it for a couple of weeks?
** needinfo the assignee to ask nicely if they're still working on it or intending to
** If the reporter hasn't touched the bug in a month, unassign it
* Triage through bugs that have the whiteboard flag [good first bug] but NOT the mentor= flag.
** [https://bugzilla.mozilla.org/buglist.cgi?f1=status_whiteboard&list_id=6500843&o1=casesubstring&resolution=---&resolution=DUPLICATE&status_whiteboard_type=allwordssubstr&query_format=advanced&status_whiteboard=good%20first%20bug&v1=mentor good first bugs query] (no mentor)
* Triaging strategies:
** Sort the list by component.
*** Pick a particular product and component. Talk with the bugzilla owner of that component or the module owner.
** Sort the list by ID. It's good to check up on very old bugs with a low ID number.
** Sort the list by last changed. For bugs that haven't been touched in weeks or months, look if they're assigned and ask the assignee, by commenting with the needinfo flag, if they're still working on it.
* Triage through the bugs that have "mentor=" as a whiteboard flag.
* Triage through bugs that have "good first bug" AND "mentor" in the whiteboard flags.
** should they have both?
TODO:
* write up how to check on good first bugs
* write up how to choose and tag good first bugs/mentored bugs, and link


==Accessibility Triage Team==
==Accessibility Triage Team==

Revision as of 19:00, 15 August 2013

Here are some ongoing Bugmaster projects to help manage Mozilla bugs. Each one will have bug days or events, to help its contributors work together. "Triaging" a bug can mean a lot of different things depending on context. In general, it means adding more information to a filed bug.


Accessibility Triage Team

This is for bug wranglers who would like to help accessibility developers and end users.

  • Join #bugmasters and #accessibility
  • Meta bug cleanup: this is a very easy task for beginners!
    • Look at accessibility meta bugs
    • Pick one, search for other bugs that are missing, and add them to the meta bug

Core:Layout Triage Team

This is a good triage task for front-end developers. Help us go through UNCONFIRMED Core:Layout bugs, talk with the bug reporters, replicate the bugs, and attached reduced test cases.

The hardest part about layout bug triage is being able to tell apart "is a valid bug" and "is not a valid bug". This typically involves understanding the spec well enough to understand what behavior it requires. It also typically involves reducing the testcase enough that it's possible to try to figure out what parts of the spec are relevant. The really rare skill here is this ability to reduce testcases well. Here are some useful slides that explain how to create reduced testcases.

  • UNCONFIRMED Core::Layout bugs
  • Sort the list different ways and look over it.
  • Pick a bug and read through it and its comments to thoroughly understand it.
  • Is the bug reproducible?
  • It may be UNCONFIRMED because it is not clear whether a reproducible issue is a problem within a Mozilla product or whether the problem lies somewhere else.
  • Search for bugs already tagged testcase-wanted and try to develop a testcase.

Creating a simplified DOM/layout test

  • These tips are from a talk by Martijn Wagners
  • This saves time for the developer
  • It is easier to convert into automated tests

Tools

  • DOM Inspector
  • Error Console
  • Disabling javascript
  • HTTP Headers (for network related problems)

Define the problem - URL/example? - Steps to reproduce? - Extensions installed? - Screenshot?

Layout bugs

DOM bugs

Problems - Report too vague, no url that shows the problem - Difficult/impossible to reproduce - Problem somewhere in an ajax library (which are usually huge) - Problems that can only be seen on a network (http headers,e tc)

Example problem bug

Firefox 3 onLoad event fireing before the page is fully loaded.

  • Page that shows the problem, but:
    • It's not happening very often
    • It seems to happen only over a (slow?) network connection
    • The JS code behind it is complicated

More info - http://developer.mozilla.org/en/Reducing_testcases - https://wiki.mozilla.org/MozillaQualityAssurance:Triage

Retrieved from "https://wiki.mozilla.org/index.php?title=Bugmasters/Projects&oldid=695161"