|
|
| (12 intermediate revisions by the same user not shown) |
| 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.
| | #REDIRECT [[Bugmasters#Projects]] |
| | |
| | |
| ==Middle-aged bugs==
| |
|
| |
| This is a project to work on Firefox bugs reported in a range time of -6months(-180d) to -1months(-30d).
| |
| | |
| These are bugs that haven't been changed recently, but were reported within the last 6 months.
| |
| Triaging them may find good, relevant bugs. It can also help clear out invalid bugs!
| |
| | |
| [https://bugzilla.mozilla.org/buglist.cgi?list_id=7036513&resolution=---&resolution=DUPLICATE&chfieldto=-30d&chfield=[Bug%20creation]&query_format=advanced&chfieldfrom=-180d&bug_status=UNCONFIRMED&component=Untriaged&product=Firefox Middle Aged Untriaged Firefox Bugs], UNCONFIRMED.
| |
| | |
| <onlyinclude>
| |
| <bugzilla>
| |
| {
| |
| "product": "Firefox",
| |
| "status": "UNCONFIRMED",
| |
| "include_fields": "id, summary, status, whiteboard",
| |
| "order": "bug_id",
| |
| "changed_before": "-1m",
| |
| "changed_after": "-6m"
| |
| | |
| }
| |
| </bugzilla>
| |
| </onlyinclude>
| |
| | |
| | |
| * '''Verify the bug'''
| |
| ** verify if the bug is still valid
| |
| ** read the description and try to reproduce it on the newest Firefox version
| |
| ** add ''need-info'' flag for reporter
| |
| *** eg. can you still reproduce the bug?
| |
| *** eg. could you provide more info about this?
| |
| ** ask for whatever additional details you need to understand
| |
| | |
| * '''Replicate the bug'''
| |
| ** if the bug is an enhancement request set the severity flag as ''enhancement''
| |
| ** if you cannot reproduce the bug
| |
| *** if the reporter doesn't answer 1 week later a requested need-info flag and the bug is INCOMPLETE tag the bug as closeme yyyyMMdd (perhaps 2 weeks later?) and wait for that period before you close it.
| |
| *** if the bug has all the info you need to close it, close as WORKSFORME or INVALID
| |
| ** if you cannot reproduce the bug and you are on a different OS add a need-replication tag
| |
| ** if you cannot reproduce the bug, help the reporter in resolving the problem if he/she answers.
| |
| ** if you can replicate the bug in the newer Firefox Versions
| |
| *** comment the bug
| |
| *** mark it as NEW
| |
| | |
| ''Remarks''
| |
| * If a bug reporter hasn't answered to qa requested added in the first week after he/she reported the bug, they are more likely to be not interested anymore.
| |
| * Some of these bugs have more than one comment, maybe those are more likely to be significant and already started to be triaged.
| |
| | |
| ==Nightly build bug team==
| |
| Hello! If you'd like to help out with bug management for Nightly builds, please email [mailto:bugmaster@mozilla.com bugmaster@mozilla.com]!
| |
| | |
| Every night the [http://www.mozilla.org/projects/firefox/prerelease.html latest pre-release version of Firefox] is made available. If you want to test against the cutting edge of Firefox, [http://nightly.mozilla.org/ download the Nightly build] and use it as your main browser. If you find any bugs, file them. ([[How to File a Bug]]).
| |
| | |
| You may also be interested in looking at the bugs others have filed, and see if you can replicate them or add any useful information. Triaging the Nightly bugs will help us catch important bugs as quickly as possible!
| |
| | |
| 1. Download the Nightly build and run it.<br>
| |
| 2. Make a bugzilla account.<br>
| |
| 3. Skim over the [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&resolution=DUPLICATE&query_format=advanced&version=24%20Branch&product=Firefox&list_id=6602828 current bugs against the Nightly release] (currently, 24 build).<br>
| |
| 4. File bugs when you find them.<br>
| |
| 5. Triage through the list of Nightly bugs. So helpful!<br>
| |
| --- replicate the bug, comment, and confirm it<br>
| |
| --- needinfo the bug reporter to get more details<br>
| |
| --- regression testing with the [http://mozilla.github.io/mozregression/ mozregression] tool<br>
| |
| <br>
| |
| | |
| For example, the current released version of Firefox is 22.0. The [http://www.mozilla.org/en-US/firefox/channel/ Beta] version is 23, and the Aurora version is 24. That means the Nightly build is 25. The bugs filed against that release are listed as being in the [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&resolution=DUPLICATE&query_format=advanced&version=25%20Branch&product=Firefox&list_id=6602828 25 branch] of Firefox.
| |
| | |
| * To search later branches, go to the [https://bugzilla.mozilla.org/query.cgi?query_format=advanced Advanced Search form] in Bugzilla, select Firefox for the product, then under the Detailed Bug Information dropdown, scroll through the Versions listed and select the latest one. That search will bring up all bugs reported for the latest nightly build.
| |
| | |
| * More explanation of the release channels for Firefox:
| |
| ** https://wiki.mozilla.org/Features/Release_Tracking
| |
| ** https://blog.mozilla.org/channels/2011/07/18/every-six-weeks/
| |
| | |
| ==Aurora bug triage team==
| |
| | |
| Hello! If you'd like to help out with bug management for Aurora builds, please email [mailto:bugmaster@mozilla.com bugmaster@mozilla.com]!
| |
| | |
| Every night the [http://www.mozilla.org/projects/firefox/prerelease.html latest pre-release version of Firefox] is made available as the Nightly release. After 6 weeks of further development that branch becomes the Aurora release, and is more stable than the nightly. If you want to test against the Aurora release of Firefox, [http://www.mozilla.org/en-US/firefox/channel/#aurora download the Aurora build] and use it as your main browser. If you find any bugs, file them. ([[How to File a Bug]]).
| |
| | |
| You may also be interested in looking at the bugs others have filed, and see if you can replicate them or add any useful information. Triaging the Aurora bugs will help us catch important bugs quickly, while you still have a relatively stable development browser to use!
| |
| | |
| 1. Download the Aurora build and run it.<br>
| |
| 2. Make a bugzilla account.<br>
| |
| 3. Skim over the [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&resolution=DUPLICATE&query_format=advanced&version=23%20Branch&product=Firefox&list_id=6602828 current bugs against the Aurora release] (currently, the 23 branch).<br>
| |
| 4. File bugs when you find them...<br>
| |
| 5. Triage through the list of [https://bugzilla.mozilla.org/buglist.cgi?list_id=6602871&resolution=---&resolution=DUPLICATE&query_format=advanced&version=23%20Branch&component=Untriaged&product=Firefox untriaged Aurora bugs]. So helpful!<br>
| |
| --- replicate, comment, confirm<br>
| |
| --- needinfo the bug reporter to get more details<br>
| |
| --- regression testing<br>
| |
| <br>
| |
| | |
| ==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==
| |
| 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 [http://people.mozilla.org/~mwargers/presentations/creating_a_dom_layout_test.odp slides that explain how to create reduced testcases].
| |
| | |
| * [https://bugzilla.mozilla.org/buglist.cgi?f1=OP&list_id=6456764&f0=OP&o2=substring&f4=CP&query_format=advanced&j1=OR&f3=CP&f2=component&bug_status=UNCONFIRMED&component=Layout&v2=layout&product=Core 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 [https://bugzilla.mozilla.org/buglist.cgi?keywords=testcase-wanted%2C%20&keywords_type=allwords&f1=OP&list_id=6456823&f0=OP&o2=substring&f4=CP&query_format=advanced&j1=OR&f3=CP&f2=component&bug_status=UNCONFIRMED&component=Layout&v2=layout&product=Core tagged testcase-wanted] and try to develop a testcase.
| |
| | |
| '''Creating a simplified DOM/layout test'''
| |
| * These tips are from a [http://people.mozilla.org/~mwargers/presentations/creating_a_dom_layout_test.odp 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'''
| |
| * Example 1: pop up menus on page are not displayed properly
| |
| * https://bugzilla.mozilla.org/show_bug.cgi?id=442304
| |
| * example 2: Hovering over links in large list is slow
| |
| ** https://bugzilla.mozilla.org/show_bug.cgi?id=449046
| |
| * Performance regression
| |
| * Adding a way to measure the perf regression
| |
| | |
| '''DOM bugs'''
| |
| * example 1: text entry field unable to take focus
| |
| ** https://bugzilla.mozilla.org/show_bug.cgi?id=440614
| |
| ** Typical editor problem
| |
| * example 2
| |
| ** https://bugzilla.mozilla.org/show_bug.cgi?id=387406
| |
| ** Form -> Select -> Jump-Menus, selectedIndex can be set to a disabled option
| |
| ** SelectedIndex and disabled options in select elements
| |
| | |
| '''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'''
| |
| * https://bugzilla.mozilla.org/show_bug.cgi?id=444322
| |
| 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
| |