On 9 October 2013 07:24, Jiří Stránský <ji...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
