Bugmasters/Projects
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.
1. Sign up for a Bugzilla account.
2. Make a Mozillians account and tag yourself "bugmasters" and "triage".
3. Join the irc channel and the bugmasters mailing list. Introduce yourself on the list!
4. Try the bug triage tutorial.
5. You might want to install the BugzillaJS add-on.
At first, you will only be able to comment on bugs. After you have added information to several bugs, let us know in the #bugmasters irc channel, and we can give you the ability to confirm and then edit bug reports.
Websites Team
This is for bugs that have been reported in Mozilla-run websites. It is probably the easiest group of bugs to confirm, so it's a good starting point!
Confirming UNCONFIRMED Websites bugs
- Take a look at the Website UNCONFIRMED bugs.
- Sort on Status, ID, or another field.
- Check to see that the bug still exists.
- You may want to check it on both the current Firefox version and the Nightly build.
- If you can't reproduce it, ask the reporter, in a comment with a need-info flag, if they can reproduce it.
- If they can't, or don't answer after a week or so, resolve the bug as WORKSFORME.
- If you can reproduce it, mark it NEW and leave a comment to describe what you did. You may be able to find a person to cc on the bug if you look for who has resolved past, similar bugs.
- If you can't reproduce it, ask the reporter, in a comment with a need-info flag, if they can reproduce it.
21 Total; 21 Open (100%); 0 Resolved (0%); 0 Verified (0%);
- Websites bugs marked NEW can also use triaging! Here's a bugzilla query for Website NEW bugs reported within the last year.
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!
Middle Aged Untriaged Firefox Bugs, UNCONFIRMED.
162 Total; 162 Open (100%); 0 Resolved (0%); 0 Verified (0%);
- 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.
Firefox UNCONFIRMED Team
Latest Untriaged Firefox bugs, UNCONFIRMED, from the last 60 days.
You may want to edit your search, limiting it to only the operating systems you can test.
| ID | Summary | Status | Op sys | Whiteboard |
|---|---|---|---|---|
| 2008336 | some sessions/computers can't start firefox | UNCONFIRMED | Unspecified | |
| 2008480 | Firefox 146.0.1 freezes completely and must be killed after sleep or locked screen | UNCONFIRMED | Unspecified | |
| 2008529 | Automation test has significant performance drop in Firefox 140 and 144 | UNCONFIRMED | Unspecified | |
| 2009094 | Remove "Style sheet could not be loaded." warning or make it actionable | UNCONFIRMED | Unspecified |
4 Total; 4 Open (100%); 0 Resolved (0%); 0 Verified (0%);
- Understand the bug
- Read the description and comments in the bug to understand the problem.
- If you don't understand the bug
- Comment, add need-info flag for reporter.
- Ask for whatever additional details you need to understand.
- Check if it's a duplicate
- Search on similar terms in Bugzilla to see if it is a duplicate of another bug.
- How to search for duplicate bugs: https://developer.mozilla.org/en-US/docs/Screening_duplicate_bugs
- (How to tell if it's a likely dup)
- Tag it dupeme? if you're not sure, and move on.
- This search may reveal what product and component the bug should go into.
- Check if it's a support question
- If it's a support question (often malware, FF is slow reports)
- Nicely let the reporter know where to look for the answer or for help.
- Ask the reporter with a need-info flag to resolve the bug as invalid, or resolve it yourself.
- Test case, if needed
- If this bug needs a test case and you don't have one:
- Ask the reporter for one. That might mean simplest or reduced test case code, or a URL.
- Or you could generate a test case and attach it.
- Replicate the bug
- Can you replicate the bug? In the same OS?
- If you can replicated it, and no one else has, leave a comment.
- If you can't replicate it, and are in the same OS
- Ask the reporter with need-info if they still see the issue
- (Especially if it's an older bug and we're on a new version of FF now)
- If they don't you can resolve it WORKSFORME or ask reporter to do so
- If they still see the bug, tag it needs-replication
- If you can't replicated it and are in a different OS
- Comment
- tag it needs-replication
- Safe mode, plugins off, New profile
- In some cases (but not all) you may want to ask the bug reporter if they still see the bug in safe mode (with all plugins disabled) and with a new profile.
- (((Explain when and when perhaps not to do this)))
- IF you can replicate the bug, and it's likely to be a Firefox bug (not a bug with a plugin, etc)
- Comment that you replicated the bug
- Mark it NEW
- You can keep adding info to the bug if you think it will be useful.
Incoming Team
Bugs Filed Today. All bugs filed in the last 24 hours. Usually this is around 400 bugs, but the number fluctuates over the course of the day.
180 Total; 161 Open (89.44%); 18 Resolved (10%); 1 Verified (0.56%);
To work in this area, go through the bugs with status UNCONFIRMED.
- Today's UNCO Bugs
- If you can reproduce a bug, and are fairly sure it is a Mozilla bug, comment on the bug to explain how you reproduced the bug.
- Include screenshots or a reduced test case, if they seem useful.
- If you have canconfirm permissions, mark the bug NEW.
- Assign the bug into a product and component, or tag it needs-component
- Tag the bug with other triage tasks that may be needed.
- If the bug is really a support question, please thank the bug reporter in a comment. Explain where the bug reporter should look for an answer.
- Mark the bug RESOLVED INVALID if you have canconfirm permissions.
Nightly build bug team
Hello! If you'd like to help out with bug management for Nightly builds, please email bugmaster@mozilla.com!
Every night the latest pre-release version of Firefox is made available. If you want to test against the cutting edge of Firefox, 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.
2. Make a bugzilla account.
3. Skim over the current bugs against the Nightly release (currently, 24 build).
4. File bugs when you find them.
5. Triage through the list of Nightly bugs. So helpful!
--- replicate the bug, comment, and confirm it
--- needinfo the bug reporter to get more details
--- regression testing with the mozregression tool
For example, the current released version of Firefox is 22.0. The 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 25 branch of Firefox.
- To search later branches, go to the 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:
Aurora bug triage team
Hello! If you'd like to help out with bug management for Aurora builds, please email bugmaster@mozilla.com!
Every night the 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, 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.
2. Make a bugzilla account.
3. Skim over the current bugs against the Aurora release (currently, the 23 branch).
4. File bugs when you find them...
5. Triage through the list of untriaged Aurora bugs. So helpful!
--- replicate, comment, confirm
--- needinfo the bug reporter to get more details
--- regression testing
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
Currently, mentored bugs feed the Bugs Ahoy site.
Good first bugs feed into 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.
- 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.
- Sort the list by component.
- 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 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
- 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
- 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
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