www/project_issues.html

<!-- 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" tabindex="1">
    <input name="id" size="6" tabindex="2" />
    <input type="submit" value="Jump to issue" tabindex="3" />
    </form>
   </td>
  </tr>
 </table>
 


<h1>Subversion Issue Tracker</h1>

<h2>Issue Tracker Guidelines</h2>

<p>As Subversion continues to mature, and as it gains attention from
   new users, folks will inevitably find bugs in, or come up with
   enhancements that they would like to see made to, the software.
   The Subversion community welcomes such requests for enhancements
   and reports of bugs.  However, we ask that you follow a few
   guidelines with respect to the issue filing process.</p>

<div class="alert" style="color: red; font-weight: bold">
<p>Before filing an issue in the Issue Tracker, please:</p>

<ul>
  <li>Look through the <a
      href="http://subversion.tigris.org/issues/buglist.cgi?component=subversion&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED">existing
      issues</a> to determine if your concern has already been noted by
      someone else.</li>
  <li>Make sure that you've read the appropriate documentation (for
      example, the <a href="http://svnbook.red-bean.com/">Subversion
      book</a>) to verify that you are using the software
      appropriately, and to determine if any problems you are seeing are
      perhaps not real bugs.</li>
  <li>Send email to the users list (<a
      href="mailto:users@subversion.tigris.org">users@subversion.tigris.org</a>)      or development list (<a
      href="mailto:dev@subversion.tigris.org">dev@subversion.tigris.org</a>)
      fully describing the enhancement or bug that brought you here
      today.  That will give the community a chance to ask questions
      of you, so that we can fully understand your concern.</li>

</ul>
</div>

<p>When mailing the development 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>

<p>After mailing the development list, you should expect your concern
   to be addressed with relative immediacy.  That is, within a few
   days, you should get feedback on your mail.  If indeed you have
   found a new bug in Subversion, or if your enhancement request is
   feasible, you will likely be asked to return here and file a new
   issue in the Issue Tracker.</p>

<p>When you file the issue, don't forget to include links to the
   relevant mailing list threads.  Those are important context for
   anyone reading the issue, and their 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 discussion). </p>

<h2>What the Fields Mean</h2>

<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>

<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>

<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>"!

<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>