Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Reply-To: <bloritsch@citi-us.com>
From: "Berin Loritsch" <bloritsch@citi-us.com>
To: "'Avalon Developers List'" <avalon-dev@jakarta.apache.org>
Subject: RE: [PMC:VOTE] PMC Voting Process
Date: Thu, 9 Jan 2003 15:37:45 -0500
Message-ID: <000501c2b81e$f7f89bb0$f700a8c0@acsdom1.citius.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <3E1DA6F2.1090206@apache.org>
Importance: Normal

> From: news [mailto:news@main.gmane.org]On Behalf Of Leo Simons
>
> Hi all,
>
> Leo Simons wrote:
> > I tweaked my original "layman text" a bit to describe the actual
> > procedure as we're following it atm. The proposal is we adopt it.
> > Comments welcome; I'll put it up for vote when peeps get back from
> > holiday. (I really feel like wrapping this stuff up sooner
> than later,
> > but I'm relatively sure Steve'll have something to say ;)
>
> I hereby propose we adopt the text below as a our voting
> guidelines, add
> these guidelines to the avalon project documentation, to completely
> replace the current (invalid) procedures and policies which
> were voted
> upon under the thread "[VOTE] PMC Voting Policies and
> Procedures" on the
> avalon pmc list.
>
> I believe the proposal lays down in clear simple wording the actual
> de-facto practices followed.
>
> I volunteer to administer the vote, add up the results and notify the
> community, and put the document up on the website if it is
> accepted (ie
> do as described in the proposed text).
>
> Note that although this is a PMC vote everyone is welcome to comment.
>
> PMC members, please cast your votes (on the avalon development list).
>
> here's mine: +1.


Leo-- I believe that the Voting procedures we previously voted on
required that all [VOTE]s had to start as a [PROPOSAL].

I like easily read documents.  They foster the attitude of following
the _spirit_ of the document as opposed to the _letter_ of the
document.  The more loopholes you try to cover the more someone
somewhere will find.

However, at this time I have to put forth a -1, because it is not
something that was formally proposed before a call for vote.

The reason for the proposal->vote procedure is to provide as much
fine tuning of the document as possible.  We cannot vote on a
document that is currently changing.  How would we know which one
we are voting on?

I am for the effort that you are trying to lay down here.  However,
we need the opportunity to fine tune the document so that it basically
says the same thing that our last one did--just without the formalism.
At that point, the vote is usually academic.

Can we go through a formal Proposal before a call to vote on this?

I would also place the most current form of the proposal on the WIKI.
If you want a WIKI with version control, SubWIKI is placed on
cvs.apache.org/wiki
which we would be able to refer to a specific version if necessary.
It is backed by SubVersion, and seems to respond more quickly than
the one on Nagoya.  Just be sure to post the link and the text.

The WIKI markup also looks pretty decent and readable as text,
so if you write it up there, and copy the text in an email, it
makes it easier on you to maintain one copy.


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>