On 10 December 2013 11:04, Steven Hardy <sha...@redhat.com> wrote:

>> So it's a gross mischaracterisation to imply that a democratic process
>> aided by some [crude] stats has been reduced to name & shame, and a
>> rather offensive one.
>
> Yes I have read your monthly core reviewer update emails[1] and I humbly
> apologize if you feel my characterization of your process is offensive, it
> certainly wasn't intended to be.

Thank; enough said here - lets move on :)


>> I think you have a very different definition of -core to the rest of
>> OpenStack. I was actually somewhat concerned about the '+2 Guard the
>> gate stuff' at the summit because it's so easily misinterpreted - and
>> there is a meme going around (I don't know if it's true or not) that
>> some people are assessed - performance review stuff within vendor
>> organisations - on becoming core reviewers.
>>
>> Core reviewer is not intended to be a gateway to getting features or
>> ideas into OpenStack projects. It is solely a volunteered contribution
>> to the project: helping the project accept patches with confidence
>> about their long term integrity: providing explanation and guidance to
>> people that want to contribute patches so that their patch can be
>> accepted.
>
> We need core reviewers who:
> 1. Have deep knowledge of the codebase (to identify non-cosmetic structural
> issues)

mmm, core review is a place to identify really significant structural
issues, but it's not ideal. Because - you do a lot of work before you
push code for review, particularly if it's ones first contribution to
a codebase, and that means a lot of waste when the approach is wrong.
Agree that having -core that can spot this is good, but not convinced
that it's a must.

> 2. Have used and debugged the codebase (to identify usability, interface
> correctness or other stuff which isn't obvious unless you're using the
> code)

If I may: 2a) Have deployed and used the codebase in production, at
scale. This may conflict with 1) in terms of individual expertise.

> 3. Have demonstrated a commitment to the project (so we know they
> understand the mid-term goals and won't approve stuff which is misaligned
> with those goals)

I don't understand this. Are you saying you'd turn down contributions
that are aligned with the long term Heat vision because they don't
advance some short term goal? Or are you saying you'd turn down
contributions because they actively harm short term goals?

Seems to me that that commitment to the project is really orthogonal
to either of those things - folk may have different interpretations
about what the project needs while still being entirely committed to
it! Perhaps you mean 'shared understanding of current goals and
constraints' ? Or something like that? I am niggling on this point
because I wouldn't want someone who is committed to TripleO but
focused on the big picture to be accused of not being committed to
TripleO.

> All of those are aided and demonstrated by helping out doing a few
> bugfixes, along with reviews.

1) might be - depends on the bug. 2) really isn't, IME anyhow, and
three seems entirely disconnected to both reviews and bugfixes, and
more all about communication.



> All I wanted to do was give folks a heads-up that IMHO the stats aren't the
> be-all-and-end-all, and here are a few things which you might want to
> consider doing, if you want to become a core reviewer in due course.

Ok, thats a much better message than the one you appeared to start
with, which sounded like 'stats are bad, here's what it really takes'.

Some food for thought though: being -core is a burden, it's not a
privilege. I think we should focus more on a broad community of
effective reviewers, rather than on what it takes to be in -core.
Being in -core should simply reflect that someone is currently active,
aware of all the review needs of the project, capable (informed,
familiar with the code and design etc) of assessing +2 and APRV
status, and responsible enough to trust with that. Folk that review
and never become -core are still making a significant contribution to
code quality, if they are doing it right - by which I mean:

 - following up and learning the norms are for that project (they
differ project to project in OpenStack)
 - following up and learning about the architectural issues and design
issues they need to watch out for

Someone doing that quickly become able to act as a valuable first-pass
filter for the two +2 votes that actually land a patch; speeding up
the +2 review time [less round trips to +2 land == more +2 bandwidth]
and helping the project as a whole.

-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

Reply via email to