On 09/25/2013 07:06 PM, Miles Parker
wrote:
Hmmm…my kneejerk response was that Reviews work best only if people are taking on both roles. That is, the only way to really know a code base well enough to make a sound judgement about code is to also be actively developing to the same code base. It's been my experience that it doesn't work very well when reviewers are not grappling on a day to day basis with the same issues that a contributor is. That might be different for a very mature piece of code, but note that the number of people with those kinds of chops and experience on platform and JDT is very small and it would be a shame to have them doing nothing but reviews. Conversely, I think it is also very important to have every coder involved in reviewing code.
There is a bit of a quid pro quo that has to develop to make the whole exchange work. If we want a community of "social coders" to emerge, we will need to stop thinking about "Reviewing" and "Coding" as separate activities.
I agree with your point.
What I have in mind is more a set of people who make reviewing the
top-priorities (more important than coding directly). When they are
out of reviews, they can keep on developing stuff.
Ideally, it should be the role of everyone, but it's difficult to
officially say to a contributor "Review first, code after" if you
don't pay him to have him/her obeying. Most of us prefer to write
new features than reviewing code, so getting people to review code
requires more effort than getting people to code (more effort =
employer/manager make it clear that it what she/he expects from
you).
Although it seems easy and usual to get review more prioritary than
coding in a team, I think there are other challenges in a community,
because no-one in the community is allowed to enfore how other
contributors should contribute, no-one can say "I want you to review
this patch before you submit another patch". There is no
organization authority to enforce such practices, so they must come
by themselves, and it is not as trivial as telling to your employee
"Don't code this, review that first".
|