incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cliff Schmidt" <>
Subject RE: The 50% Rule
Date Tue, 15 Jun 2004 02:53:44 GMT
Roy T. Fielding wrote on Monday, June 14, 2004 3:40 PM:

>> Personally, I'd like to see one or two quantitative rules (such as
>> one about independent committers to allow for vetoes) and then leave
>> the rest up to a voting body that will evaluate graduation against
>> some general guidelines.  I also think the voting body should be the
>> PPMC, which is made up of the project's committers, the PMC members
>> of the destination TLP (or the Board if destined to be a TLP
>> itself), and interested members of the Incubator PMC.  This means
>> that after meeting some minimum requirements, the project members
>> along with experienced members of the Apache community, who have
>> been watching and participating in the developing project, would
>> evaluate the overall health of the community and vote accordingly. 
>> Before Roy says anything ;-), I realize that the PPMC isn't part of
>> the Bylaws and therefore wouldn't mean anything official on its own,
>> but maybe that's where the Incubator PMC would ratify the PPMC's
>> decision with a vote in favor, assuming the basic process was
>> observed. 
> Not quite. The PPMC is a subgroup officially established by the
> incubator PMC, containing a named list of individuals who have agreed
> to participate on the PPMC.  

I think we need to make its status as an official subgroup of the 
incubator PMC more clear to everyone.  I believe the only reference to 
it is on the incubator wiki:
-- not in any policy doc on  

BTW, I'll volunteer to fix this if there's interest in committing to 
something a little more formal.  As a member of a project that has 
had to implement and use a PPMC, I've put some thought into this, 
although I already see changes I would make to my original proposal:

> As such, they are covered by the PMC
> clauses of the bylaws as far as decision-making goes.  The only
> difference is that the PPMC does not have the authority to release
> software on behalf of the ASF, whereas the PMC does.  Other than that,
> we want the PPMC to make its own decisions, including when to
> recommend a snapshot release and when to request exit from the
> incubator.
> The incubator PMC makes its own decisions based on that input, which
> isn't the same as ratifying someone else's decision.

Makes sense.  As long as the PPMC reports to the Incubator PMC, I suppose
they would be making a recommendation, not a decision to be ratified. 

> Before someone starts complaining about bureaucracy, please understand
> that the only reason a "corporation" differs from a sack of
> individuals, and thus individual liability, is because there is
> active group oversight of decisions made on behalf of the corporation
> for the sake of the corporation.  That applies for a nonprofit even
> more so than a for-profit, since our process has to be valid for both
> the Delaware corporate laws and the IRS guidelines.  The safest way
> to do that is 
> to assign responsibilities to specific committees and keep records
> of their decisions (and how those decisions were reached).

I completely understand the importance of this, but I'd like to ask 
another specific question about decision-making:

If committers don't make any legally significant decisions for the ASF 
(instead they decide things such as ongoing code changes, new committers, 
maybe project roadmaps?)...and PMCs make the legally significant 
decisions, as designated in the ASF Bylaws and the particular Board 
resolution that formed the PMC (decisions such as official ASF releases 
and changes to the charter)....what decisions, if any, does the PPMC 
make?  Or is the PPMC only ever recommending decisions to the PMC, each 
requiring a vote of first the PPMC and later the PMC?

> Personally, the only quantitative rule I want to see is at least
> three independent committers capable and willing to become the
> destination PMC.  The reason is because people tend to change jobs
> fairly frequently, especially when a new company decides they want
> to make a project part of their revenue stream *while* contributing
> to the open source side.  Companies should not face artificial
> barriers against hiring the developers who work on our projects.

Sounds like we're all in agreement here (at least all those who have
posted to the list in the last few days).


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

View raw message