Re: Proposed Update to the Guidelines

[Ted Husted <ne...@husted.com>]

Perhaps this would be a good time to complete the proposed update to
the guidelines. 

The current draft proposal, which has been stable since it was posted
two weeks ago, is at 

< http://jakarta.apache.org/site/proposal.html >

I would respectfully request a poll of the PMC members, and any other
interested committers, as to whether the current draft is acceptable. 

If so, I would also bring up these remaining points:

<quote> "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)." </quote>

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".

Finally, I would suggest that we incorporate the language annexed to
this message, which is taken from the original guidelines.  Its my
feeling that putting this language back into the guidelines may help to
avoid future conflicts.

I would then suggest removing the strikeout and blueline from the
proposal, so that the PMC would be able to consider a vote as to
whether the proposal draft should be accepted.

*********** REPLY SEPARATOR  ***********

On 1/29/2001 at 7:32 AM Ted Husted wrote:
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. 

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. 

<.../>

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. 

--

Long Term Plans

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

--

Short Term Plans

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

--

Action Items

Product Changes 

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

+ 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. 

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

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

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. 

--

When to commit a change

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

--

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. 

--



-- 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/

Re: Proposed Update to the Guidelines

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Ted Husted wrote:

> On 2/10/2001 at 12:40 AM Conor MacNeill wrote:
>
> >Also, in the paragraph below, does "more +1 votes than -1 votes" imply
> only
> >binding +1/-1 votes. For example say there is a vote and 3 committers
> vote
> >+1 and four non-committers vote -1, what would happen?
>
> That's why I want to remove the word binding. Right now, it does sound
> like anyone's -1's might count ;-).
>
> In context, the prior statement "All Developers are encouraged to
> participate in decisions, but the decision itself is made by those that
> have Committer status in the Project" falls through and removes the
> ambiguity. Only the votes of Committers are actually tallied.
>
> Alternatively, I would suggest that we include the binding modifier
> wherever it would apply, making the language
>
> >"An action item requiring majority approval must receive at
> >least 3 binding +1 votes and more binding +1 votes than
> >binding -1 votes (i.e., a majority with a minimum quorum
> >of three positive votes)."
>

I like that one better, even though "inherited meaning" would be more o-o
oriented :-).

> -- 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/
>

Craig

Re: Proposed Update to the Guidelines

[Ted Husted <ne...@husted.com>]

On 2/10/2001 at 12:40 AM Conor MacNeill wrote:

>Also, in the paragraph below, does "more +1 votes than -1 votes" imply
only
>binding +1/-1 votes. For example say there is a vote and 3 committers
vote
>+1 and four non-committers vote -1, what would happen?

That's why I want to remove the word binding. Right now, it does sound
like anyone's -1's might count ;-).

In context, the prior statement "All Developers are encouraged to
participate in decisions, but the decision itself is made by those that
have Committer status in the Project" falls through and removes the
ambiguity. Only the votes of Committers are actually tallied. 

Alternatively, I would suggest that we include the binding modifier
wherever it would apply, making the language 

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


-- 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/

Re: Proposed Update to the Guidelines

[Conor MacNeill <co...@cortexebusiness.com.au>]

Ted,

----- Original Message -----
From: "Ted Husted" <ne...@husted.com>
>
> 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.

Not sure why you see binding as redundant. Even removing the concept of a
breveted developer, anyone is allowed to vote but only a committer's vote
is binding.

Also, in the paragraph below, does "more +1 votes than -1 votes" imply only
binding +1/-1 votes. For example say there is a vote and 3 committers vote
+1 and four non-committers vote -1, what would happen?

"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)."

Perhaps we should rewrite the guidelines as a piece of code, so we can all
understand it. We could just run it to sort out any ambiguities :-)

Conor