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