|Re: [ide-dev] Development Process|
On 09/25/2013 07:06 PM, Miles Parker wrote:
I agree with your point.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.
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".