www/project_issues.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<style type="text/css"> /* <![CDATA[ */
  @import "tigris-branding/css/tigris.css";
  @import "tigris-branding/css/inst.css";
  /* ]]> */</style>
<link rel="stylesheet" type="text/css" media="print"
  href="tigris-branding/css/print.css"/>
<script type="text/javascript" src="tigris-branding/scripts/tigris.js"></script>
<title>Subversion Issue Tracker</title>
</head>

<body>
<div class="app">

<div class="h2">
<h2>Subversion Issue Tracker</h2>

<!-- jump to issue form: -->
 <table border="0" cellspacing="0" cellpadding="3">
  <tr>

   <td id="issueid">
    <form method="get" action="http://subversion.tigris.org/issues/show_bug.cgi">
     <div>
      <input name="id" size="6" />
      <input type="submit" value="Jump to issue" />
     </div>
    </form>
   </td>
  </tr>
 </table>
 
<div class="h3" id="guidelines" title="guidelines">
<h3>Issue Tracker Guidelines</h3>

<div style="color: black; font-size: 130%; font-weight: bold; background-color: #ff5">

<p style="font-size: 200%; color: red; text-align: center">
Before filing a new issue, please:
</p>

<ul>

  <li><p>Re-read the documentation<br />
      <span style="font-size: 75%; font-weight: normal">
      (especially the <a href="faq.html">FAQ</a> and the
      online <a href="http://svnbook.red-bean.com/"
      >Subversion book</a>).</span></p></li>

  <li><p>Look through <a
      href="http://subversion.tigris.org/issues/buglist.cgi?component=subversion&amp;issue_status=UNCONFIRMED&amp;issue_status=NEW&amp;issue_status=STARTED&amp;issue_status=REOPENED"
      >all existing issues</a>, or search their summaries:</p>
      <form method="get"
        action="http://subversion.tigris.org/issues/buglist.cgi"><div>
      <input name="short_desc" />
      <input type="submit" value="Search!" />
      <input type="hidden" name="component" value="subversion" />
      <input type="hidden" name="issue_status" value="NEW" />
      <input type="hidden" name="issue_status" value="STARTED" />
      <input type="hidden" name="issue_status" value="REOPENED" />
      <input type="hidden" name="short_desc_type" value="substring" />
      <input type="hidden" name="cmdtype" value="doit" />
      </div></form>
      <p style="font-size: 75%; font-weight: normal">
      to see if this bug has already been reported.</p></li>

  <li><p>Report your problem to <a href="mailto:users@subversion.tigris.org"
      >users@subversion.tigris.org</a>,<br /> <span style="font-size:
      75%; font-weight: normal"> describing the bug or feature request
      that you were about to file.  People there will ask you
      questions and help get the bug report into a useful form, after
      verifying that a new issue is appropriate.  (See <a
      href="http://svn.collab.net/repos/svn/trunk/BUGS"
      >http://svn.collab.net/repos/svn/trunk/BUGS</a> for how to write
      a useful bug report.) If you do file an issue, remember to
      include a link to the relevant mailing list message(s) or
      thread.  That's important context for anyone reading the issue,
      and its presence also confirms that the issue <i>has</i> already
      been discussed on the mailing list.  Otherwise, the issue may
      get accidentally closed because no one can tell that it is the
      product of a list discussion.</span></p></li>

</ul>

<p>We depend on the mailing list as a first level of filtering for our
bug tracker.  Without it, the tracker would be full of duplicate
issues, non-issues, and unreproducible issues.  Please help us keep
the bug database clean, by always posting to the list first!</p>

</div>

<p>When mailing the list with a concern, make sure that your e-mail
   describes your bug or enhancement fully.  Provide details about the
   versions of the relevant software (Subversion, Apache, neon, etc.)
   that you are using, about your operating system, and about any
   other thing that might seem pertinent to the issue.  If you can
   provide a script which consistently reproduces a problem, that can
   be incredibly helpful to those evaluating and/or working on your
   issue.</p>

