launchpad-users team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On Sat, 2009-07-04 at 17:10 -0400, Dan MacNeil wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> We're thinking of ditching the blueprints and moving our 17 blueprints
> to the bug tracker.
> 
> As near as I can tell
> 
> Blueprints can do these things that bugs can't.
> 
>    1) distignish between Dafter/approver/implementor
> 
>    2) create a pretty dependency graph to other
>       blueprints
> 
>    3) Mark blueprint as related to a bug
> 
>    4) (somehow?) be used for project management
> 
> Bugs can do these things blueprints can't
> 
>   1) be managed/updated via email
>   2) be tagged
> 
> Bug advantage #1 is huge as far as time savings go.
> 
> Blueprint advantages 1-2 aren't important to us. #2 and #3 can be
> largely be accomplished by mentioning related bugs numbers/urls in the
> narrative.

I would think that the blueprint approver and the series driver (release
manager) should be the same person because the driver is responsible for
targeting the bug or blueprint to a milestone that it can be completed
in.

The blueprint implementer is the same as the bug assignee

So the drafter is what is unique about the blueprint. The person who
drafts the blueprint probably needs to be in contact with the driver and
assignee, because unless they agree on scope, the blueprint will never
be implemented.

> #4 is something I've not figured out.

Both blueprints and bugs can be targeted to a series milestone. You can
see a summary of their progress on the series page and the milestone
page.

> For even moderately detailed specifications, Blueprints are not nearly
> as easy to use as a text file or word processing document checked into
> version.
> 
> The lack of email support ---apparently even x-message-rationale means
> that blueprints can't even be sorted / filtered.
> 
> Launchpad itself has only 9 blueprints and they don't seem to be active.

This is true, though you are looking at the wrong place. We create
blueprints in the sub-project. We have hundreds.
    https://blueprints.edge.launchpad.net/launchpad-project

Blueprints are not very agile, nor is it well suited for distributed
environments (as you noted about the email issues). We have experimented
with the story and saga approach with defining features.

    https://dev.launchpad.net/

When the blueprints source code is released. I will help contributors
fix it many bugs, and help it evolve into an agile tool.

> Ubuntu has hundreds and that group seems to use them. This is a good
> random example:
> 
> https://blueprints.launchpad.net/ubuntu/+spec/desktop-karmic-bug-workflow
> 
> However, I don't see how this couldn't have been done in the bug tracker
>  via an email conversation.
> 
> The biggest thing holding us back from moving our blueprints to the bug
> tracker is that it is nice to hope to have all bugs closed.

Indeed. I use bugs for small blueprints, and I am not happy with it.

> Is there anyone on this list using blueprints happily, who would
> recommend against us (a small project) ditching blueprints?

Blueprint's email problems could be addresses in about 80 man hours. If
these are fixed in the next three months, will you regret the switch
from blueprints? If so I suggest you wait a few months to see if users
are willing to improve Blueprints.


-- 
__Curtis C. Hovey_________
http://launchpad.net/

Attachment: signature.asc
Description: This is a digitally signed message part