geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: [VOTE] Geronimo Development Process
Date Thu, 14 Sep 2006 14:02:49 GMT
[X] +1 CTR with documentation guidelines


On 9/10/06, Kevan Miller <kevan.miller@gmail.com> 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
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message