<div dir="ltr">inline comments about how those fields are used in places I know about...<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 1, 2014 at 5:43 PM, Mark Côté <span dir="ltr"><<a href="mailto:mcote@bugzilla.org" target="_blank">mcote@bugzilla.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">At last Wednesday's Bugzilla meeting, when discussing remaining<br>
blockers for Bugzilla 5.0, we discussed how we flag bugs for inclusion<br>
into a given release.  At the moment, we use both the Target Milestone<br>
and the whiteboard for this purpose.<br>
<br>
The Target Milestone currently serves two purposes: flagging bugs we<br>
think would be nice to include in a given release (the next one or a<br>
future one), and flagging bugs that have been fixed (but not necessarily<br>
flagged ahead of time) and will be included in the next version.  The<br>
white board tag, e.g. [Roadmap: 5.0], is used to denote bugs that we<br>
think *really* should be in that release.<br></blockquote><div><br></div><div>Are we making assumptions there? What if a team wants to follow agile processes?</div><div>Would that become a tedious activity?</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This system may have worked well in the past, but in our current<br>
development process, where we have a stable product and a small pool of<br>
contributors, it's essentially backwards.  Since the number of new<br>
features is relatively low, at least compared with earlier Bugzilla<br>
versions, we are moving to a model in which we ship whatever we have<br>
every 6 months or so, or if there's a really big or useful feature that<br>
we want to get out.  Development of the latter tends to come from<br>
features that are needed in site installations, such as Red Hat's or<br>
Mozilla's.  Other commits tend to be smaller bug fixes that volunteers<br>
sporadically contribute.  We end up with lots and lots of Target<br>
Milestones that have no reasonable chance of being resolved and just get<br>
moved from version to version after each release.<br></blockquote><div><br></div><div>agile: everything goes in the "backlog", "backlog" would be an interesting</div><div>value to add to your target milestones.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thus I propose that our policy for using the Target Milestone be as follows:<br>
<br>
* Bugs that are being actively worked on and are anticipated to be<br>
finished before the next release, as well as bugs officially designated<br>
as blockers, should have the Target Milestone set, and only to the next<br>
anticipated release.<br></blockquote><div><br></div><div>agile: they would be in "backlog" to begin with, and if somebody is working on</div><div>them, then let's assume product owner moved them to the release backlog or</div>
<div>sprint backlog.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* Only the bug's assignee or a Bugzilla reviewer/approver should set or<br>
unset the Target Milestone.<br></blockquote><div><br></div><div>agile: only the product owner would do that. new bugs go to the backlog.</div><div>... I lie, we need to distinguish bugs from features. if the bug is introduced</div>
<div>based on some other bug getting worked on, then that would belong to</div><div>the same sprint. Maybe if you are not product owner, your choices get</div><div>restricted to either current sprint or backlog.</div><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* As we currently do, bugs without a Target Milestone that are committed<br>
before an upcoming release should set it after the patch is committed.<br></blockquote><div><br></div><div>This is making the assumption that people work on what they want to work on</div><div>rather than on what they have been appointed to work on. Not all processes</div>
<div>are like that. It's okay for you to say it should be one way or another for</div><div>bmo, but for users out there, please consider that it is not the only workflow.</div><div><br></div><div>If you have a milestone "current sprint" or "current", you can always rename</div>
<div>that when you branch the code or change versions. Is target milestone</div><div>normalized?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* We will stop using the [Roadmap: X] white board tag.<br>
<br>
Everyone at the meeting was in agreement, but I want to turn it over to<br>
the forum for any discussion before making it official.<br>
<span class="HOEnZb"><font color="#888888"><br>
Mark<br>
--<br>
Mark Côté<br>
Assistant Project Lead, Bugzilla<br>
_______________________________________________<br>
dev-apps-bugzilla mailing list<br>
<a href="mailto:dev-apps-bugzilla@lists.mozilla.org">dev-apps-bugzilla@lists.mozilla.org</a><br>
<a href="https://lists.mozilla.org/listinfo/dev-apps-bugzilla" target="_blank">https://lists.mozilla.org/listinfo/dev-apps-bugzilla</a><br>
-<br>
To view or change your list settings, click here:<br>
<<a href="http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT" target="_blank">http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT</a>><br>
</font></span></blockquote></div><br></div></div>