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, so we'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). 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