Proposal for target milestones

[Damien]

inline comments about how those fields are used in places I know about...


On Mon, Sep 1, 2014 at 5:43 PM, Mark Côté <mcote at bugzilla.org> wrote:

> At last Wednesday's Bugzilla meeting, when discussing remaining
> blockers for Bugzilla 5.0, we discussed how we flag bugs for inclusion
> into a given release.  At the moment, we use both the Target Milestone
> and the whiteboard for this purpose.
>
> The Target Milestone currently serves two purposes: flagging bugs we
> think would be nice to include in a given release (the next one or a
> future one), and flagging bugs that have been fixed (but not necessarily
> flagged ahead of time) and will be included in the next version.  The
> white board tag, e.g. [Roadmap: 5.0], is used to denote bugs that we
> think *really* should be in that release.
>

Are we making assumptions there? What if a team wants to follow agile
processes?
Would that become a tedious activity?


>
> This system may have worked well in the past, but in our current
> development process, where we have a stable product and a small pool of
> contributors, it's essentially backwards.  Since the number of new
> features is relatively low, at least compared with earlier Bugzilla
> versions, we are moving to a model in which we ship whatever we have
> every 6 months or so, or if there's a really big or useful feature that
> we want to get out.  Development of the latter tends to come from
> features that are needed in site installations, such as Red Hat's or
> Mozilla's.  Other commits tend to be smaller bug fixes that volunteers
> sporadically contribute.  We end up with lots and lots of Target
> Milestones that have no reasonable chance of being resolved and just get
> moved from version to version after each release.
>

agile: everything goes in the "backlog", "backlog" would be an interesting
value to add to your target milestones.


>
> Thus I propose that our policy for using the Target Milestone be as
> follows:
>
> * Bugs that are being actively worked on and are anticipated to be
> finished before the next release, as well as bugs officially designated
> as blockers, should have the Target Milestone set, and only to the next
> anticipated release.
>

agile: they would be in "backlog" to begin with, and if somebody is working
on
them, then let's assume product owner moved them to the release backlog or
sprint backlog.


> * Only the bug's assignee or a Bugzilla reviewer/approver should set or
> unset the Target Milestone.
>

agile: only the product owner would do that. new bugs go to the backlog.
... I lie, we need to distinguish bugs from features. if the bug is
introduced
based on some other bug getting worked on, then that would belong to
the same sprint. Maybe if you are not product owner, your choices get
restricted to either current sprint or backlog.


>
> * As we currently do, bugs without a Target Milestone that are committed
> before an upcoming release should set it after the patch is committed.
>

This is making the assumption that people work on what they want to work on
rather than on what they have been appointed to work on. Not all processes
are like that. It's okay for you to say it should be one way or another for
bmo, but for users out there, please consider that it is not the only
workflow.

If you have a milestone "current sprint" or "current", you can always rename
that when you branch the code or change versions. Is target milestone
normalized?


>
> * We will stop using the [Roadmap: X] white board tag.
>
> Everyone at the meeting was in agreement, but I want to turn it over to
> the forum for any discussion before making it official.
>
> Mark
> --
> Mark Côté
> Assistant Project Lead, Bugzilla
> _______________________________________________
> dev-apps-bugzilla mailing list
> dev-apps-bugzilla at lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20140902/f16bbbfd/attachment.html>