Thanks for writing it up; #milestones-open is a good text to link
users@ and issues@ queriers to.
cmpilato_at_apache.org wrote on Fri, May 13, 2011 at 14:57:05 -0000:
> Author: cmpilato
> Date: Fri May 13 14:57:04 2011
> New Revision: 1102775
>
> URL: http://svn.apache.org/viewvc?rev=1102775&view=rev
> Log:
> * site/publish/docs/community-guide/issues.part.html
> (milestones): New section describing how we interpret issue
> milestones in our tracker.
> (issue-triage): Minor tweaks to the process of triaging issues.
>
> Modified:
> subversion/site/publish/docs/community-guide/issues.part.html
>
> Modified: subversion/site/publish/docs/community-guide/issues.part.html
> URL: http://svn.apache.org/viewvc/subversion/site/publish/docs/community-guide/issues.part.html?rev=1102775&r1=1102774&r2=1102775&view=diff
> ==============================================================================
> --- subversion/site/publish/docs/community-guide/issues.part.html (original)
> +++ subversion/site/publish/docs/community-guide/issues.part.html Fri May 13 14:57:04 2011
> @@ -198,6 +198,128 @@ make the bug much more likely to get fix
> </div> <!-- bugs-where -->
>
>
> +<div class="h2" id="milestones">
> +<h2>Milestone Management
> + <a class="sectionlink" href="<!--#echo var="GUIDE_ISSUES_PAGE" -->#milestones"
> + title="Link to this section">¶</a>
> +</h2>
> +
> +<p>Issue tracker milestones are an important aspect of how the
> +Subversion developers organize their efforts and communicate with each
> +other and with the Subversion user base. With the exception of some
> +milestones used primarily when doing high-level
> +issue triage, the project's issue tracker
> +milestones tend to be named to reflect release version numbers and
> +variations thereof. Milestones are used for slightly different
> +purposes depending on the state of the issue, so it's important to
> +understand those distinctions.</p>
> +
> +<div class="h3" id="milestones-open">
> +<h3>Milestones for open issues
> + <a class="sectionlink" href="<!--#echo var="GUIDE_ISSUES_PAGE" -->#milestones-open"
> + title="Link to this section">¶</a>
> +</h3>
> +
> +<p>For open issues (those whose status is <tt>UNCONFIRMED</tt>,
> +<tt>NEW</tt>, <tt>STARTED</tt> or <tt>REOPENED</tt>), the milestone
> +indicates the Subversion release for which the developers are
> +targeting the resolution of that issue. In the general case, we use
> +milestones of the form <tt><em>VERSION</em>-consider</tt> to indicate
> +that the resolution of an issue is being considered as something we'd
> +like to release in <em>VERSION</em>. For example, a feature we think
> +we can and should add to Subversion 1.9 will get
> +a <tt>1.9-consider</tt> milestone. For obvious reasons, the accuracy
> +of these release targets gets increasingly worse the farther into the
> +future you look and, as such, users are encouraged to <em>not</em>
> +treat them as binding promises from the developer community.</p>
> +
> +<p>At any given time, there is work toward "the next big release"
> +happening in the community. As that release begins to take shape, the
> +developers will get a better feel for which issues are "must-haves"
> +for the release (also known as "release blockers"), which ones are
> +"nice-to-haves", and which ones should be deferred to a future release
> +altogether. Issue milestones are the mechanism used to carry the
> +results of those decisions. An issue that is deemed to be a release
> +blocker will be moved from the <tt><em>VERSION</em>-consider</tt>
> +milestone to the <tt><em>VERSION</em></tt> milestone;
> +"nice-to-haves" will be left with
> +the <tt><em>VERSION</em>-consider</tt> milestone; and issues deferred
> +from the release will be re-milestoned either
> +with <tt><em>ANOTHERVERSION</em>-consider</tt>
> +or <tt>unscheduled</tt>, depending on whether we have a clear guess as
> +to when the issue will be addressed.</p>
> +
> +<p>Continuing the previous example, as development on Subversion
> +1.9.0-to-be progresses, developers will be evaluating that feature we
> +planned for the release. If we believe that Subversion 1.9 should not
> +be released without that feature, we'll change its milestone
> +from <tt>1.9-consider</tt> to <tt>1.9.0</tt>; if we hope to release
> +with that feature but don't want to commit to it, we'll leave the
> +milestone as <tt>1.9-consider</tt>; and if we know good and well we
> +aren't going to get around to implementing the feature in the 1.9.x
> +release series, we'll re-milestone the issue to something else
> +(<tt>1.10-consider</tt>, perhaps).</p>
> +
> +<p>The accuracy of the <tt><em>VERSION</em></tt> milestone is very
> +important, as developers tend to use those issues to focus their
> +efforts in the final days of a major release cycle.</p>
> +
> +</div> <!-- milestones-open -->
Received on 2011-05-14 02:52:50 CEST