Populating the initial PPMC

[Marvin Humphrey <ma...@rectangular.com>]

On Mon, Nov 18, 2013 at 3:41 AM, Andy Seaborne <an...@apache.org> wrote:
> I am concerned that it would be dis-empowering to the incoming community if
> at least the active and major developers of the podling were not on the PPMC
> at the start.

I don't see how we might divide up an "Initial Committer List" into "active
and major developers" and "everyone else", so I think it's all or nothing.
That gives us four ways to populate the initial PPMC:

1.  Mentors + Initial Commiter List
2.  Initial Committer List
3.  Mentors
4.  (empty)

With regards to whether voting in all project contributors is
"dis-empowering", I claim that it is precisely the opposite.  Going through
the exercise of bootstrapping the PPMC allows people who are new to the ASF to
become familiar with the ritual of personnel voting, and it provides a
framework for conversations about the "PPMC member" role and its
responsibilities, community development, recruitment and meritocracy.  In
contrast, the present system denies ASF novices such practical experience
until a new contributor wanders by.

To the extent that any dis-empowerment happens under this proposal, it is
exactly the same dis-empowerment which happens today: "active and major
developers" who bring codebases to Apache relinquish control and become one
vote among many on a PMC.  Subjecting such individuals to a vote on their
merit (which will surely pass) just reveals the truth to them sooner.

Perhaps with the truth laid bare, certain projects might not enter the
Incubator.  Do we care?  Regretful project founders who are unable to let go
have caused our communities a lot of grief, from both inside and outside
Apache.

Still, this isn't the hill I want to die on.  I think that starting with an
empty PPMC is good policy for a variety of reasons, but I'm willing to be
flexible for the sake of building consensus on how to address the truly
damaging dis-empowerment of PPMC members with regards to release votes.  If
an empty initial PPMC is a deal breaker for you, does it's removal unblock
your support for the rest of the proposal at <http://s.apache.org/atG>?

Marvin Humphrey

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

Re: Populating the initial PPMC

[Dave Fisher <da...@comcast.net>]

Dislike.

For small projects, PPMC == Committers is a great starting point.

For huge projects like OpenOffice something like this would have been chaos unleashed.

If it were 3 or 4 then I would not have volunteered to be a Mentor for Apache Flex.

To me the answer should remain somewhere between 1 and 2 - the status quo.

Regards,
Dave

On Nov 20, 2013, at 5:53 PM, Marvin Humphrey wrote:

> On Mon, Nov 18, 2013 at 3:41 AM, Andy Seaborne <an...@apache.org> wrote:
>> I am concerned that it would be dis-empowering to the incoming community if
>> at least the active and major developers of the podling were not on the PPMC
>> at the start.
> 
> I don't see how we might divide up an "Initial Committer List" into "active
> and major developers" and "everyone else", so I think it's all or nothing.
> That gives us four ways to populate the initial PPMC:
> 
> 1.  Mentors + Initial Commiter List
> 2.  Initial Committer List
> 3.  Mentors
> 4.  (empty)
> 
> With regards to whether voting in all project contributors is
> "dis-empowering", I claim that it is precisely the opposite.  Going through
> the exercise of bootstrapping the PPMC allows people who are new to the ASF to
> become familiar with the ritual of personnel voting, and it provides a
> framework for conversations about the "PPMC member" role and its
> responsibilities, community development, recruitment and meritocracy.  In
> contrast, the present system denies ASF novices such practical experience
> until a new contributor wanders by.
> 
> To the extent that any dis-empowerment happens under this proposal, it is
> exactly the same dis-empowerment which happens today: "active and major
> developers" who bring codebases to Apache relinquish control and become one
> vote among many on a PMC.  Subjecting such individuals to a vote on their
> merit (which will surely pass) just reveals the truth to them sooner.
> 
> Perhaps with the truth laid bare, certain projects might not enter the
> Incubator.  Do we care?  Regretful project founders who are unable to let go
> have caused our communities a lot of grief, from both inside and outside
> Apache.
> 
> Still, this isn't the hill I want to die on.  I think that starting with an
> empty PPMC is good policy for a variety of reasons, but I'm willing to be
> flexible for the sake of building consensus on how to address the truly
> damaging dis-empowerment of PPMC members with regards to release votes.  If
> an empty initial PPMC is a deal breaker for you, does it's removal unblock
> your support for the rest of the proposal at <http://s.apache.org/atG>?
> 
> Marvin Humphrey
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 


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

Re: Populating the initial PPMC

[ant elder <an...@gmail.com>]

On Thu, Nov 21, 2013 at 1:53 AM, Marvin Humphrey <ma...@rectangular.com>wrote:


> Still, this isn't the hill I want to die on.  I think that starting with an
> empty PPMC is good policy for a variety of reasons, but I'm willing to be
> flexible for the sake of building consensus on how to address the truly
> damaging dis-empowerment of PPMC members with regards to release votes.  If
> an empty initial PPMC is a deal breaker for you, does it's removal unblock
> your support for the rest of the proposal at <http://s.apache.org/atG>?
>
>

I think there are several problems with this approach.

One is that trying it for an already started podling _is_ disempowering.
You would have to go unsubscribe people from the private list and tell them
that they no longer have a voice in voting in new committers for their
project. That to me is just wrong.

Trying it for a new just starting up podling might work, which is why i
said previously try the experiment.  But i wouldn't like this to become a a
main stream approach. Remember what the main role of the PMC is - proposing
and voting for _and against_ new committers and PMC members. The point of
being able to veto PMC nominations is so you're not made to work with
someone you don't like or agree with. See the long post from Roy a while
ago about that.  Excluding podling participants from the PMC removes them
from those decisions.

This approach did happen a while ago to a podling, by accident not by
design when just them mentors ended up on the initial private list. They
voted in a new committer and announced it on the dev list, an argument
ensued where the others were surprised and angry about the choice, and the
result was everyone got added to the PPMC. Can't remember which, maybe
Cassandra if anyone wants to check the archives.

I think this is getting too hung up on vetting releases is the be all and
end all of PMC membership when really there are other just as if not more
important things. The way to teach new podling people about this is to
include them in the process while incubating, not exclude them.

   ...ant


I think this is getting to hung up on knowing how to make a release is the
be all and end all of PMC membership when thats jus