User:Tyler/BMOsurvival3: Difference between revisions

Jump to navigation Jump to search
m
Round of typo fixes near the bottom
m (Minor cleanup in "FIXED, RESOLVED, VERIFIED, WHAT?")
m (Round of typo fixes near the bottom)
Line 23: Line 23:
<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. 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. </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 reference bug 471700, type Bug 471700. It will automatically create a link.</p>
<p>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.</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 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.</p>
<p>Canconfirm: With these privileges, you can confirm any bug.<br />
<p>Canconfirm: With these privileges, you can confirm any bug.<br />
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>
Line 34: Line 34:
<h2>FAQs</h2>
<h2>FAQs</h2>
<p>Q. How do I get started on BMO?<br />
<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>
   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.</p>
<p>Q. How many people use BMO?<br />
<p>Q. How many people use BMO?<br />
   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 dving force behind BMO.</p>
   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.</p>
<p>Q. What Mozilla products use BMO? Just Firefox?<br />
<p>Q. What Mozilla products use BMO? Just Firefox?<br />
A. Nope. Every single Mozilla product and website uses BMO for their development. Firefox, Thunderbird, mozilla.org, Camino, the whole bucket.</p>
A. Nope. Every single Mozilla product and website uses BMO for their development. Firefox, Thunderbird, mozilla.org, Camino, the whole bucket.</p>
16

edits

Navigation menu