Open Stack

On 03/28/2017 11:09 AM, 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).

To me, this is an indication that cores are overloaded already (or 
apathetic about software design, but I'm going to be optimistic here). 
Adding more features for them to review isn't going to help that. :-/

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

I hate that we've come to this (and yes, hate is a strong word.  That's 
not an accident).  For minor features that only require a single or 
couple of patches, sure.  But one of the advantages of specs is that 
they provide an explicit list of things that the submitter needs to 
think about (user interaction, documentation, testing, security, etc.). 
This is all stuff that needs to be considered whether we use full specs 
or not, unless the feature is so small that none of them apply, which is 
a good indication that a spec is not required anyway.

That said, I do recognize the problems we've had with specs.  I wonder 
if, regardless of whether we do a spec-lite thing, we need to revisit 
https://specs.openstack.org/openstack/tripleo-specs/specs/policy/spec-review.html 
and streamline it a lot.  Stronger emphasis on not nit-picking spelling 
and grammar, maybe better guidelines about the expected level of detail 
of a spec and how deeply (or not) they should be reviewed.

Also worth noting is that a few of us have been contacted privately 
asking for tips on writing specs.  It might be worth writing something 
up from the other side to help committers write good, reviewable specs. 
It wouldn't have to be elaborate, but some guidelines might make 
everyone's lives easier.

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

+1.  It seems like a lot of the problems with specs stem from the fact 
that they get too deep into the implementation details and it just takes 
too long to review.  Also, as Steve mentioned, it's hard to know all the 
implementation details up front.  The spec should just be setting the 
direction and allowing people to raise concerns with same.

> 3. If you still want to write a spec, please don't stop your work
> after the specs. Please engage some PoC and prototypes to get feedback
> directly on the implementation.

Having a PoC to look at while reviewing a spec can be super helpful.  I 
would caution about getting too invested in a specific direction in case 
the review feedback requires major changes, but I'm +1 overall on this.

>
> I think these proposals are realistic with the regard of how TripleO
> project works now.
> Please bring any feedback or question.
>
> Thanks,
>
> On Fri, Jan 29, 2016 at 3:26 AM, Dougal Matthews <dougal at redhat.com> wrote:
>>
>>
>> On 27 January 2016 at 16:21, Derek Higgins <derekh at redhat.com> wrote:
>>>
>>> Hi All,
>>>
>>> We briefly discussed feature tracking in this weeks tripleo meeting. I
>>> would like to provide a way for downstream consumers (and ourselves) to
>>> track new features as they get implemented. The main things that came out of
>>> the discussion is that people liked the spec-lite process that the glance
>>> team are using.
>>>
>>> I'm proposing we would start to use the same process, essentially small
>>> features that don't warrant a blueprint would instead have a wishlist bug
>>> opened against them and get marked with the spec-lite tag. This bug could
>>> then be referenced in the commit messages. For larger features blueprints
>>> can still be used. I think the process documented by glance[1] is a good
>>> model to follow so go read that and see what you think
>>>
>>> The general feeling at the meeting was +1 to doing this[2] so I hope we
>>> can soon start enforcing it, assuming people are still happy to proceed?
>>
>>
>> +1 sounds good.
>>
>>>
>>>
>>> thanks,
>>> Derek.
>>>
>>> [1]
>>> http://docs.openstack.org/developer/glance/contributing/blueprints.html#glance-spec-lite
>>> [2]
>>> http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-01-26-14.02.log.html
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>