Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Message-ID: <4522C5A6.8010400@rowe-clan.net>
Date: Tue, 03 Oct 2006 15:18:46 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 1.5.0.7 (X11/20060913)
MIME-Version: 1.0
To: general@incubator.apache.org
Subject: Re: Policy on Initial Committership
References: <NBBBJGEAGJAKLIDBKJOPAENAKKAC.noel@devtech.com>
In-Reply-To: <NBBBJGEAGJAKLIDBKJOPAENAKKAC.noel@devtech.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Noel J. Bergman wrote:
> 
> Putting the process of Committership into the hands of the people managing
> the project is the best solution to both.

-1.  Putting initial committership, in the hands of the proposer and
people they accept on educated trust is the right answer, along with
the mentors.

If I propose a project, it's my proposal.  If I have two coproposers, it's
our proposal.  The moment it's -accepted- it's no longer (our) project,
but the ASF's.

While it's in the proposal stage, only the submittor(s) should be changing
anything, and that includes initial participants.  And that -should- include
every individual who's contributed to any incoming code.

Friendly amendments are always welcome, that includes initial participants,
and we've found that most projects are amiable to them.

But from the time it launches anyone earns merit; anyone can be considered
based on their contributions.  Mentors are there to ensure the process is
equitable.

Are we trying to avoid 'hurt feelings'?  Earn merit, or submit a competing
project to the incubator.  Don't stamp your name on another's proposal for
'free' commit access.


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