Open Stack

IMO, 'spec' is indeed a good idea and indeed useful for tracking
features, although it's a little tough for us not using English as
native language. But we still need to identify these 'small features',
and core reviewers do some review, then approve them ASAP, so that we
can avoid to waste a lot of time to wait for code implementaion.

2014-07-02 2:08 GMT+08:00 Devananda van der Veen <devananda.vdv at gmail.com>:
> On Tue, Jul 1, 2014 at 10:02 AM, Dolph Mathews <dolph.mathews at gmail.com> wrote:
>> The argument has been made in the past that small features will require
>> correspondingly small specs. If there's a counter-argument to this example
>> (a "small" feature requiring a relatively large amount of spec effort), I'd
>> love to have links to both the spec and the resulting implementation so we
>> can discuss exactly why the spec was an unnecessary additional effort.
>>
>>
>> On Tue, Jul 1, 2014 at 10:30 AM, Jason Dunsmore
>> <jason.dunsmore at rackspace.com> wrote:
>>>
>>> On Mon, Jun 30 2014, Joshua Harlow wrote:
>>>
>>> > There is a balance here that needs to be worked out and I've seen
>>> > specs start to turn into requirements for every single patch (even if
>>> > the patch is pretty small). I hope we can rework the 'balance in the
>>> > force' to avoid being so strict that every little thing requires a
>>> > spec. This will not end well for us as a community.
>>> >
>>> > How have others thought the spec process has worked out so far? To
>>> > much overhead, to little…?
>>> >
>>> > I personally am of the opinion that specs should be used for large
>>> > topics (defining large is of course arbitrary); and I hope we find the
>>> > right balance to avoid scaring everyone away from working with
>>> > openstack. Maybe all of this is part of openstack maturing, I'm not
>>> > sure, but it'd be great if we could have some guidelines around when
>>> > is a spec needed and when isn't it and take it into consideration when
>>> > requesting a spec that the person you have requested may get
>>> > frustrated and just leave the community (and we must not have this
>>> > happen) if you ask for it without explaining why and how clearly.
>>>
>>> +1 I think specs are too much overhead for small features.  A set of
>>> guidelines about when specs are needed would be sufficient.  Leave the
>>> option about when to submit a design vs. when to submit code to the
>>> contributor.
>>>
>>> Jason
>>>
>
> Yes, there needs to be balance, but as far as I have seen, folks are
> finding the balance around when to require specs within each of the
> project teams. I am curious if there are any specific examples where a
> project's core team required a "large spec" for what they considered
> to be a "small feature".
>
> I also feel strongly that the spec process has been very helpful for
> the projects that I'm involved in for fleshing out the implications of
> changes which may at first glance seem small, by requiring both
> proposers and reviewers to think about and discuss the wider
> ramifications for changes in a way that simply reviewing code often
> does not.
>
> Just my 2c,
> Devananda
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards!
-----------------------------------
Lingxian Kong