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