> [ ] +1 Relaxed RTC
> [ ] +1 RTC with Lazy Consensus
> [X] +1 CTR with documentation guidelines
Cheers!
Hernan
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
