Thanks Kevan for the summary, I think this really helps.
More comments below inline...
On Sep 6, 2006, at 1:34 PM, Kevan Miller wrote:
1. Relaxed RTC
...
* 3 +1 votes from committers on the project (1 of these committers
needs to be a member of the PMC) with no outstanding -1 votes.
I don't think that we need a requirement of a PMC vote here. The PMC
can provide enough oversight w/o a required vote. IMO, a vote is a
vote is a vote... I don't put any weight over a committers vote to a
PMC members vote. I value them both equally. Forcing a PMC vote
here is artificial and promotes separatism rather than unity.
2. RTC with Lazy Consensus
Geronimo follows a Review-Then-Commit model with Lazy consensus.
Patches for new function are provided by developers for review and
comment by their peers. Feedback is conducted through JIRA
comments. The goal of this interaction is to solicit suggestions
from the community and incorporate their feedback as appropriate. A
patch is accepted if:
* 3 +1 votes from committers on the project with no outstanding -1
votes and no significant, ongoing discussion
* 72 hours pass with no outstanding -1 votes and no significant,
ongoing discussion. A 24 hour warning should be sent to the dev list.
For the most part I like this model... but only for non-trivial
changes, see below.
3. CTR with documentation guidelines
Geronimo follows a Commit-Then-Review model. There should be an
emphasis of community communication. Community-based policing and
persuasion will be used to remedy any problem areas. Guidelines are
not strict dogma -- common sense should prevail. Community
communication is the key, not a process. General guidelines are:
* Non-trivial changes (and certainly potentially controversial
changes) should be announced on the dev list. This announcement
should be well in advance of the change being committed. The
community should be given the opportunity to understand and discuss
the proposal.
* Concurrent with the commit of a significant change, the committer
should document the change on the dev list. You should describe
what you are doing, describe why you are doing it, and provide an
overview of how you implemented it.
This feels a whole lot like common-sense for how to participate on an
open-source project. In most cases, I think this is also the best
model to run under... though I do believe that RTC has some merit as
well.
If it was up to me (which it isn't, but here is my opinion anyways),
I would use a hybrid model, which would default to CTR (with emphasis
on common sense and communication) and for non-trivial or potentially
controversial changes follow the RTC with Lazy Consensus as described
in #2 (with the addition of inclusion of development branches or
patches, depending on the complexity). I actually think that this is
common-sense too.
IMO... this is the best of both worlds, without being too overbearing
on policy and process, leveraging the trust of the developers and
fostering our community with sufficient oversight and freedom to
allow real progress to be achieved.
* * *
But Jason... how do I know what is non-trivial or controversial?
Well, if you have to ask this... either common sense has failed you
( :-P ) or you should consider your changes to be non-trivial/
controversial and propose the change under RTC w/LC.
But Jason... what if someone commits something that I think should
have been RTC w/LC?
Well, you communicate that to the group, explaining why you think the
change was non-trivial/controversial and then we work together as a
community to resolve the issue, potentially educating the developer
if the change should have been RTC w/LC or educating why it was not
and if needed backing out the change and re-proposing it via RTC w/
LC. This too feels like common sense.
But Jason... I think you are on crack... and I want to smoke some too!
Okay, you are on your own there... just make sure you clean your
pipe, cause their ain't nuthing worse than a dirty ole crack pipe. :-P
--jason
