On Wed, Mar 29, 2017 at 10:42 PM, Steven Hardy <sha...@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.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev