Please allow for bugs to be proposed to a milestone and a series

On Tue, Sep 11, 2007 at 10:24:13PM -0000, Joey Stanford wrote:
> Please allow bugs to be proposed to a particular milestone, reusing if
> possible the code from Blueprints's propose to series.

I think it would make more sesnse to re-use the code from Bug's propose
to series. :)

If we need to propose things to be fixed, maybe we should try using
series instead, though? Milestones are supposed to be lightweight, so I
don't think we should make them more heavyweight, with proposals, like
series.

Oh, and I now noticed that the summary mentions that it should be able to propose bugs to be fixed in a series. I assume you didn't know this functionality already existed?

Reusing code from Bug's is certainly good. I was indicating blueprints because that is the flow I would like us to follow.

e.g.

1) user runs across a bug that they want to have fixed in the next release (milestone or series)

2) user selects the "propose for milestone" or "propose for release" buttons

3) bug is now marked at proposed for the milestone or series

4) project owner/project manager/team lead reviews the proposed bugs for the upcoming milestone and series and approves or rejects the proposed bugs
 * accepted bugs are targeted for the milestone/release
 * rejected bugs remove the proposal in formation (i.e. go back into a state prior to someone proposing them).

I can see an instance where a bug is targeted to 1.1.12 but is proposed for 1.1.10. Should the proposal be accepted, the bug is updated to reflect 1.1.10. Should the proposal be rejected, the existing target is kept.

I still would like this as a medium priority please.

On Wed, Sep 12, 2007 at 02:25:53PM -0000, Joey Stanford wrote:
> Reusing code from Bug's is certainly good. I was indicating blueprints
> because that is the flow I would like us to follow.
>
> e.g.
>
> 1) user runs across a bug that they want to have fixed in the next
> release (milestone or series)
>
> 2) user selects the "propose for milestone" or "propose for release"
> buttons
>
> 3) bug is now marked at proposed for the milestone or series
>
> 4) project owner/project manager/team lead reviews the proposed bugs for the upcoming milestone and series and approves or rejects the proposed bugs
> * accepted bugs are targeted for the milestone/release
> * rejected bugs remove the proposal in formation (i.e. go back into a state prior to someone proposing them).

What are we hoping to gain by allowing nominations for milestones?
Personally I think it would create more work for the one that has to
review the milestone nominations. Of course people want to have their
bugs fixes as soon as possible, won't they?

> I can see an instance where a bug is targeted to 1.1.12 but is proposed
> for 1.1.10. Should the proposal be accepted, the bug is updated to
> reflect 1.1.10. Should the proposal be rejected, the existing target is
> kept.

Who proposes, and for what reason is the bug proposed to be fixed for an
earlier milestone?

> I still would like this as a medium priority please.

I'd rather wait prioritizing the bug until I know the reasons for this
functionality. I marked the bug as Incomplete, since I'm not convinced
this is a real bug that should be fixed, and Incomplete bugs shouldn't
have an importance set.

I'd also be interested in if your use case would be fulfilled by us
using series instead of milestones? It sounds like you want milestones
to work like series do, which kind of defeats the purpose of being able
to use both milestones and series to target bugs to.

Oh btw, afaik, blueprints can't be proposed to milestones, can they? To me Blueprints and Bugs work practially the same when it comes to milestone and series, so I don't understand what you want us to take from the Blueprint workflow. The workflow you proposed is more or less exactly how bug nominations work today for series.

> What are we hoping to gain by allowing nominations for milestones?
> Personally I think it would create more work for the one that has to
> review the milestone nominations. Of course people want to have their
> bugs fixes as soon as possible, won't they?

This is true but the use will vary by project.

In Launchpad's case, I'd like to propose two or three bugs to each
group for each cycle. So, instead of me trading emails and such I
could propose a small number that are important for various reasons.

Additionally, instead of assigning a bug to a cycle several releases
out, a team member could simply propose it for then.

> > I can see an instance where a bug is targeted to 1.1.12 but is proposed
> > for 1.1.10. Should the proposal be accepted, the bug is updated to
> > reflect 1.1.10. Should the proposal be rejected, the existing target is
> > kept.
>
> Who proposes, and for what reason is the bug proposed to be fixed for an
> earlier milestone?

