Confirmed users
494
edits
User:Tyler/BMOsurvival3: Difference between revisions
Jump to navigation
Jump to search
added major content changes
(text now) |
(added major content changes) |
||
| Line 2: | Line 2: | ||
<h2>PART 3 </h2> | <h2>PART 3 </h2> | ||
<h1>Advanced BMO Details and FAQs </h1> | <h1>Advanced BMO Details and FAQs </h1> | ||
<p>While the first two parts of this guide give you the basics you need to survive on BMO, and how bug's work. However, there is so much more to BMO, most of which can not be covered without writing a very thick book | <p>While the first two parts of this guide give you the basics you need to survive on BMO, and how bug's 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, and list of links is at the bottom, and will give you a starting point to go to learn more. </p> | ||
<h2>Patches</h2> | <h2>Patches</h2> | ||
<p>If you submit a patch to BMO, you have to fill out a somewhat complex form witout several fields. It can be hard to decide what to fill in.</p> | |||
<p>First, put the location of your patch in the locations field, then put a name, like "Patch, v1".<br /> | |||
Mark the patch checkbox.<br /> | |||
In the review, fill in the approiate 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 reviewd by the owner, or peers of the module that they are on. A somewhat comprehensive list of owners and peers can be found here.<br /> | |||
After you gain review "+", place "checkin-needed" in the keyword field. This will amrk 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.</p> | |||
<p>The reson review occours isto 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 othewise good could become lost in the system, and never be found. </p> | |||
<h2>Teams</h2> | <h2>Teams</h2> | ||
<p>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 as informal gathering of users, who will 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 apprioprate 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 scren name that shows the team they are in, ie. Tyler Downer [Triage], but that is not required.</p> | |||
<p>Here are the 3 most popular and largest teams.</p> | |||
<p>Triage: 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 diganostic steps, and enure the bug is properly filed.<br /> | |||
Development: This team is the muscle of the Mozilla project, with most patches comming from this group.<br /> | |||
QA: The Quality Assurance team, probably on of the most organized teams, works closely with the Triage team. They perform testing of bugs and fixes. They also produce testcases to illustrate bugs. </p> | |||
<h2>FIXED, RESOLVED, VERFIED, WHAT? </h2> | <h2>FIXED, RESOLVED, VERFIED, WHAT? </h2> | ||
<p>When the bugzilla product was written, the developers placed two levels or 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 bus 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. </p> | <p>When the bugzilla product was written, the developers placed two levels or 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 bus 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. </p> | ||
<h2>Testing Bugzilla, the Product </h2> | <h2>Testing Bugzilla, the Product </h2> | ||
<p>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> </p> | <p>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 evaulate the different functions of Bugzilla, the product. </p> | ||
<h2>The Whiteboard, Again</h2> | <h2>The Whiteboard, Again</h2> | ||
<p>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. </p> | <p>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. </p> | ||
<p>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).</p> | <p>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).</p> | ||
<p>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. One 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. </p> | <p>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. One 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. </p> | ||
<h2>Handy Hints and Tricks </h2> | <h2>Handy Hints and Tricks </h2> | ||
<p>To create a link to a bug when writing a comment in BMO, simple write bug, followed by the number. Example to refrence bug 471700, type Bug 471700. It will automatically create a link.</p> | |||
<h2>Privileges</h2> | <h2>Privileges</h2> | ||
<p>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 won 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.</p> | <p>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 won 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.</p> | ||
| Line 21: | Line 31: | ||
Canedit: With these privileges, you can edit any area of any bug. </p> | Canedit: With these privileges, you can edit any area of any bug. </p> | ||
<p>These are about the highest privs that most members of the community will get. Module owners, and Mozilla employees will be given more privileges as required.</p> | <p>These are about the highest privs that most members of the community will get. Module owners, and Mozilla employees will be given more privileges as required.</p> | ||
<p>Now, how do you get privileges? You need to demonstrate that you deserve them. </p> | <p>Now, how do you get privileges? You need to demonstrate that you deserve them. </p> | ||
<h2>FAQs</h2> | <h2>FAQs</h2> | ||
<h2>A List of Resources </h2> | <p>Q. How do I get started on BMO?<br /> | ||
A. Really easy. Simply read this document, sign up for an account and start! You may want to file a few bugs ortry to confirm already filed ones to gain priveliges. A good way to gain experience is to CC yourself to some existing bugs.</p> | |||
<p>Q. How many people use BMO?<br /> | |||
A. Thousands. Besids the hundereds of regular team members and bug reporters, many people report one time issues on BMO as well. Volunteers are the dving force behind BMO.</p> | |||
<p>Q. What Mozilla products use BMO? Just firefox?<br /> | |||
A. Nope. Every single Mozillam product and website uses BMO for their development. Firefox, Thunderbird, mozilla.org, Camino, the whole bucket.</p> | |||
<p>Q. What about extensions, should I report issues on them at BMO?<br /> | |||
A. With the exeption 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 issue to the software vender. </p> | |||
<p>Q. Can anyone contribute to Mozilla? Even when I can't code?<br /> | |||
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 testcases. Can you folow 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 evanglize Mozilla projects to websites, or even just tell your friends.</p> | |||
<h2>A List of Resources</h2> | |||
<p>This list will be put up shortly. </p> | |||
<h2>[https://wiki.mozilla.org/User:Tyler/BMOsurvival2<<< Previous Page - Bug Reports, from Top to Bottom]</h2> | <h2>[https://wiki.mozilla.org/User:Tyler/BMOsurvival2<<< Previous Page - Bug Reports, from Top to Bottom]</h2> | ||