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

Tim Schaub tschaub at openplans.org
Wed Dec 19 15:52:53 EST 2007


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 

With that in mind, I think it makes sense to have an explicit path to 
becoming a trunk committer.  We currently have two different roles with 
regard to code contributions: sandbox commit (given out to anyone who 
asks), and trunk commit (given out after some process of proving oneself).

Reviewer role
I'd like to add a "reviewer" role between the two.  The reviewer role 
would be given to someone who has demonstrated a commitment to the 
project and shows good sense through code contributions (patches, 
comments, etc.).  Reviewers would then be eligible for trunk commit 
access after continued demonstration of commitment and good sense (all 
vague, I know).

Non-API commits
Then, I'd like to say we amend our trunk commit policy to say that 
modifications that don't change the API (no API additions, no changes to 
  API method signatures) require review by either a reviewer or a trunk 

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.

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.

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 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.  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.

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 

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.

Thanks for any feedback,

More information about the Dev mailing list