openfirst-cvscommit

[Tim G. <xt...@us...>]

Update of /cvsroot/openfirst/www/htdocs/bugzilla/pages
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv28397/pages

Added Files:
	bug-writing.html.tmpl fields.html.tmpl linked.html.tmpl 
	linkify.html.tmpl voting.html.tmpl 
Log Message:
Bring templates up to date for Bugzilla 2.18.1

--- NEW FILE: linked.html.tmpl ---
[%# 1....@bu... %]
[%# The contents of this file are subject to the Mozilla Public
  # License Version 1.1 (the "License"); you may not use this file
  # except in compliance with the License. You may obtain a copy of
  # the License at http://www.mozilla.org/MPL/
  #
  # Software distributed under the License is distributed on an "AS
  # IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
  # implied. See the License for the specific language governing
  # rights and limitations under the License.
  #
  # The Original Code is the Bugzilla Bug Tracking System.
  #
  # The Initial Developer of the Original Code is Netscape Communications
  # Corporation. Portions created by Netscape are
  # Copyright (C) 1998 Netscape Communications Corporation. All
  # Rights Reserved.
  #
  # Contributor(s): Stefan Seifert <ni...@de...>
  #                 Gervase Markham <ge...@ge...>
  #%]

[% INCLUDE global/header.html.tmpl title = "Your Linkified Text" %]
[% USE Bugzilla %]
[% cgi = Bugzilla.cgi %]

<p>
  Copy and paste the text below:
</p>

<hr>

<p>
<pre>
[%- cgi.param("text") FILTER quoteUrls FILTER html -%]
</pre>
</p>

<hr>

<p>
  If you place it in <tt>&lt;pre&gt;</tt> tags, 
  the text will end up looking like this:
</p>

<hr>

<p>
<pre>
[%- cgi.param("text") FILTER quoteUrls -%]
</pre>
</p>

<hr>

[% INCLUDE global/footer.html.tmpl %]

--- NEW FILE: bug-writing.html.tmpl ---
[%# 1....@bu... %]
[%# The contents of this file are subject to the Mozilla Public
  # License Version 1.1 (the "License"); you may not use this file
  # except in compliance with the License. You may obtain a copy of
  # the License at http://www.mozilla.org/MPL/
  #
  # Software distributed under the License is distributed on an "AS
  # IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
  # implied. See the License for the specific language governing
  # rights and limitations under the License.
  #
  # The Original Code is the Bugzilla Bug Tracking System.
  #
  # The Initial Developer of the Original Code is Netscape Communications
  # Corporation. Portions created by Netscape are
  # Copyright (C) 1998 Netscape Communications Corporation. All
  # Rights Reserved.
  #
  # Contributor(s): Eli Goldberg <el...@pr...>
  #                 Gervase Markham <ge...@ge...>
  #                 Claudius Gayle
  #                 Peter Mock
  #                 Chris Pratt
  #                 Tom Schutter
  #                 Chris Yeh
  #%]
  
[% PROCESS global/variables.none.tmpl %] 
[% INCLUDE global/header.html.tmpl title = "$terms.Bug Writing Guidelines" %] 

<h3>Why You Should Read This</h3>

<blockquote>
  <p>Simply put, the more effectively you report [% terms.abug %], the more
  likely an
  engineer will actually fix it.</p>

  <p>These guidelines are a general tutorial to teach novice and
  intermediate [% terms.bug %] reporters how to compose effective 
  [% terms.bug %] reports. Not
  every sentence may precisely apply to your software project.</p>
</blockquote>

<h3>How to Write a Useful [% terms.Bug %] Report</h3>

<blockquote>
  <p>Useful [% terms.bug %] reports are ones that get [% terms.bugs %] fixed. 
  A useful [% terms.bug %] report normally has two qualities:</p>

  <ol>
    <li><b>Reproducible.</b> If an engineer can't see the [% terms.bug %]
    herself to prove that it exists, she'll probably stamp your [% terms.bug %]
    report "WORKSFORME" or "INVALID" and move on to the next [% terms.bug %].
    Every detail you can provide helps.<br>
    <br>
    </li>

    <li><b>Specific.</b> The quicker the engineer can isolate the 
    [% terms.bug %] to a specific area, the more likely she'll expediently 
    fix it. (If a programmer or tester has to decipher [% terms.abug %], 
    they may spend more time cursing the submitter than solving the 
    problem.)<br>
    <br>
    [ <a href="#tips" name="Anchor">Tell Me More</a> ]</li>
  </ol>

  <p>Let's say the application you're testing is a web browser. You crash
  at foo.com, and want to write up a [% terms.bug %] report:</p>

  <blockquote>
    <p><b>BAD:</b> "My browser crashed. I think I was on www.foo.com. I
    play golf with Bill Gates, so you better fix this problem, or I'll
    report you to him. By the way, your Back icon looks like a squashed
    rodent. UGGGLY. And my grandmother's home page is all messed up in your
    browser. Thx 4 UR help."</p>

    <p><b>GOOD:</b> "I crashed each time I went to www.foo.com, using the
    2002-02-25 build on a Windows 2000 system. I also rebooted into Linux,
    and reproduced this problem using the 2002-02-24 Linux build.</p>

    <p>It again crashed each time upon drawing the Foo banner at the top of
    the page. I broke apart the page, and discovered that the following
    image link will crash the application reproducibly, unless you remove
    the "border=0" attribute:</p>

    <p><tt>&lt;IMG SRC="http://www.foo.com/images/topics/topicfoos.gif"
    width="34" height="44" border="0" alt="News"&gt;</tt></p>
  </blockquote>
</blockquote>

<h3>How to Enter your Useful [% terms.Bug %] Report 
    into [% terms.Bugzilla %]:</h3>

<blockquote>
  <p>Before you enter your [% terms.bug %], use [% terms.Bugzilla %]'s 
  <a href="query.cgi">search page</a> to determine whether the defect 
  you've discovered is a known, already-reported [% terms.bug %]. If 
  your [% terms.bug %] is the 37th duplicate of a known issue,
  you're more likely to annoy the engineer. (Annoyed engineers fix fewer
  [% terms.bugs %].)</p>

  <p>Next, be sure to reproduce your [% terms.bug %] using a recent build. 
  Engineers tend to be most interested in problems affecting the code base 
  that they're actively working on. After all, the [% terms.bug %] you're 
  reporting may already be fixed.</p>

  <p>If you've discovered a new [% terms.bug %] using a current build, report 
  it in [% terms.Bugzilla %]:</p>

  <ol>
    <li>From your [% terms.Bugzilla %] main page, choose 
    "<a href="enter_bug.cgi">Enter a new [% terms.bug %]</a>".</li>

    <li>Select the product that you've found a [% terms.bug %] in.</li>

    <li>Enter your e-mail address, password, and press the "Login" button.
    (If you don't yet have a password, leave the password field empty, and
    press the "E-mail me a password" button instead. You'll quickly receive
    an e-mail message with your password.)</li>
  </ol>

  <p>Now, fill out the form. Here's what it all means:</p>

  <p><b>Where did you find the [% terms.bug %]?</b></p>

  <blockquote>
    <p><b>Product: In which product did you find the [% terms.bug %]?</b><br>
     You just specified this on the last page, so you can't edit it
    here.</p>

    <p><b>Version: In which product version did you find 
          the [% terms.bug %]?</b><br>
     (If applicable)</p>

    <p><b>Component: In which component does the [% terms.bug %] 
          exist?</b><br>
    [% terms.Bugzilla %] requires that you select a component to enter 
    a [% terms.bug %]. (Not sure which to choose? Click on the Component link. 
    You'll see a description of each component, to help you make the best 
    choice.)</p>

    <p><b>OS: On which Operating System (OS) did you find 
          this [% terms.bug %]?</b>
    (e.g. Linux, Windows 2000, Mac OS 9.)<br>
    If you know the [% terms.bug %] happens on all OSs, choose 'All'. 
    Otherwise, select the OS that you found the [% terms.bug %] on, or 
    "Other" if your OS isn't listed.</p>
  </blockquote>

  <p><b>How important is the [% terms.bug %]?</b></p>

  <blockquote>
    <p><b>Severity: How damaging is the [% terms.bug %]?</b><br>
     This item defaults to 'normal'. If you're not sure what severity your
    [% terms.bug %] deserves, click on the Severity link. You'll see a
    description of each severity rating.<br>
    </p>
  </blockquote>

  <p><b>Who will be following up on the [% terms.bug %]?</b></p>

  <blockquote>
    <p><b>Assigned To: Which engineer should be responsible for fixing
    this [% terms.bug %]?</b><br>
    [% terms.Bugzilla %] will automatically assign the [% terms.bug %] to a
    default engineer upon submitting [% terms.abug %] report. If you'd prefer
    to directly assign the [% terms.bug %] to someone else, enter their e-mail
    address into this field. (To see the list of default engineers for each
    component, click on the Component link.)</p>

    <p><b>Cc: Who else should receive e-mail updates on changes to this
    [% terms.bug %]?</b><br>
     List the full e-mail addresses of other individuals who should receive
    an e-mail update upon every change to the [% terms.bug %] report. You can
    enter as many e-mail addresses as you'd like, separated by spaces or 
    commas, as long as those people have [% terms.Bugzilla %] accounts.</p>
  </blockquote>

  <p><b>What else can you tell the engineer about the [% terms.bug %]?</b></p>

  <blockquote>
    <p><b>Summary:</b> <b>How would you describe the [% terms.bug %], in 
    approximately 60 or fewer characters?</b><br>
     A good summary should <b>quickly and uniquely identify [% terms.abug %]
    report</b>. Otherwise, an engineer cannot meaningfully identify your
    [% terms.bug %] by its summary, and will often fail to pay attention to 
    your [% terms.bug %] report when skimming through a 10 
    page [% terms.bug %] list.<br>
    <br>
     A useful summary might be "<tt>PCMCIA install fails on Tosh Tecra
    780DVD w/ 3c589C</tt>". "<tt>Software fails</tt>" or "<tt>install
    problem</tt>" would be examples of a bad summary.<br>
    <br>
     [ <a href="#summary">Tell Me More</a> ]<br>
    <br>
     <b>Description:</b><br>
     Please provide a detailed problem report in this field. Your 
     [% terms.bug %]'s recipients will most likely expect the following 
     information:</p>

    <blockquote>
      <p><b>Overview Description:</b> More detailed expansion of
      summary.</p>

      <blockquote>
<pre>
Drag-selecting any page crashes Mac builds in NSGetFactory
</pre>
      </blockquote>

      <p><b>Steps to Reproduce:</b> Minimized, easy-to-follow steps that
      will trigger the [% terms.bug %]. Include any special setup steps.</p>

      <blockquote>
<pre>
1) View any web page. (I used the default sample page,
resource:/res/samples/test0.html)

2) Drag-select the page. (Specifically, while holding down 
the mouse button, drag the mouse pointer downwards from any 
point in the browser's content region to the bottom of the 
browser's content region.)                   
</pre>
      </blockquote>

      <p><b>Actual Results:</b> What the application did after performing
      the above steps.</p>

      <blockquote>
<pre>
The application crashed. Stack crawl appended below from MacsBug.
</pre>
      </blockquote>

      <p><b>Expected Results:</b> What the application should have done,
      were the [% terms.bug %] not present.</p>

      <blockquote>
<pre>
The window should scroll downwards. Scrolled content should be selected. 
(Or, at least, the application should not crash.)
</pre>
      </blockquote>

      <p><b>Build Date &amp; Platform:</b> Date and platform of the build
      that you first encountered the [% terms.bug %] in.</p>

      <blockquote>
<pre>
Build 2002-03-15 on Mac OS 9.0
</pre>
      </blockquote>

      <p><b>Additional Builds and Platforms:</b> Whether or not 
      the [% terms.bug %] takes place on other platforms (or browsers, 
      if applicable).</p>

      <blockquote>
<pre>
- Also Occurs On        
Mozilla (2002-03-15 build on Windows NT 4.0) 

- Doesn't Occur On        
Mozilla (2002-03-15 build on Red Hat Linux; feature not supported)        
Internet Explorer 5.0 (shipping build on Windows NT 4.0)        
Netscape Communicator 4.5 (shipping build on Mac OS 9.0)
</pre>
      </blockquote>

      <p><b>Additional Information:</b> Any other debugging information.
      For crashing [% terms.bugs %]:</p>

      <ul>
        <li><b>Win32:</b> if you receive a Dr. Watson error, please note
        the type of the crash, and the module that the application crashed
        in. (e.g. access violation in apprunner.exe)</li>

        <li><b>Mac OS:</b> if you're running MacsBug, please provide the
        results of a <b>how</b> and an <b>sc</b>:</li>
      </ul>

      <blockquote>
<pre>
*** MACSBUG STACK CRAWL OF CRASH (Mac OS)
Calling chain using A6/R1 links 
Back chain  ISA  Caller 
00000000    PPC  0BA85E74   
03AEFD80    PPC  0B742248   
03AEFD30    PPC  0B50FDDC  NSGetFactory+027FC
PowerPC unmapped memory exception at 0B512BD0 NSGetFactory+055F0
</pre>
      </blockquote>
    </blockquote>
  </blockquote>

  <p>You're done!<br>
  <br>
   After double-checking your entries for any possible errors, press the
  "Commit" button, and your [% terms.bug %] report will now be in 
  the [% terms.Bugzilla %] database.<br>
  </p>
</blockquote>
<hr>

<h3>More Information on Writing Good [% terms.Bugs %]</h3>

<blockquote>
  <p><b><a name="tips"></a> 1. General Tips for a Useful [% terms.Bug %] 
     Report</b></p>

  <blockquote>
    <p><b>Use an explicit structure, so your [% terms.bug %] reports are easy
    to skim.</b> [% terms.Bug %] report users often need immediate access to 
    specific sections of your [% terms.bug %]. If your [% terms.Bugzilla %] 
    installation supports the [% terms.Bugzilla %] Helper, use it.</p>

    <p><b>Avoid cuteness if it costs clarity.</b> Nobody will be laughing
    at your funny [% terms.bug %] title at 3:00 AM when they can't remember how 
    to find your [% terms.bug %].</p>

    <p><b>One [% terms.bug %] per report.</b> Completely different people 
    typically fix, verify, and prioritize different [% terms.bugs %]. If you 
    mix a handful of [% terms.bugs %] into a single report, the right people 
    probably won't discover your [% terms.bugs %] in a timely fashion, or at 
    all. Certain [% terms.bugs %] are also more important than others. It's 
    impossible to prioritize [% terms.abug %] report when
    it contains four different issues, all of differing importance.</p>

    <p><b>No [% terms.bug %] is too trivial to report.</b> Unless you're 
    reading the source code, you can't see actual software [% terms.bugs %], 
    like a dangling pointer -- you'll see their visible manifestations, such 
    as the segfault when the application finally crashes. Severe software 
    problems can manifest themselves in superficially trivial ways. File them
    anyway.<br>
    </p>
  </blockquote>

  <p><b><a name="summary"></a>2. How and Why to Write Good [% terms.Bug %]
  Summaries</b></p>

  <blockquote>
    <p><b>You want to make a good first impression on the [% terms.bug %]
    recipient.</b> Just like a New York Times headline guides readers
    towards a relevant article from dozens of choices, will 
    your [% terms.bug %] summary suggest that your [% terms.bug %] report is 
    worth reading from dozens or hundreds of choices?</p>

    <p>Conversely, a vague [% terms.bug %] summary like <tt>install 
    problem</tt> forces anyone reviewing installation [% terms.bugs %] to waste 
    time opening up your [% terms.bug %] to determine whether it matters.</p>

    <p><b>Your [% terms.bug %] will often be searched by its summary.</b> Just 
    as you'd find web pages with Google by searching by keywords through 
    intuition, so will other people locate your [% terms.bugs %]. 
    Descriptive [% terms.bug %] summaries are
    naturally keyword-rich, and easier to find.</p>

    <p>For example, you'll find a [% terms.bug %] titled "<tt>Dragging icons 
    from List View to gnome-terminal doesn't paste path</tt>" if you search on
    "List", "terminal", or "path". Those search keywords wouldn't have
    found a [% terms.bug %] titled "<tt>Dragging icons doesn't paste</tt>".</p>

    <p>Ask yourself, "Would someone understand my [% terms.bug %] from just 
    this summary?" If so, you've written a fine summary.</p>

    <p><b>Don't write titles like these:</b></p>

    <ol>
      <li>"Can't install" - Why can't you install? What happens when you
      try to install?</li>

      <li>"Severe Performance Problems" - ...and they occur when you do
      what?</li>

      <li>"back button does not work" - Ever? At all?</li>
    </ol>

    <p><b>Good [% terms.bug %] titles:</b></p>

    <ol>
      <li>"1.0 upgrade installation fails if Mozilla M18 package present" -
      Explains problem and the context.</li>

      <li>"RPM 4 installer crashes if launched on Red Hat 6.2 (RPM 3)
      system" - Explains what happens, and the context.</li>
    </ol>
  </blockquote>
</blockquote>

[% INCLUDE global/footer.html.tmpl %]

--- NEW FILE: linkify.html.tmpl ---
[%# 1....@bu... %]
[%# The contents of this file are subject to the Mozilla Public
  # License Version 1.1 (the "License"); you may not use this file
  # except in compliance with the License. You may obtain a copy of
  # the License at http://www.mozilla.org/MPL/
  #
  # Software distributed under the License is distributed on an "AS
  # IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
  # implied. See the License for the specific language governing
  # rights and limitations under the License.
  #
  # The Original Code is the Bugzilla Bug Tracking System.
  #
  # The Initial Developer of the Original Code is Netscape Communications
  # Corporation. Portions created by Netscape are
  # Copyright (C) 1998 Netscape Communications Corporation. All
  # Rights Reserved.
  #
  # Contributor(s): Stefan Seifert <ni...@de...>
  #                 Gervase Markham <ge...@ge...>
  #%]

[% PROCESS global/variables.none.tmpl %]
[% INCLUDE global/header.html.tmpl title = "Linkify Text" %]

<p>
  If you enter some text, this form will return it marked up like a
  standard [% terms.Bugzilla %] comment. That is, valid [% terms.bug %] numbers,
  URLs, email addresses and so on will be replaced with appropriate HTML links.
</p>

<form action="page.cgi" method="post">
  <textarea cols="80" rows="20" name="text" wrap="hard"></textarea>
  <br>
  <input type="hidden" name="id" value="linked.html">
  <input value="Linkify" type="submit">
</form>

[% INCLUDE global/footer.html.tmpl %]

--- NEW FILE: voting.html.tmpl ---
[%# 1....@bu... %]
[%# The contents of this file are subject to the Mozilla Public
  # License Version 1.1 (the "License"); you may not use this file
  # except in compliance with the License. You may obtain a copy of
  # the License at http://www.mozilla.org/MPL/
  #
  # Software distributed under the License is distributed on an "AS
  # IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
  # implied. See the License for the specific language governing
  # rights and limitations under the License.
  #
  # The Original Code is the Bugzilla Bug Tracking System.
  #
  # The Initial Developer of the Original Code is Netscape Communications
  # Corporation. Portions created by Netscape are
  # Copyright (C) 1998 Netscape Communications Corporation. All
  # Rights Reserved.
  #
  # Contributor(s): Terry Weissman <te...@mo...>
  #                 Gervase Markham <ge...@ge...>
  #%]

[% PROCESS global/variables.none.tmpl %]
[% INCLUDE global/header.html.tmpl title = "Voting" %]

<p>[% terms.Bugzilla %] has a "voting" feature. Each product allows users to 
have a certain number of votes. (Some products may not allow any, which means 
you can't vote on things in that product at all.) With your vote, you indicate
which [% terms.bugs %] you think are the most important to be fixed.</p>

<p>Depending on how the administrator has configured the relevant product,
you may be able to vote for the same [% terms.bug %] more than one time. But 
remember, you only have so many votes to use in total! So, you can either vote 
a little for many [% terms.bugs %], or vote a lot for a few [% terms.bugs %].
</p>

<p>To look at votes:</p>

<ul>
  <li>Go to the query page. Do a normal query, but enter 1 in the "At least
  ___ votes" field. This will show you items that match your query that
  have at least one vote.</li>
</ul>

<p>To vote for [% terms.abug %]:</p>

<ul>
  <li>Bring up the [% terms.bug %] in question.</li>

  <li>Click on the "Vote for this [% terms.bug %]" link that appears just 
  above the "Additional Comments" field. (If no such link appears, then voting 
  may not be allowed in this [% terms.bug %]'s product.)</li>

  <li>Indicate how many votes you want to give this [% terms.bug %]. This page 
  also displays how many votes you've given to other [% terms.bugs %], so you 
  may rebalance your votes as necessary.</li>
</ul>

<p>You will automatically get email notifying you of any changes that occur
on [% terms.bugs %] you vote for.</p>

<p>You may review your votes at any time by clicking on the "<a href=
"votes.cgi?action=show_user">My Votes</a>" link in the page footer.</p>

[% INCLUDE global/footer.html.tmpl %]

--- NEW FILE: fields.html.tmpl ---
[%# 1....@bu... %]
[%# The contents of this file are subject to the Mozilla Public
  # License Version 1.1 (the "License"); you may not use this file
  # except in compliance with the License. You may obtain a copy of
  # the License at http://www.mozilla.org/MPL/
  #
  # Software distributed under the License is distributed on an "AS
  # IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
  # implied. See the License for the specific language governing
  # rights and limitations under the License.
  #
  # The Original Code is the Bugzilla Bug Tracking System.
  #
  # The Initial Developer of the Original Code is Netscape Communications
  # Corporation. Portions created by Netscape are
  # Copyright (C) 1998 Netscape Communications Corporation. All
  # Rights Reserved.
  #
  # Contributor(s): Terry Weissman <te...@mo...>
  #                 Gervase Markham <ge...@ge...>
  #%]

[% PROCESS global/variables.none.tmpl %]
[% INCLUDE global/header.html.tmpl title = "A $terms.Bug's Life Cycle" %]

<p>
The <b>status</b> and <b>resolution</b> fields define and track the life
cycle of [% terms.abug %].  
</p>

<a name="status"></a>
<a name="resolution"></a>

<table border="1" cellpadding="4">
  <tr align="center" valign="top">
    <td width="50%">
      <h1>STATUS</h1>
    </td>

    <td>
      <h1>RESOLUTION</h1>
    </td>
  </tr>

  <tr valign="top">
    <td>The <b>status</b> field indicates the general health of a 
    [% terms.bug %]. Only certain status transitions are allowed.</td>

    <td>The <b>resolution</b> field indicates what happened to this
    [% terms.bug %].</td>
  </tr>

  <tr valign="top">
    <td>
      <dl>
        <dt>
          <b>UNCONFIRMED</b>
        </dt>
        <dd>
          This [% terms.bug %] has recently been added to the database. 
          Nobody has validated that this [% terms.bug %] is true. Users
          who have the "canconfirm" permission set may confirm
          this [% terms.bug %], changing its state to NEW. Or, it may be
          directly resolved and marked RESOLVED.
        </dd>

        <dt>
          <b>NEW</b>
        </dt>
        <dd>
          This [% terms.bug %] has recently been added to the assignee's
          list of [% terms.bugs %] and must be processed. [% terms.Bugs %] in
          this state may be accepted, and become <b>ASSIGNED</b>, passed
          on to someone else, and remain <b>NEW</b>, or resolved and marked
          <b>RESOLVED</b>.
        </dd>

        <dt>
          <b>ASSIGNED</b>
        </dt>
        <dd>
          This [% terms.bug %] is not yet resolved, but is assigned to the 
          proper person. From here [% terms.bugs %] can be given to another 
          person and become <b>NEW</b>, or resolved and become <b>RESOLVED</b>.
        </dd>

        <dt>
          <b>REOPENED</b>
        </dt>
        <dd>
          This [% terms.bug %] was once resolved, but the resolution was 
          deemed incorrect. For example, a <b>WORKSFORME</b> [% terms.bug %] is
          <b>REOPENED</b> when more information shows up and
          the [% terms.bug %] is now reproducible. From here [% terms.bugs %] are
          either marked <b>ASSIGNED</b> or <b>RESOLVED</b>.
        </dd>
      </dl>
    </td>

    <td>
      <dl>
        <dd>
          No resolution yet. All [% terms.bugs %] which are in one of 
          these "open" states have the resolution set to blank. All 
          other [% terms.bugs %] will be marked with one of the following 
          resolutions.
        </dd>
      </dl>
    </td>
  </tr>

  <tr valign="top">
    <td>
      <dl>
        <dt>
          <b>RESOLVED</b>
        </dt>
        <dd>
          A resolution has been taken, and it is awaiting verification by
          QA. From here [% terms.bugs %] are either re-opened and become 
          <b>REOPENED</b>, are marked <b>VERIFIED</b>, or are closed for
          good and marked <b>CLOSED</b>.
        </dd>

        <dt>
          <b>VERIFIED</b>
        </dt>
        <dd>
          QA has looked at the [% terms.bug %] and the resolution and 
          agrees that the appropriate resolution has been taken. [% terms.Bugs %] remain
          in this state until the product they were reported
          against actually ships, at which point they become
          <b>CLOSED</b>.
        </dd>

        <dt>
          <b>CLOSED</b>
        </dt>
        <dd>
          The [% terms.bug %] is considered dead, the resolution is correct. 
          Any zombie [% terms.bugs %] who choose to walk the earth again must 
          do so by becoming <b>REOPENED</b>.
        </dd>
      </dl>
    </td>

    <td>
      <dl>
        <dt>
          <b>FIXED</b>
        </dt>
        <dd>
          A fix for this [% terms.bug %] is checked into the tree and 
          tested.
        </dd>

        <dt>
          <b>INVALID</b>
        </dt>
        <dd>
          The problem described is not [% terms.abug %].
        </dd>

        <dt>
          <b>WONTFIX</b>
        </dt>
        <dd>
          The problem described is [% terms.abug %] which will never be 
          fixed.
        </dd>

        <dt>
         <b>DUPLICATE</b>
        </dt>
        <dd>
          The problem is a duplicate of an existing [% terms.bug %].
          Marking [% terms.abug %] duplicate requires the [% terms.bug %]#
          of the duplicating [% terms.bug %] and will at least put
          that [% terms.bug %] number in the description field.
        </dd>

        <dt>
          <b>WORKSFORME</b>
        </dt>
        <dd>
          All attempts at reproducing this [% terms.bug %] were futile, 
          and reading the code produces no clues as to why the described
          behavior would occur. If more information appears later,
          the [% terms.bug %] can be reopened.
        </dd>

        <dt>
          <b>MOVED</b>
        </dt>
        <dd>
          The problem was specific to a related product 
          whose [% terms.bugs %] are tracked in
          another [% terms.bug %] database.
          The [% terms.bug %] has been moved to that database.
        </dd>
      </dl>
    </td>
  </tr>
</table>

<h2><a name="bug_severity">Severity</a></h2>
This field describes the impact of [% terms.abug %]. 

<table>
  <tr>
    <th>Blocker</th>

    <td>Blocks development and/or testing work</td>
  </tr>

  <tr>
    <th>Critical</th>

    <td>crashes, loss of data, severe memory leak</td>
  </tr>

  <tr>
    <th>Major</th>

    <td>major loss of function</td>
  </tr>

  <tr>
    <th>Minor</th>

    <td>minor loss of function, or other problem where easy
    workaround is present</td>
  </tr>

  <tr>
    <th>Trivial</th>

    <td>cosmetic problem like misspelled words or misaligned
    text</td>
  </tr>

  <tr>
    <th>Enhancement</th>

    <td>Request for enhancement</td>
</table>

<h2><a name="priority">Priority</a></h2>
This field describes the importance and order in which [% terms.abug %]
should be fixed. This field is utilized by the
programmers/engineers to prioritize their work to be done. The
available priorities range from <b>P1</b> (most important) to 
<b>P5</b> (least important.) 


<h2><a name="rep_platform">Platform</a></h2>
This is the hardware platform against which the [% terms.bug %] was
reported. Legal platforms include: 

<ul>
  <li>All (happens on all platforms; cross-platform [% terms.bug %])</li>

  <li>Macintosh</li>

  <li>PC</li>

  <li>Sun</li>

  <li>HP</li>
</ul>
<b>Note:</b> When searching, selecting the option "All" does not 
select [% terms.bugs %]
assigned against any platform. It merely selects [% terms.bugs %] that are
marked as occurring on all platforms, i.e. are designated "All". 

<h2><a name="op_sys">Operating System</a></h2>
This is the operating system against which the [% terms.bug %] was
reported. Legal operating systems include: 

<ul>
  <li>All (happens on all operating systems; cross-platform
  [% terms.bug %])</li>

  <li>Windows 95</li>

  <li>Mac System 8.0</li>

  <li>Linux</li>
</ul>
Sometimes the operating system implies the platform, but not
always. For example, Linux can run on PC and Macintosh and
others. 

<h2><a name="assigned_to">Assigned To</a></h2>

<p>
This is the person in charge of resolving the [% terms.bug %]. Every time
this field changes, the status changes to <b>NEW</b> to make it
easy to see which new [% terms.bugs %] have appeared on a person's list.</p>

<p>
The default status for queries is set to NEW, ASSIGNED and
REOPENED. When searching for [% terms.bugs %] that have been resolved or
verified, remember to set the status field appropriately. 
</p>

[% INCLUDE global/footer.html.tmpl %]