geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <jgenen...@apache.org>
Subject Re: [VOTE] Geronimo Development Process
Date Mon, 11 Sep 2006 14:46:30 GMT
[X] +1 CTR with documentation guidelines

Kevan Miller wrote:
>>
>> This is a vote to determine the development process the Geronimo
>> community wishes to use for "trunk" development. If any modifications
>> are needed for a "branch" development process, then a separate vote
>> will be held.
>>
>> All votes are important. This is a community-wide issue. Please let
>> your voice be heard...
>>
>> Choose the development process which you think will best serve the
>> Geronimo community. I'd like to limit voting to a single process,
>> rather than using a poll/ranking system (i.e. 1,2,3). If a clear
>> consensus does not emerge, then we'll need to refine and hold another
>> vote.
>>
>> [ ] +1 Relaxed RTC
>> [ ] +1 RTC with Lazy Consensus
>> [ ] +1 CTR with documentation guidelines
>>
>> These development processes are summarized below:
>>
>> 1. Relaxed RTC
>>
>> Geronimo follows a Review-Then-Commit (RTC) model.  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.  In order for a patch to be
>> accepted it requires the following:
>>
>> * Needs to be reviewed by committers on the project.  Others may
>> comment but their comments are not binding.  The review may, but does
>> not have to, include application and testing.  The goal of the review
>> is to understand the technical attributes of the change as well as the
>> assess other impacts to the project as a whole.
>>
>> * 3 +1 votes from committers on the project with no outstanding -1 votes.
>>
>> * Any -1 votes need to be accompanied by a reason (the parties should
>> then attempt to reach a mutually agreed upon solution to the issue
>> raised).
>>
>> * If the issues can't be resolved then the PMC can be called upon to
>> settle the dispute and make a recommendation.
>>
>> * Issues are generally of a technical nature.  However, issues may
>> include other items like usability, project cohesiveness or other
>> issues that impact the project as a whole.
>>
>> The goal of these guidelines is to facilitate timely communication as
>> well as the fostering of ideas and collaboration as well as innovation.
>>
>> 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.
>>
>> 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.
>>
>> --kevan
>>

Mime
View raw message