Open Stack

> -----Original Message-----
> From: Todd Willey
> Sent: 28 March 2011 21:11
> To: Jay Pipes
> Cc: openstack at lists.launchpad.net
> Subject: Re: [Openstack] Feature Freeze status
>
> [Snip] 
>
> Clearly blueprints are about process and not about code.  Merge
> proposals are a hybrid of code and process.  Blueprints are about
> managing expectations, whereas merge proposals are about managing
> code.  I think if you are working on a self-contained change you don't
> need to manage the expectations of people working on other parts of
> the system because you're not going to interfere, and their
> expectations about how they should write code can go unchanged.  You
> do, however, need to have a process required to get your changes
> accepted into the code, and need to outline your reasoning and
> implementation goals.

I think that this paragraph is a great exposition of why I (and others) disagree with you.  Blueprints are not about managing expectations.  Blueprints are about telling other people what you're working on.  This is important, because I don't think that anyone is in a position to judge whether they are "working on a self-contained change" or whether they're "not going to interfere" _unless_ they are telling people what they are working on.

For example, there have been many occasions when we (Citrix) have said "oh, we don't need to work on that, because Rackspace have it covered" or "we'd best mention this to Rackspace, because they're working on something else that is _bound_ to conflict".  There have also been times when we've said "it sure would have been great to know about that in advance, and save ourselves half-a-dozen trunk merges".

Blueprints are important because they save other people wasting their time.  That's either because they get to avoid duplicating your effort, or because they want to work in the same code and get to schedule around you so that the merge conflicts aren't insane.  Maybe, if you're really lucky, they might actually have some good ideas and can make suggestions to you.

Blueprints should be regarded in the same way as docstrings.  Sure, you can write the code faster without docstrings, and the code will work just as well, but it will take everyone else twice as long to figure out what it was you are trying to do.  Blueprints are the same, just at a different phase in the process.  You can definitely write the code without writing the blueprint first, but everyone else would sure appreciate it if you put half-an-hour into the blueprint.  That way, we'll know what it is you're trying to do.

Thanks,

Ewan.