16
edits
User:Tyler/BMOsurvival3: Difference between revisions
Jump to navigation
Jump to search
m
Fixed some typos in the "Teams" section
m (Removed "While" from beginning of first paragraph, "bug's" to "bugs") |
m (Fixed some typos in the "Teams" section) |
||
| Line 11: | Line 11: | ||
<p>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. </p> | <p>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. </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? | <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 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.</p> | ||
<p>Here are the 3 most popular and largest teams.</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 diagnostic steps, and ensure the bug is properly filed.<br /> | <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 diagnostic steps, and ensure the bug is properly filed.<br /> | ||
Development: This team is the muscle of the Mozilla project, with most patches coming from this group.<br /> | Development: This team is the muscle of the Mozilla project, with most patches coming from this group.<br /> | ||
QA: The Quality Assurance team, probably | 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. </p> | ||
<h2>FIXED, RESOLVED, VERIFIED, WHAT? </h2> | <h2>FIXED, RESOLVED, VERIFIED, 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> | ||