On 1/17/2001 at 11:17 PM Craig R. McClanahan wrote:
> Many of those rules and conventions are documented (such as the rules
on voting), but some are not. One of the things I took away from the
PMC meeting yesterday is the need to better articulate those rules.
As a new committer to another Jakarata project, I personally think that
would be very helpful.
There seem to be many deep conventions in play here that I cannot find
in a reading of the ASF by-laws or the project guidelines. So far, the
only documentation I've found is <
http://jakarta.apache.org/site/guidelines.html > and <
http://www.apache.org/foundation/bylaws.html >. Apparently, there is
also a "Rules for Revolutionaries" document, but I haven't been able to
find it. (URL?)
Although I probably don't understand all the nuances of the "Apache
Culture", as a Jakarta Committer, here is a draft "patch" that I would
suggest to decisions.html (mostly parity-checks):
--
Voting
Any Developer or Committer may call for a Vote on the Developer mailing
list. It is preferred that a Vote be preceded by a formal proposal
offered for discussion purposes. A call for a formal Vote must contain
the legend "[VOTE-action item]" in its subject line, where "action
item" is Release Plan, Public Release, Showstopper, or Product Change.
A * Public Release * Vote is not binding until the individual who
tendered the Vote posts a followup message with the legend
"[VOTE-RESULT]" summaring the replies. Any other Vote that receives any
binding -1 reply (later withdrawn or not) must also post a
"[VOTE-RESULT]" message to be binding. All Votes receiving only +1 or
+/-0 replies are subject to lazy approval. Any question regarding the
outcome of a Vote may be refrerred by a Committer to the PMC for
arbitration.
All votes by Committers should include the word "binding" next to their
vote. When tendering a -1 vote on a Consensus item, a Committer should
include the phrase "binding veto" next to their Vote, to make their
intent clear.
Persons wishing to discuss a Vote before replying, may open a
"[VOTE-ISSUES]" thread, to help eliminate premature vetos.
Other Action Items
When announcing their Short Term Plans or Long Term Plans, developers
should include the legend "[ANN-action item]" in the subject line of
their message to the Developers list.
Proposals are not a formal Action Item, but should be labeled
"[PROPOSAL]" in their subject line.
Action Item Voting Types
Note "Lazy" means that is not required to tally the votes, unless a -1
reply is posted. All votes are lazy except for a public Release vote.
Long Term Plans - No vote required.
Short Term Plans - No vote required.
Release Plan - Lazy Majority vote on each issue.
Release Testing - Consensus vote before public Release.
Showstoppers - Lazy consensus until resolved and removed from status
file.
Product Change - Lazy consensus.
--
>If the vote is about a change to the source code or documentation and
the primary author is a Developer and not a Commiter, the primary
author of what is being changed may also cast a binding vote on that
issue.
I would consider striking this, as I believe Committer status on
Jakarta may be easier to get than on Apache, and there is less of a
need for this exception.
--
> that I will *not* veto a release plan for 3.3 that meets my concerns
about support)
Here's another place where it gets confusing. Technically, it seems
that we can't "veto" a Release Plan, since it is a Majority Vote.
(Though, you might be able to veto a specific issue, if it involved a
Product Change.) Someone could ultimately veto a public "Release" since
that is a Consensus Vote.
The cultural idea being, I guess, that this is a meritocracy, and
nothing can be binding until we have the actual code in front of us.
Another nit is that the all-important public release is not listed as
an Action Item, although it is implied by the description of Release
Plan and Showstoppers.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
