User:Tyler/BMOsurvival3
BMO Survival Guide
PART 3
Advanced BMO Details and FAQs
The first two parts of this guide give you the basics you need to survive on BMO, as well as an overview of how bugs work. However, there is so much more to BMO, most of which can not be covered without writing a very thick book. This last part of the guide will cover some of the more advanced details on BMO, and a bunch of Misc things to cover. If you want more information, a list of links is at the bottom. They will serve as a starting point for you to learn more.
Patches
If you submit a patch to BMO, you have to fill out a somewhat complex form with several fields. It can be hard to decide what to fill in.
- First, put the location of your patch in the locations field, then put a name, like "Patch, v1".
- Mark the patch checkbox.
- In the review, fill in the appropriate fields. For most patches, placing a "?" in "Review" and placing the e-mail address of a module owner there is good enough. All patches need to be reviewed by the owner or peers of the module that they are on. A somewhat comprehensive list of owners and peers can be found <a href="http://www.mozilla.org/owners.html" title="Mozilla Module Owners">here</a>.
- After you gain review "+", place "checkin-needed" in the keyword field. This will mark that your bug is ready to be checked into the tree. Until you gain commit status, you will have to have other people check your patches in.
The reason review occurs is to protect the tree. If everyone was able to simply make whatever change they wanted, the chances for an undesirable change increase dramatically. Review is a simple way for cross-checking work done, and making sure it is of good quality with no mistakes. Without asking for review, patches that are otherwise good could become lost in the system, and never be found.
Teams
In this document, you have heard about several different "teams": the triage team, the QA team, the development team, etc. You may be wondering, what are these teams? Teams are an informal gathering of users who perform tasks on BMO. However, for most teams, there is not a "sign-up sheet", etc. To participate in a team, follow some current members (watch already filed bugs). Jump on the appropriate IRC channel, and read up on the tasks you will perform. When you are ready, jump in. Some team members will place a note in their screen name that shows the team they are in, ie. Tyler Downer [Triage], but that is not required.
Here are the 3 most popular and largest teams.
Triage: This is the entry point team. Just like triage at a hospital, the members of this team will attempt to gather basic info on your issue, give you diagnostic steps, and ensure the bug is properly filed.
Development: This team is the muscle of the Mozilla project, with most patches coming from this group.
QA: The Quality Assurance team, probably one of the most organized teams, works closely with the Triage team. They perform testing of bugs and fixes. They also produce test cases to illustrate bugs.
FIXED, RESOLVED, VERIFIED, WHAT?
When the Bugzilla product was written, the developers made two levels for closing a bug. The first is Resolved whatever (DUPLICATE, FIXED, etc.). Beyond that, after a bug is resolved, it can be Verified as whatever it was resolved as. The main advantage of this approach is that it gives a second opinion, and ideally, in a perfect world, every bug should end as being verified. Unfortunately, this is not a perfect world. The majority of bugs are resolved, and that is as far as they get. There are simply too many bugs, and too few triage members. Only a portion of resolved bugs will be verified. So, the usual approach is this: while verified is nice, we have to live with resolved. Of course, if you enjoy making sure resolutions are accurate, by all means verify bugs.
Testing Bugzilla, the Product
We understand if you want to play around and test the actual Bugzilla product (<a href="http://www.bugzilla.org">www.bugzilla.org</a>). However, BMO is not the correct place to do that. You should use <a href="http://landfill.mozilla.org" target="_blank">landfill.bugzilla.org</a> to evaluate the different functions of Bugzilla, the product.
The Whiteboard, Again
We already went over the whiteboard, right? Wrong. The whiteboard is one of the most misunderstood and confusing aspects of a bug, even for developers. So, even the things said in this section could be in turmoil right now.
The whiteboard is a place where notes can be placed on a bug, keywords that are not keywords, or a request that something be done (such as a review).
One popular whiteboard note is CLOSEME. This note is supposed to be placed on the whiteboard of a bug that has not had any activity after a period of time (usually 3 weeks). The person who places the note should also place a comment asking for the required information. The close will have a date on it. On that date, the bug is supposed to be closed as INCOMPLETE, WFM, whatever resolution is appropriate. In theory, every bug that has had no comment after a request for more information should have this note added, and then be closed at the date specified. As already noted, theory does not always play out in the real world. So, while it would be nice to have a very orderly way of closing abandoned bugs, CLOSEME is not universally used, nor is it required to close a bug.
Handy Hints and Tricks
To create a link to a bug when writing a comment in BMO, simple write "Bug", followed by the number. Example: to reference bug 471700, type Bug 471700. It will automatically create a link.
Privileges
When you first sign up with BMO, you will be able to do very little. You can file a bug, and make changes to most areas of your own bug, and you can add comments and attachments to other bugs. However, you can not change the status or product, or change any fields of someone else's bug. You will need to be able to get extended privileges to do that.
Canconfirm: With these privileges, you can confirm any bug.
Canedit: With these privileges, you can edit any area of any bug.
These are about the highest privileges that most members of the community will get. Module owners, and Mozilla employees will be given more privileges as required.
Now, how do you get privileges? You need to demonstrate that you deserve them.
FAQs
Q. How do I get started on BMO?
A. Really easy. Simply read this document, sign up for an account and start! You may want to file a few bugs or try to confirm already filed ones to gain privileges. A good way to gain experience is to CC yourself to some existing bugs.
Q. How many people use BMO?
A. Thousands. Besides the hundreds of regular team members and bug reporters, many people report one-time issues on BMO as well. Volunteers are the driving force behind BMO.
Q. What Mozilla products use BMO? Just Firefox?
A. Nope. Every single Mozilla product and website uses BMO for their development. Firefox, Thunderbird, mozilla.org, Camino, the whole bucket.
Q. What about extensions, should I report issues on them at BMO?
A. With the exception of a very few Mozilla developed extensions (such as the QA companion), extensions are usually developed by people other than Mozilla. The developers at BMO can not fix their bugs for them, so please report extension issues to the software vendor.
Q. Can anyone contribute to Mozilla? Even when I can't code?
A. Absolutely! We need all the help we can get, and you can use your gifts in almost any area on Mozilla. Can you write good documents? Then help keep developer.mozilla.org up to date, or any of the hundreds of different docs. Can you write HTML? Then create test cases. Can you follow instruction well and find issues? Then join the QA team. Can you code? Create patches. There are tons of things to do outside of BMO. support.mozilla.org needs help, you can evangelize Mozilla projects to websites, or even just tell your friends.
A List of Resources
This list will be put up shortly.
