geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: [VOTE] Geronimo Development Process
Date Mon, 11 Sep 2006 14:04:50 GMT
 > [X] +1 CTR with documentation guidelines

We'll have to work extra hard to ensure that we hold each other to the 
communication standard ... but I think if we are diligent then this 
makes the most sense.

If the change is approved, I also recommend that we hold a public review 
of how we feel it is working after some reasonable amount of time 
(perhaps 2-3 months) to ensure that we're not drifting back into old habits.

Joe

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