[OpenLayers-Dev] more reviewers, more committers, faster development

[Christopher Schmidt]

On Wed, Dec 19, 2007 at 01:52:53PM -0700, Tim Schaub wrote:
> Hey-
> 
> So, I'd like to get feedback on a fresh proposal.  We're all interested 
> (I think) in seeing things move more quickly through the ticket queue. 
> I'm also interested in seeing more people contributing to OpenLayers as 
> committers.

First reaction to this is positive. I think that everything you've said
here is right, and it addresses my concerns better than simply removing
a review step.

I'm still concerned that people won't be reviewing patches. I'm not
convinced yet that this solves that problem. Maybe widening the pool
really will help -- in which case I'm all for it. 

I'm also supportive of requiring more review on things that affect the
API. I'm aware that I'm pretty stringent with regard to changing API
methods, which means that screwing it up the first time means that I say
we can't change it :) Preventing ourselves from screwing it up the first
time is good.

> This could be made clear by adding an "API Review" state to the state 
> field for tickets.  Tickets with "Review" can get reviewed by reviewers 
> or trunk committers.  Tickets with "API Review" require review by a 
> trunk committer.
> 
> I imagine it is also possible to add a reviewer role to trac permissions 
> - making the state field editable only by reviewers.

I don't think this particular technical detail is neccesary, and I'd
prefer not to screw with trac anymore than I have to. :) Erik would
probably be willing to look into it when he gets back, and I'd be
willing to make it happen if someone could make the modifications a step
by step process i can follow.

> Trivial commits
> ---------------
> Even with more reviewers (and I'd like to significantly expand our 
> reviewer pool), I imagine there will be an interest in speeding up the 
> commit process.  I proposed some language on the TrunkCommits wiki page 
> for trivial commits.  I'm open to hearing suggestions on expanding that 
> to include other simple bug fixes or modifications.

I think your language here is acceptable if reviews of functional
changes happen consistently. My arguments in favor of allowing trivial
commits without review have been about solving the problem in the wrong
way.

> There are a handful of reasons why I prefer a path like this to the 
> "commits without review" path.  Primarily, it's about getting more 
> people involved in the project - which I believe will let us sustain a 
> successful project.  

I'll buy that.

> I also believe that removing the review process 
> makes it *harder* to give out commit access.  That is, we raise the bar 
> when we remove the review process.  

I buy that too.

> Chris, this is not about you.  I 
> have no concern about you making commits without review.  This is about 
> broadening the project beyond a few select contributers.

Yep.

> In addition, I think adding a reviewer role would give contributers a 
> better chance to demonstrate commitment and good sense.  I appreciate 
> the chance to review patches because I feel like it helps understand how 
> another developer thinks.  By reviewing each other's code, we 
> synchronize our style and thinking.  I believe that this benefits the 
> project by giving it a more uniform behavior and feel.  I can't see how 
> this happens (with new contributers in particular) if we all operate 
> independently.

Agreed.

> I meant to keep this simple.  I'm really just proposing a reviewer role. 
>   Not trying to solve all problems - but I think this would get at a 
> number of issues we are currently dealing with.

Yep. Agreed in full.

Regards,
-- 
Christopher Schmidt
MetaCarta