[VOTE RESULT] Geronimo Development Process

[Kevan Miller <ke...@gmail.com>]

All,
Thanks for your votes.

CTR with documentation guidelines was the unanimous choice by the  
community. The Geronimo Development Process will become CTR with  
documentation guidelines on Monday September 18 at 9AM EDT.

Multiple people mentioned that we'll need to be diligent to maintain  
appropriate community communication. This is certainly true.  
Committers still have a responsibility to communicate their changes  
to the community. We all have a shared responsibility to review these  
communications and commit logs.

There was also a desire to review our development process in 2-3  
months. This is a very good idea. Let's plan on initiating a review  
in early December (2 1/2 months). However, if you identify any  
problems with CTR, please raise them immediately. The sooner we deal  
with any issues, the better off we'll all be...

22 people registered +1 votes for CTR:

Davanum Srinivas
Rick McGuire
Jacek Laskowski
Guillaume Nodet
Matt Hogstrom
Paul McMahan
Joe Bohn
Sachin Patel
Hernan Cunico
Jeff Genender
Jason Dillon
David Jencks
Gianny Damour
Anita Kulshreshtha
David Blevins
John Sisson
Alan Cabrera
Jan Bartel
Dain Sundstrom
Hiram Chirino
Bill Dudney
Prasad Kashyap

By my count this includes (2 non-committers and 20 committers -- 14  
of which are PMC members)

--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