incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <>
Subject Re: Inviting new committers to a podling
Date Tue, 01 May 2018 22:23:47 GMT
On Mon, Apr 30, 2018 at 4:50 PM, Craig Russell <> wrote:
> I would respectfully suggest that the PPMC guide section that describes how to invite
new committers and PPMC members is not adequate to the task.
> This is what I think is the relevant section of
> There are no ASF wide rules on how to decide when to make someone a committer, podlings
need to agree an approach that works for them. Some ASF projects have a high bar requiring
significant contributions before someone is considered, other projects grant it more freely
to anyone who shows interest in contributing. Some projects use formal [DISCUSS] and [VOTE]
threads on the private mailing list, others use a more lazy consensus approach. For more information
see, commit access and the ASF How it Works document, which explains meritocracy and roles.
> Once the decision has been made the proposer offers committership to the nominee. If
the nominee accepts the responsibility of being a committer for the project, the nominee formally
becomes an Apache committer.
> The proposer then asks an Incubator PMC member (typically one of the mentors) to follow
the documented procedures to complete the
process. If the nominee is already an Apache committer on another project, the Incubator PMC
member simply updates the SVN authorization settings to include the nominee as a committer
on the podling.

To me the biggest problem with the above is that it actually fails
to communicate the point that establishing these types of basic
principles of how to self-govern is, in fact, part of a succesful
incubation process.

As a community you may very well arrive at a process that's
very different from the rest of the ASF's TLPs, but it has to
be well understood. Worst possible thing for a community
is to keep changing these types of goal posts.

In addition to that -- it is a job of mentors to actually make
sure that a podling community converges on a reasonable process.

Now a few comments:

> I suggest that we look again at this section for these aspects:
> 1. We should document how we expect podlings to discuss, vote, and invite committers
and PPMC members. The paragraph describing how to decide on new committers should be non-prescriptive
with regard to the criteria, but prescribe the process. If a podling doesn't want to follow
the process of discussing, voting, and inviting, it should explicitly document what it wants
to do so that its unique process can be incorporated into the project's unique Project By-Laws.
But most podlings will want to follow the processes of most TLPs:
> a: discuss in private the desire to invite a new committer/PPMC member
> b: hold a vote in private, with +1, -1, +0 and -0
> c: end the vote when all PPMC members have voted, or at least 72 hours have passed; with
at least three binding (IPMC members) votes in favor, and no -1 votes

I agree in principle, but it all depends on how this is worded. Like I said
above -- I think it would be totally fine to tell the podling -- look how
the rest of the PMCs are functioning. At the same time -- I've had a
series of unfortunate experiences where anything that we write on
that page gets quoted back to you as immutable dogma. We should
avoid that.

Once again -- we really should make sure that mentors understand
that this is their responsibility to make sure these types of things
are understood by a PPMC (but, of course, something like this is
much easier said than done :-().

> 2. We should document the process in the guide and *not* refer to the page that describes
how PMCs invite new committers. The processes are different in the case of podlings and it
is simply confusing to mix them. Podlings especially could use help with "standard" emails
similar to those found here:

Big +1 here!

> 3. It is not obvious what the policy is for a podling to invite new committers and PPMC
members. I don't believe it should be the responsibility of the podling to decide in isolation
the process to invite new committers, just as it is not the podlings' decision how to invite
new PPMC members.

I actually don't quite understand this point. Care to elaborate?


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

View raw message