<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 2, 2014 at 7:08 AM, Lingxian Kong <span dir="ltr"><<a href="mailto:anlin.kong@gmail.com" target="_blank">anlin.kong@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">IMO, 'spec' is indeed a good idea and indeed useful for tracking<br>
features, although it's a little tough for us not using English as<br>
native language. But we still need to identify these 'small features',<br>
and core reviewers do some review, then approve them ASAP, so that we<br>
can avoid to waste a lot of time to wait for code implementaion.<br></blockquote><div><br></div><div>If you are confident in the acceptability of your spec, I don't think you should necessarily wait to begin work on an implementation. In fact, I'd suggest that you not wait at all.</div>
<div><br></div><div>An implementation can help illustrate a spec, find it's weak points, or even identify unimplementable parts of a spec.</div><div><br></div><div>That said, you should maintain such an implementation in Gerrit as a Work In Progress so that it is not accidentally merged ahead of the spec.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2014-07-02 2:08 GMT+08:00 Devananda van der Veen <<a href="mailto:devananda.vdv@gmail.com">devananda.vdv@gmail.com</a>>:<br>
<div class="HOEnZb"><div class="h5">> On Tue, Jul 1, 2014 at 10:02 AM, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>> wrote:<br>
>> The argument has been made in the past that small features will require<br>
>> correspondingly small specs. If there's a counter-argument to this example<br>
>> (a "small" feature requiring a relatively large amount of spec effort), I'd<br>
>> love to have links to both the spec and the resulting implementation so we<br>
>> can discuss exactly why the spec was an unnecessary additional effort.<br>
>><br>
>><br>
>> On Tue, Jul 1, 2014 at 10:30 AM, Jason Dunsmore<br>
>> <<a href="mailto:jason.dunsmore@rackspace.com">jason.dunsmore@rackspace.com</a>> wrote:<br>
>>><br>
>>> On Mon, Jun 30 2014, Joshua Harlow wrote:<br>
>>><br>
>>> > There is a balance here that needs to be worked out and I've seen<br>
>>> > specs start to turn into requirements for every single patch (even if<br>
>>> > the patch is pretty small). I hope we can rework the 'balance in the<br>
>>> > force' to avoid being so strict that every little thing requires a<br>
>>> > spec. This will not end well for us as a community.<br>
>>> ><br>
>>> > How have others thought the spec process has worked out so far? To<br>
>>> > much overhead, to little…?<br>
>>> ><br>
>>> > I personally am of the opinion that specs should be used for large<br>
>>> > topics (defining large is of course arbitrary); and I hope we find the<br>
>>> > right balance to avoid scaring everyone away from working with<br>
>>> > openstack. Maybe all of this is part of openstack maturing, I'm not<br>
>>> > sure, but it'd be great if we could have some guidelines around when<br>
>>> > is a spec needed and when isn't it and take it into consideration when<br>
>>> > requesting a spec that the person you have requested may get<br>
>>> > frustrated and just leave the community (and we must not have this<br>
>>> > happen) if you ask for it without explaining why and how clearly.<br>
>>><br>
>>> +1 I think specs are too much overhead for small features. A set of<br>
>>> guidelines about when specs are needed would be sufficient. Leave the<br>
>>> option about when to submit a design vs. when to submit code to the<br>
>>> contributor.<br>
>>><br>
>>> Jason<br>
>>><br>
><br>
> Yes, there needs to be balance, but as far as I have seen, folks are<br>
> finding the balance around when to require specs within each of the<br>
> project teams. I am curious if there are any specific examples where a<br>
> project's core team required a "large spec" for what they considered<br>
> to be a "small feature".<br>
><br>
> I also feel strongly that the spec process has been very helpful for<br>
> the projects that I'm involved in for fleshing out the implications of<br>
> changes which may at first glance seem small, by requiring both<br>
> proposers and reviewers to think about and discuss the wider<br>
> ramifications for changes in a way that simply reviewing code often<br>
> does not.<br>
><br>
> Just my 2c,<br>
> Devananda<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Regards!<br>
-----------------------------------<br>
Lingxian Kong<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>