Open Stack

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!

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 <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud