On Wed, Jul 2, 2014 at 7:08 AM, Lingxian Kong <anlin.k...@gmail.com> wrote:
> 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. > 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. An implementation can help illustrate a spec, find it's weak points, or even identify unimplementable parts of a spec. 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. > > 2014-07-02 2:08 GMT+08:00 Devananda van der Veen <devananda....@gmail.com > >: > > On Tue, Jul 1, 2014 at 10:02 AM, Dolph Mathews <dolph.math...@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.dunsm...@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@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Regards! > ----------------------------------- > Lingxian Kong > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev