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 __________________________________________________________________________ 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