Excerpts from Robert Collins's message of 2013-12-09 16:31:37 -0800: > 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! >
We are human. Humans see a word like core and they look it up in their internal dictionary. Apples have cores. Nuclear reactors have cores. You can extract a core sample from deep under a sheet of ice. In our mind, cores are at the _center_. The seeds are in the cores. Cores are where all the magic happens. They hold the secrets. So it makes sense that when not-core sees core, they think "I should defer to this person." They do not think "I am a peer." If the code review process were a nuclear reactor, they are just shielding, or vent tubes. That person is part of _the core_. And having +2/-2/+A reinforces this. Core does not have to say much, they can "speak softly and carry a big -2 stick". Finally, being confirmed by the rest of the team makes them special. It makes them a leader. Can we change this? Before we run off and change everything, I think we must also ask ourselves "should we change this?" > 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). > They also lose the ability to +1 or -1 changes to the core team. But the bigger loss is that it means they lose a label that gives their voice amplification. It may not be intended that way, but I would challenge anyone to explain that it is not that way. I would be surprised to see one review stream that does not have core reviewers setting the tone and driving almost all of the conversations. Should we change this? I don't think so. I think being a leader is a burden unto itself. I also think that all reviewers can be trusted to hold off with just +1 instead of +2 if they don't feel like they're familiar enough with the code to +2. And I think it would make our governance unnecessarily complex if we tried to have two overlapping groups for core review and leadership. So for what it is worth, I think that we should make core more sticky and just give core people a reminder when they're not doing _all_ of the duties that they've signed up for. Your email showing people below the line is an example of a reminder for those people. "You are not doing everything a leader must do." _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
