On Sun, Jul 20, 2014, at 04:35 PM, Jay S. Bryant wrote: > 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 <jsbry...@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.
We should make that a cross-project session, so we can learn from what the other projects did, too. Doug > > > > > - 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 > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev