On Sep 11, 2006, at 3:45 PM, David Jencks wrote:
[X] +1 CTR with documentation guidelines
I'm worried that we will not maintain enough awareness of each
others work, and think we all need to be very vigilant. I agree
with Joe that we need to review how we are doing in a reasonable
amount of time (2-3 months, less if there are obvious problems)
[X] +1 CTR with documentation guidelines
And to clarify, my proposal was actual for CTR w/optional RTC with
Lazy Consensus, where we as a community agree RTC with Lazy Consensus
is encouraged in the following situations:
On Aug 23, 2006, at 1:14 PM, David Blevins wrote:
I'm inclined to say "at your discretion" where the following are
encouraged:
- Significant new functionality
- Significant changes
- Patches from Contributors
- Borderline "fixes" to a stable branch
This is still my preferred verbiage.
-David
thanks
david jencks
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
