Open Stack

On 2013/08/10 23:53, Robert Collins wrote:
> 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
>
Hey Rob, Clint and Monty,

thanks for clarification, I was not aware of these details before. I 
hope that it will work well.

Thanks
-- Jarda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131009/4b3394c5/attachment.html>