[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-general
Subject:    Proposed Update to the Guidelines
From:       "Ted Husted" <news.ted () husted ! com>
Date:       2001-01-29 12:32:13
[Download RAW message or body]

I reviewed the original Apache guidelines <
http://dev.apache.org/guidelines.html >, and noted that the following
passages are ommitted from the Jakarta version. There are the only
ommissions I noted. I've changed the text to show how they would read
in a Jakarta context, and noted those changes in [square brackets].
I've included the headings from the original for reference, but only
the text omitted from that heading.

These passages may help address issues that have come up here:

--

People

A [Committer] is considered inactive by their own declaration or by not
contributing in any form to the project for over six months. An
inactive [Committer] can become active again by reversing whichever
condition made them inactive (i.e., by reversing their earlier
declaration or by once again contributing toward the [sub]project's
work). [Committer status] can be revoked by a unanimous vote of all the
active [Committers] other than the [Committer] in question.

Status

Many issues will be encountered by the [sub]project, each resulting in
zero or more proposed action items. Issues should be raised on the
mailing list as soon as they are identified. Action items must be
raised on the mailing list and added to the relevant STATUS file. All
action items may be voted on, but not all of them will require a formal
vote.=A0

Voting

Since we are all volunteers, [Committers] often become inactive for
periods of time in order to take care of their "real jobs" or devote
more time to other projects. It is therefore unlikely that [every
Committer] will vote on every issue. To account for this, all voting
decisions are based on a minimum quorum.=A0

<.../>

An action item requiring majority approval must receive at least 3
binding +1 votes and more +1 votes than -1 votes [we omit the
following:] (i.e., a majority with a minimum quorum of three positive
votes).

<.../>

Votes are tallied within the STATUS file, adjacent to the action item
under vote. All votes must be either sent to the mailing list or added
directly to the STATUS file entry for that action item.=A0

--

These passages from the original may also  be helpful in communicating
the Apache culture:

--

Long Term Plans

In general, it is always better to hear about alternate plans prior to
spending time on less adequate solutions.=A0

Short Term Plans

This is a good way to proactively avoid conflict and possible
duplication of work.=A0

When to commit a change

Ideas must be review-then-commit; patches can be commit-then-review.=A0

--

Finally, I'm not sure whether some of these references might represent
a maintenance hardship or not:

Action Items

Product Changes=A0
Changes to the Jakarta products, including code and documentation, will
appear as action items under several categories corresponding to the
change status:=A0

+ concept/plan - An idea or plan for a change. These are usually only
listed in STATUS when the change is substantial, significantly impacts
the API, or is likely to be controversial. Votes are being requested
early so as to uncover conflicts before too much work is done.=A0

+ proposed patch - A specific set of changes to the current product in
the form of input to the patch command (a diff output).=A0

+ committed change - A one-line summary of a change that has been
committed to the repository since the last public release.=A0

All product changes to the currently active repository are subject to
lazy consensus. All product changes to a prior-branch (old version)
repository require consensus before the change is committed.=A0

When to Commit

Each developer is responsible for notifying the mailing list and adding
an action item to STATUS when they have an idea for a new feature or
major change to propose for the product. The distributed nature of the
Jakarta project requires an advance notice of 48 hours in order to
properly review a major change -- consensus approval of either the
concept or a specific patch is required before the change can be
committed. Note that a [Committer] might veto the concept (with an
adequate explanation), but later rescind that veto if a specific patch
satisfies their objections. No advance notice is required to commit
singular bug fixes.=A0

--

Pending negative comments, I would suggest we add this back into the
text in a Navy font. 

Meanwhile:

> "An action item requiring majority approval must receive at least 3
binding +1 votes and more +1 votes than -1 votes(i.e., a majority with
a minimum quorum of three positive votes)."

Originally, the Apache Group provided that they could brevet a
Developer (using our terms) to Committer status for a particular vote,
so, in that case, a Developer could cast a binding +1 vote. Since
Committer status is easier to earn here, we have already discussed
striking that provision, and so should now also strike the word
"binding" as redundant. 

I would also suggest that we replace the word "positive" with +1
whereever it appears, UNLESS +0 can be considered "positive".


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]