Open Stack

On Wed, Mar 29, 2017 at 10:42 PM, Steven Hardy <shardy at redhat.com> wrote:

> On Tue, Mar 28, 2017 at 12:09:43PM -0400, Emilien Macchi wrote:
> > Bringing an old topic on the table.
> >
> > We might have noticed:
> >
> > 1. Some tripleo-specs take huge amount of time before getting merged
> > (or even reviewed). We have been asking folks to review them every
> > week but unfortunately they don't get much attraction (# of core
> > reviewers versus # of folks actually reviewing specs).
> > 2. Some folks spend a lot of time writing TripleO specs and wait for
> > feedback before starting some implementation (like proof of concept).
> >
> > Because TripleO like innovation and also moving fast, I think it's
> > time to bring the tripleo-specs topic on the table:
> >
> > 1. If you have an idea, don't feel obliged to write a specs. Create a
> > blueprint on launchpad, announce it on the ML and start writing code
> > (can be real implementation or just a simple PoC). Feedback will be
> > given in the classic code review.
>
> +1 I for one have been burnt more than once spending significant time
> on a spec only to find our collective understanding changes after actual
> code exists.
>
> For things related to interfaces a spec can be helpful, but I think it's
> often faster to raise a blueprint with relatively few details and work on a
> prototype that clarifies the direction, particularly if such code patches
> can be generated fairly quickly.
>
> > 2. If you still want to write a spec, please make it readable and
> > communicate about it. If your spec is 900 lines long and not announced
> > anywhere, there is an high change that it will never been reviewed.
>
> I agree - I think a common mistake is to get bogged down in implementation
> detail when writing (and reviewing) a spec, so I definitely favor a
> clearly expressed summary of the problem, an overview of the proposed
> direction (including any major interface changes), and clarification of any
> user/dev visible impact.  None of this requires much focus at all on the
> details of the implementation IMO.
>
> Thanks for raising this Emilien, hopefully this will help us move a little
> faster in future!
>
> Steve


Having wrote a few specs this cycle, its good to read both your views, as I
was becoming concerned about spending a fair amount of time on answering
comments, correcting grammar nits, clarifying misunderstands etc, instead
of getting code I already had staged up for review.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170330/b2d312c3/attachment.html>