geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: [VOTE] Geronimo Development Process
Date Wed, 13 Sep 2006 13:31:42 GMT
Keep the votes coming...

The vote has been active for 2 1/2 days. I'll plan on giving it 2  
more days. Unless there are objections, I'll end the vote on Friday,  
Sept 15 at 9 AM EDT.

--kevan

On Sep 10, 2006, at 9:23 PM, 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