</div>

<div class="h3" id="write-access" title="write-access">
<h3>Filing New Issues, Modifying Existing Issues</h3>

<p>You must be logged in to the web site to add a new issue, and you must
be logged in with the <em>Observer</em> role in the Subversion project
to modify an existing issue&nbsp;&mdash;&nbsp;even one that you
created yourself.</p>

<p>Here's how to acquire the <em>Observer</em> role:</p>

<ol>
  <li>Log in on the tigris.org site</li>
  <li>Go to the Subversion project front page</li>
  <li>Click on the <em>Request project role</em> link directly below the
    &quot;Project Home&quot; line</li>
  <li>Request the <em>Observer</em> role</li>
  <li>Wait for the confirmation e-mail</li>
</ol>

</div>

<div class="h3" id="fields" title="fields">
<h3>What the Issue Fields Mean</h3>

<p>When an issue is first filed, it automatically goes in the
<b>"---"</b> target milestone, which indicates that the issue has not
yet been processed.  A developer will examine it and maybe talk to
other developers, then estimate the bug's severity, the effort
required to fix it, and schedule it in a numbered milestone, for
example <b><a
href="http://subversion.tigris.org/issues/buglist.cgi?target_milestone=1.1"
>1.1</a></b>.  (Or they may put it the <b><a
href="http://subversion.tigris.org/issues/buglist.cgi?target_milestone=unscheduled"
>unscheduled</a></b> or <b><a
href="http://subversion.tigris.org/issues/buglist.cgi?target_milestone=nonblocking"
>nonblocking</a></b> milestone, if they consider it tolerable for all
currently planned releases.)  </p>

<p> An issue filed in <b>unscheduled</b> might still get fixed soon,
if some committer decides they want it done.  Putting it in
<b>unscheduled</b> merely means it hasn't been scheduled for any
particular release yet.  The <b>nonblocking</b> milestone, on the
other hand, means that we do not anticipate ever scheduling the issue
for a particular release.  This also does not mean the issue will
never be fixed; it merely means that we don't plan to block any
release on it.</p>

<p>
Severity is represented in the <b>Priority</b> field.  Here is how
priority numbers map to severity:
</p>

<ul>

   <li><b>P1:</b> <i>Prevents work from getting done, causes data
         loss, or BFI ("Bad First Impression" -- too embarrassing for
         a 1.0 release).</i>
   </li>

   <li><b>P2:</b> <i>Workaround required to get stuff done.</i>
   </li>

   <li><b>P3:</b> <i>Like P2, but rarely encountered in normal usage.</i>
   </li>

   <li><b>P4:</b> <i>Developer concern only, API stability or
         cleanliness issue.</i>
   </li>

   <li><b>P5:</b> <i>Nice to fix, but in a pinch we could live with it.</i>
   </li>

</ul>

<p>
Effort Required is represented in the <b>Status Whiteboard</b> with an
"<b>e number</b>", which is the average of the most optimistic and
most pessimistic projections for number of engineer/days needed to
fix the bug.  The e number always comes first, so we can sort on the
field, but we include the actual spread after it, so we know when
we're dealing with a wide range.  For example
"<b>e2.5&nbsp;(2&nbsp;/&nbsp;3)</b>" is not quite the same as 
"<b>e2.5&nbsp;(1&nbsp;/&nbsp;4)</b>"!</p>

</div>

</div>

<div class="h2" id="enter" title="enter">
<h2>Enter the Issue Tracker</h2>

<p>And so, with further ado, we give you (drumroll&hellip;) the
   Subversion <a 
   href="http://subversion.tigris.org/servlets/ProjectIssues">Issue
   Tracker</a>.</p>

<p><i>Again, remember that to add or modify issues, you must be <a
href="#write-access">logged into the website</a>.</i></p>

</div>

</div>
</body>
</html>