Anyone can propose (although for launchpad it would be nice to
restrict this to the development team).

For prosing for an earlier milestone: My team lead has said I need to
work on a bug for 1.1.12 however I think I can fit it into 1.1.10. So,
I'll propose it for 1.1.10 and during my review with my team lead he
can approve or deny it. This is most certainly an edge case and I'm
happy to cede this request if it's more than a small bit of work.

> I'd also be interested in if your use case would be fulfilled by us
> using series instead of milestones? It sounds like you want milestones
> to work like series do, which kind of defeats the purpose of being able
> to use both milestones and series to target bugs to.

The answer to this is a bit complicated for us. For others, not so sure.

We designed the release process to originally use series but series
lacked the functionality we needed so Kiko and I agreed to use
milestones instead and improve the series functionality over the
course of the year. There are still several things missing from
series that are found in Milestones. Ultimately how a project
manages, via series or via milestones, is up to that product and we
should not force a particular path. This argument only applies to
milestones and series, not to other aspects of Launchpad.

On 9/12/07, Björn Tillenius <email address hidden> wrote:
> Oh btw, afaik, blueprints can't be proposed to milestones, can they?

Correct. They can only be proposed to a release. I believe this to be
a handycap for us today.

> To
> me Blueprints and Bugs work practically the same when it comes to
> milestone and series, so I don't understand what you want us to take
> from the Blueprint workflow. The workflow you proposed is more or less
> exactly how bug nominations work today for series.

I can agree to this. My point about series missing features is still
valid and so perhaps we should fix that.

e.g. Compare

Series: https://edge.launchpad.net/malone/1.1
Milestones: https://edge.launchpad.net/malone/+milestone/1.1.9

Also, I was unable to find propose for a release but I was able to
target for a release just as we target for a milestone. Can you give
me the relevant URL for this bug please? Thanks.

On Wed, Sep 12, 2007 at 03:56:58PM -0000, Joey Stanford wrote:
> > I'd also be interested in if your use case would be fulfilled by us
> > using series instead of milestones? It sounds like you want milestones
> > to work like series do, which kind of defeats the purpose of being able
> > to use both milestones and series to target bugs to.
>
> The answer to this is a bit complicated for us. For others, not so sure.
>
> We designed the release process to originally use series but series
> lacked the functionality we needed so Kiko and I agreed to use
> milestones instead and improve the series functionality over the
> course of the year. There are still several things missing from
> series that are found in Milestones. Ultimately how a project
> manages, via series or via milestones, is up to that product and we
> should not force a particular path. This argument only applies to
> milestones and series, not to other aspects of Launchpad.

So, reading this I think we should put our effort into improving how
series work, instead of trying to make milestones more like series. I
think this is a subject we should discuss at the next LP meeting in
Boston; I don't think it's entirely clear how milestones and series
should work.

> So, reading this I think we should put our effort into improving how
> series work, instead of trying to make milestones more like series. I
> think this is a subject we should discuss at the next LP meeting in
> Boston; I don't think it's entirely clear how milestones and series
> should work.

Added to https://launchpad.canonical.com/ReleaseCycles/improvement
although this will have a wider impact than just us.

On Wed, Sep 12, 2007 at 04:03:14PM -0000, Joey Stanford wrote:
> I can agree to this. My point about series missing features is still
> valid and so perhaps we should fix that.

Yes, I certainly agree.

> Also, I was unable to find propose for a release but I was able to
> target for a release just as we target for a milestone. Can you give
> me the relevant URL for this bug please? Thanks.

Well, this is also something we copied from Blueprints. If you have
permission to approve a nomination, you can't nominate a bug for a
release. The only difference from Blueprints is that we change the label
from "propose" to "target". In Blueprints the label stays the same, so
it says that you propose a blueprint, even though the blueprint will in
fact be targeted to that release.

There is a proposal from mpt on how to restructure Launchpad which includes addressing this problem. It has not yet been agreed upon by upper manager though, to the best of my knowledge.

That proposal is in bug 174468. Joey, perhaps you could raise it this week.

I'm closing this bug, since it's unclear what it is about. This is too big of an issue to discuss in a bug report.