incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: an experiment
Date Fri, 13 Aug 2010 13:44:50 GMT

On 8/11/10 5:29 PM, Joe Schaefer wrote:
> ----- Original Message ----
>> From: Donald Woods <>
>> To:
>> Sent: Wed, August 11, 2010 5:19:03 PM
>> Subject: Re: an experiment
>> On 8/11/10 1:45 PM, Joe Schaefer wrote:
>>> So.  Following some  advice given to me by Sam Ruby,
>>> I'd like to start experimenting with  different organizational
>>> and procedural approaches to the projects I  participate in
>>> here.  What I want to do is to see how far I can  push
>>> the envelope on the whole notion of empowerment and 
>>>  self-governance in an incubating project, following the
>>> lessons I've  learned from httpd's treatment of the subprojects
>>> it happens to be  responsible for.
>>> The first idea should be fairly  straightforward: that for
>>> the projects I participate in (so far thrift  and sis), that
>>> the IPMC delegates to the PPMC the decision-making  process
>>> for voting in new committers: basically rolling back the  clock
>>> to May 1, 2007 on guides/ppmc.html.
>> How about requiring at  least one mentor on the vote, so there is still
>> some oversight?
> I'm actually not in favor of that idea because relatively few
> mentors are active developers in their projects (I'm certainly
> in that category).  Part of what I'm trying to teach is that
> self-governance requires active participants to be making the
> critical decisions. 
> OTOH I would be perfectly OK with the idea that a mentor must
> file the account request, or more simply must submit an ACK request
> regarding the vote to either general@incubator or private@incubator.

Sounds like a good solution for accounts, but I'd still like to see at
least one mentor vote required on release artifacts, as the mentors
agreed to step up and guide/teach podlings about the Apache Way, which
includes using RAT and IANAL plugins to ensure license headers on the
code and license/notice/disclaimer artifacts in the released artifacts.

>>> The second idea is more controversial: to hold IPMC votes to
>>>  admit all significant committers to those projects to the IPMC
>>>  itself.  The purpose of this concept is to allow those who
>>> best  know the codebase to provide IPMC oversight over it, 
>>> especially as it  pertains to releases.
>> Would still like this to be an opt-in, where any  existing PMC member
>> interested in helping with the Incubator could request  membership and be
>> added after 72 hours (expanding ASF member rules to apply  to all PMC
>> members.)
> Are you referring to ASF members here?  PMC members themselves who
> are not ASF members must be voted in by the IPMC to gain IPMC membership.
> ASF members interested in IPMC membership need only notify the chair
> of their intentions.  I don't expect any of that to change with what
> I'm proposing.
>>  For committers (non-PMC members), I'd want an  existing IPMC
>> or PMC member nominate the person to the IPMC and require a  72hr lazy
>> consensus, since IPMC members are expected to mentor and teach  new
>> podlings about the Apache way.
> I would expect a more formal process of consensus voting for IPMC
> membership in the case of a podling committer, ie 3 +1's and no
> vetoes.  The vote would be held on private@incubator naturally.


> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message