Open Stack

Thanks Duncan and also Dolph, I should have made the question
broader.  :-)

On Wed, 2014-07-16 at 13:22 +0100, Duncan Thomas wrote:
> On 16 July 2014 03:57, Jay S. Bryant <jsbryant at electronicjungle.net> wrote:
> > John,
> >
> > So you have said a few times that the specs are a learning process.
> > What do you feel with have learned thus far using specs?
> 
> I'm not John, but I'm going to answer as if you'd addressed the question wider:
> - Specs can definitely help flesh out ideas and are much better than
> blueprints as a way of tracking concerns, questions, etc
> 

I feel I have better knowledge of what is being worked thanks to the
specs.  This may partially be because I was also involved from the
summit on for the first time.  They definitely are better for fleshing
out ideas and discussing concerns.

> - We as a community are rather shy about making decisions as
> individuals, even low risk ones like 'Does this seem to require a
> spec' - if there doesn't seem to be value in a spec, don't do one
> unless somebody asks for one

Agreed.  I think we all need to be less shy about making decisions and
voicing them.  At least in Cinder.  :-)

> 
> - Not all questions can be answered at spec time, sometimes you need
> to go bash out some code to see what works, then circle again
> 
> - Careful planning reduces velocity. No significant evidence either
> way as to whether it improves quality, but my gut feeling is that it
> does. We need to figure out what tradeoffs on either scale we're happy
> to make, and perhaps that answer is different based on the area of
> code being touched and the date (e.g. a change that doesn't affect
> external APIs in J-1 might need less careful planning than a change in
> J-3. API changes or additions need more discussion and eyes on than
> none-API changes)

I think, through this development cycle we are starting to narrow down
what really needs a spec.  I think it would be good to perhaps have a
Lessons Learned session at the K summit on the specs and try to better
define expectations for use in the future.  I feel it has slowed, or at
least focused development.  That has been good.

> 
> - Specs are terrible for tracking work items, but no worse than blueprints
> 
Agreed.
> - Multiple people might choose to work on the same blueprint in
> parallel - this is going to happen, isn't necessarily rude and the
> correct solution to competing patches is entirely subjective