[OpenLayers-Dev] more reviewers, more committers, faster development
Tim Schaub
tschaub at openplans.org
Wed Dec 19 15:52:53 EST 2007
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.
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
committer.
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
independently.
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,
Tim
More information about the Dev
mailing list