On 05/06/14 12:03, Kurt Griffiths wrote:
I just learned that some projects are thinking about having the specs
process be the channel for submitting new feature ideas, rather than
registering blueprints. I must admit, that would be kind of nice because
it would provide some much-needed structure around the triaging process.
I wonder if we can get some benefit out of the spec process while still
keeping it light? The temptation will be to start documenting everything
in excruciating detail, but we can mitigate that by codifying some
guidelines on our wiki and baking it into the team culture.
What does everyone think?
FWIW we just adopted a specs repo in Heat, and all of us feel exactly
the same way as you do:
http://lists.openstack.org/pipermail/openstack-dev/2014-May/036432.html
I can't speak for every project, but you are far from the only ones
wanting to use this as lightweight process. Hopefully we'll all figure
out together how to make that happen :)
cheers,
Zane.
From: Kurt Griffiths <kurt.griffi...@rackspace.com
<mailto:kurt.griffi...@rackspace.com>>
Date: Tuesday, June 3, 2014 at 9:34 AM
To: OpenStack Dev <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Marconi] Adopt Spec
I think it becomes more useful the larger your team. With a smaller team
it is easier to keep everyone on the same page just through the mailing
list and IRC. As for where to document design decisions, the trick there
is more one of being diligent about capturing and recording the why of
every decision made in discussions and such; gerrit review history can
help with that, but it isn’t free.
If we’d like to give the specs process a try, I think we could do an
experiment in j-2 with a single bp. Depending on how that goes, we may
do more in the K cycle. What does everyone think?
From: Malini Kamalambal <malini.kamalam...@rackspace.com
<mailto:malini.kamalam...@rackspace.com>>
Reply-To: OpenStack Dev <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, June 2, 2014 at 2:45 PM
To: OpenStack Dev <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Marconi] Adopt Spec
+1 – Requiring specs for every blueprint is going to make the
development process very cumbersome, and will take us back to waterfall
days.
I like how the Marconi team operates now, with design decisions being
made in IRC/ team meetings.
So Spec might become more of an overhead than add value, given how our
team functions.
_'If'_ we agree to use Specs, we should use that only for the blue
prints that make sense.
For example, the unit test decoupling that we are working on now – this
one will be a good candidate to use specs, since there is a lot of back
and forth going on how to do this.
On the other hand something like Tempest Integration for Marconi will
not warrant a spec, since it is pretty straightforward what needs to be
done.
In the past we have had discussions around where to document certain
design decisions (e.g. Which endpoint/verb is the best fit for pop
operation?)
Maybe spec is the place for these?
We should leave it to the implementor to decide, if the bp warrants a
spec or not & what should be in the spec.
From: Kurt Griffiths <kurt.griffi...@rackspace.com
<mailto:kurt.griffi...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, June 2, 2014 1:33 PM
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Marconi] Adopt Spec
I’ve been in roles where enormous amounts of time were spent on writing
specs, and in roles where specs where non-existent. Like most things,
I’ve become convinced that success lies in moderation between the two
extremes.
I think it would make sense for big specs, but I want to be careful we
use it judiciously so that we don’t simply apply more process for the
sake of more process. It is tempting to spend too much time recording
every little detail in a spec, when that time could be better spent in
regular communication between team members and with customers, and on
iterating the code (/short/ iterations between demo/testing, so you
ensure you are on staying on track and can address design problems
early, often).
IMO, specs are best used more as summaries, containing useful
big-picture ideas, diagrams, and specific “memory pegs” to help us
remember what was discussed and decided, and calling out specific
“promises” for future conversations where certain design points are TBD.
From: Malini Kamalambal <malini.kamalam...@rackspace.com
<mailto:malini.kamalam...@rackspace.com>>
Reply-To: OpenStack Dev <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, June 2, 2014 at 9:51 AM
To: OpenStack Dev <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Marconi] Adopt Spec
Hello all,
We are seeing more & more design questions in #openstack-marconi.
It will be a good idea to formalize our design process a bit more
& start using spec.
We are kind of late to the party –so we already have a lot of precedent
ahead of us.
Thoughts?
Malini
_______________________________________________
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
