On Dec 10, 2013 2:37 AM, "Robert Collins" <robe...@robertcollins.net> wrote:
> On 6 December 2013 21:56, Jaromir Coufal <jcou...@redhat.com> wrote:
> >
> > Hey there,
> >
> > thanks Rob for keeping eye on this. Speaking for myself, as current
> > non-coder it was very hard to keep pace with others, especially when UI
> > on hold and I was designing future views. I'll continue working on
> > much more, but I will also keep an eye on code which is going in. I
> > that UX reviews will be needed before merging so that we assure keeping
> > vision. That's why I would like to express my will to stay within -core
> > when I don't deliver that big amount of reviews as other engineers.
> > if anybody feels that I should be just +1, I completely understand and I
> > will give up my +2 power.
> >
> > -- Jarda
> Hey, so -
> I think there are two key things to highlight here. Firstly, there's
> considerable support from other -core for delaying the removals this
> month, issue. I'll re-evaluate in Jan (and be understanding then as there
> is a big 1-2 week holiday in there).
> That said, I want to try and break down the actual implications here,
> both in terms of contributions, recognition and what it means for the
> project.
> Firstly, contributions. Reviewing isn't currently *directly*
> recognised as a 'technical contribution' by the bylaws: writing code
> that land in the repository is, and there is a process for other
> contributions (such as design, UX, and reviews) to be explicitly
> recognised out-of-band. It's possible we should revisit that -
> certainly I'd be very happy to nominate people contributing through
> that means as a TripleO ATC irrespective of their landing patches in a
> TripleO code repository [as long as their reviews *are* helpful :)].
> But thats a legalistic sort of approach. A more holistic approach is
> to say that any activity that helps TripleO succeed in it's mission is
> a contribution, and we should be fairly broad in our recognition of
> that activity : whether it's organising contributed hardware for the
> test cloud, helping admin the test cloud, doing code review, or UX
> design - we should recognise and celebrate all of those things.
> Specifically, taking the time to write a thoughtful code review which
> avoids a bug landing in TripleO, or keeps the design flexible and
> effective *is* contributing to TripleO.
> We have a bit of a bug in OpenStack today, IMO, in that there is more
> focus on being -core than on being a good effective reviewer. IMO
> that's backwards: the magic switch that lets you set +2 and -2 is a
> responsibility, and that has some impact on the weight your comments
> in reviews have on other people - both other core and non-core, but
> the contribution we make by reviewing doesn't suddenly get
> significantly better by virtue of being -core. There is an element of
> trust and faith in personality etc - you don't want destructive
> behaviour in code review, but you don't want that from anyone - it's
> not a new requirement place on -core. What I'd like to see is more of
> a focus on review (design review, code review, architecture review) as
> something we should all contribute towards - jointly share the burden.
> For instance, the summit is a fantastic point for us to come together
> and do joint design review of the work organisations are pushing on
> for the next 6 months : thats a fantastic contribution. But when
> organisations don't send people to the summit, because of $reasons,
> that reduces our entire ability to catch problems with that planned
> work : going to the summit is /hard work/ - long days, exhausting,
> intense conversations. The idea (which I've heard some folk mention)
> that only -core folk would be sent to the summit is incredibly nutty!
> So what does it mean for TripleO when someone stops being -core
> because of inactivity:
> Firstly it means they have *already* effectively stopped doing code
> review at a high frequency: they are *not* contributing in a
> substantial fashion through that avenue. It doesn't mean anything
> about other avenues of contribution.
> Secondly, if they do notice something badly wrong with a patch, or a
> patch that needs urgent landing, they can no longer do that
> themselves: they need to find a -core and get the -core to do it.
> Thats really about it - there is no substantial impact on the core
> review bandwidth for the team (they were already largely inactive).


Very well put, as you said this is a larger openstack issue, hopefully we
can fix this on the larger openstack scale and not just in tripleo.

> So, how does this apply to you specifically, and to the other Tuskar
> UI folk who've been focused on Horizon itself and other things
> recently....
> If you add a -1 to a patch, it should be treated with much the same
> consideration as one from me: we all want to get good code in, and the
> union of opinions should be fairly harmonious.
> If you +1 a patch saying 'the design is great', it helps other folk
> worry less about that, but we still have to care for the code, the API
> implications etc.
> If you (I'm speaking to everyone that I proposed in the 'should we
> remove from -core?' section are planning on staying about the same
> level of activity w.r.t. code review, then I don't think being in
> -core makes a lot of sense. We're pretty up to date on reviews - we
> have very little backlog and code quality landing is pretty good. Even
> if one of you individually wrote 90% of the new Tuskar-API code, if
> you're not reviewing *other peoples code* enough to keep up to date...
> then being in -core doesn't make sense. Writing code and reviewing
> code are separate contribution pathways, and though obviously there is
> considerable crossover it's entirely possible to be good at one and
> not the other, or just to do a lot of one and not the other. *And
> thats OK*.
> So all that said, I think the vote summary is:
>  - Ghe into core
>  - the proposed removals held for a month
> And we'll re-evaluate in Jan.
> -Rob
> --
> Robert Collins <rbtcoll...@hp.com>
> Distinguished Technologist
> HP Converged Cloud
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
OpenStack-dev mailing list

Reply via email to