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 was > > on hold and I was designing future views. I'll continue working on designs > > much more, but I will also keep an eye on code which is going in. I believe > > that UX reviews will be needed before merging so that we assure keeping the > > vision. That's why I would like to express my will to stay within -core even > > when I don't deliver that big amount of reviews as other engineers. However > > 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).
+1 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 OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
