[openstack-dev] [TRIPLEO] tripleo-core update october

Robert Collins robertc at robertcollins.net
Tue Oct 8 21:53:14 UTC 2013


On 9 October 2013 07:24, Jiří Stránský <jistr at redhat.com> wrote:
> Clint and Monty,
>
> thank you for such good responses. I am new in TripleO team indeed and I was
> mostly concerned by the "line in the sand". Your responses shed some more
> light on the issue for me and i hope we'll be heading the right way :)

Sorry for getting folk concerned! I'm really glad some folk jumped in
to clarify. Let me offer some more thoughts on top of this..
I was taking some concepts as a given - they are part of the OpenStack
culture - when I wrote my mail about TripleO reviewer status:

* That what we need is a bunch of folk actively engaged in thinking
about the structure, performance and features of the component
projects in TripleO, who *apply* that knowledge to every code review.
And we need to grow that collection of reviewers to keep up with a
growing contributor base.

* That the more reviewers we have, the less burden any one reviewer
has to carry : I'd be very happy if we normalised on everyone in -core
doing just one careful and effective review a day, *if* thats
sufficient to carry the load. I doubt it will be, because developers
can produce way more than one patch a day each, which implies 2*
developer count reviews per day *at minimum*, and even if every ATC
was a -core reviewer, we'd still need two reviews per -core per day.

* How much knowledge is needed to be a -core? And how many reviews?
There isn't a magic number of reviews IMO: we need 'lots' of reviews
and 'over a substantial period of time' : it's very hard to review
effectively in a new project, but after 3 months, if someone has been
regularly reviewing they will have had lots of mentoring taking place,
and we (-core membership is voted on by -core members) are likely to
be reasonably happy that they will do a good job.

* And finally that the job of -core is to sacrifice their own
productivity in exachange for team productivity : while there are
limits to this - reviewer fatigue, personal/company goals, etc etc, at
the heart of it it's a volunteer role which is crucial for keeping
velocity up: every time a patch lingers without feedback the developer
writing it is stalled, which is a waste (in the Lean sense).



So with those 'givens' in place, I was trying to just report in that
context.. the metric of reviews being done is a *lower bound* - it is
necessary, but not sufficient, to be -core. Dropping below it for an
extended period of time - and I've set a pretty arbitrary initial
value of approximately one per day - is a solid sign that the person
is not keeping up with evolution of the code base.

Being -core means being on top of the evolution of the program and the
state of the code, and being a regular, effective, reviewer is the one
sure fire way to do that. I'm certainly open to folk who want to focus
on just the CLI doing so, but that isn't enough to keep up to date on
the overall structure/needs - the client is part of the overall
story!. So the big thing for me is - if someone no longer has time to
offer doing reviews, thats fine, we should recognise that and release
them from the burden of -core: their reviews will still be valued and
thought deeply about, and if they contribute more time for a while
then we can ask them to shoulder -core again.

HTH,
-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



More information about the OpenStack-dev mailing list