Hi Charlie.
My answer is not specific to your question since I have been asked this many
times. You can scan the what follows. I think you care about my final
conclusions.
On Fri, 2009-12-04 at 16:20 -0800, Charlie Poole wrote:
> Hi All,
>
> Launchpad is great in providing lots of options for how to do things,
> but sometimes it's hard to decide which way to go.
>
> I'd particularly like to hear what people think about targeting bugs
> to milestones versus to series - or doing both. What are the factors
> going into such a decision? What have different projects done?
How bugs are targeted is largely determined what you need to plan, and how
the work is supported when the goal is complete. You can answer the question
for yourself by exploring three axis that represent the destination, the
journey, and continuity. I think most projects favour one side of each axis,
but will always use the other side when needed.
* Destination: Leading or trailing series?
* A trailing series is created *after* the work is completed.
* The focus of development is always the same series: trunk, head
master, main, etc.
* The trailing series marks a interesting point in development.
* The trailing series is often a supported release that will get
backports and bug fixes while main development happen in trunk.
* This approach is common for small projects or project tied to a
non-distributed repository.
* Bugs and features are never targeted to a series.
* A leading series is created *before* the work is complete.
* The leading series has a set of features and fixes it intends to
complete.
* The leading series is the focus of development.
* Previous series are supported or obsolete...
* Except for experimental series, which are concurrent with the
series that is the focus of development.
* This approach is more common in large projects or projects that
use a distributed repository.
* Bugs and features are may be targeted to a series.
* Journey: Time-directed or feature-directed milestones?
* A time-directed milestone restricts development by time.
* The milestone is complete when the date is reached.
* Time-directed milestones are by their nature, the series; work
happens in one milestone at a time.
* Work is focused on the current milestone.
* Incomplete work is moved to another milestone or untargeted when
the milestone's date is reached.
* If a bug is fixed from a another milestone, it is targeted to the
current milestone.
* Time-directed milestones emphasises cadence; delivering value to
stakeholders at regular intervals.
* Time-directed milestones requires more commitment from the
developers to deliver work on schedule.
* A feature-directed milestone restricts development to a feature.
* The milestone is complete when the feature is complete; there is
no expected completion date.
* A series may have several feature milestones working in parallel.
* Feature-directed milestones allow multiple developers/teams to work
independent or each other (models real behaviour).
* Feature-directed milestones are harder to manage since the manager
(and hopefully not the team or developer) must change focus often.
* Continuity: Continuous or discrete goals?
* Continuous goals are project goals to exist beyond the life of a
series.
* Incomplete features and fixes for a series become the goals of the
next series.
* The priority of fixes and features do not necessarily change from
one series to the next.
* Trailing series development encourages continuous goals.
* Discrete goals belong to the series and they are not important after
the series.
* Incomplete features and fixes are untargeted.
* The incomplete features and fixes must re-evaluated for the next
development series.
* The priority of each bug or feature will change because the goals
of the new series changes.
* Leading series development encourages discrete goals.
That said, I think Launchpad has two separate implementations for planning
that do not interact well. Series and milestones are devices to plan work
and they depend on each other, but they seem to be in conflict in Launchpad.
I tried and abandoned using series because I cannot fix mistakes
* I cannot untarget a bug from a series.
Targeting created a bugtask and that cannot be deleted! You can mark
The series bugtask as invalid, but still clutters the interface.
* This is incompatible with continuous goals.
* I cannot move a bug between a series and milestone.
As I revise my plans, I need to move bugs from
* Targeting to series and milestones happen in separate places, and
milestones are much easier that series.
* Series reporting appears to be broken.
Viewing the bugs for a series does not show me the bugs targeted to
the series' milestones. The milestone is just a subset of the series.
If I move a milestone to another series, I know I am also moving
the targeted bugs to that series.
* I cannot target a two milestones that belong to the development and
supported series.
My recommendation that works for most models is to ignore the implementation
details of destination and journey and use milestones to do both.
* You are free to use leading or trailing series.
* Use feature-directed milestones to represent the goals of the series.
* They are commonly named 'future' or 'horizon', but naming it after
the series is most clear to users: 'Series3.1'
* Use time-directed milestones to represent cadence and to target work
that really has a date to complete.
* Create a milestone that represent dates that features and fixes must
be committed to the code base by.
* Create a milestone for each development release you plan.
* Move fixes and features from the series milestone to other milestones.
* Move low priority items to the current milestone only when you are
certain the work will be completed.
* Move high priority items to other milestones when developers will
commit to meeting the dates.
* Use feature-directed milestones to when you need to work in parallel.
* You are free to move them to other series if you wish.
* If your goals are continuous, when a development series is complete
rename the series milestone to the new series name.
* If you are using leading series, move the milestone to the new series.
* Use series targeting to plan backports to supported series.
* Refrain from targeting to a supported series until you are certain
when the work will be complete in the development series.
--
__Curtis C. Hovey_________
http://launchpad.net/
Attachment:
signature.asc
Description: This is a digitally signed message part
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)