Open Stack

Excerpts from Robert Collins's message of 2013-12-09 16:31:37 -0800:
> On 6 December 2013 21:56, Jaromir Coufal <jcoufal at 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."