Re: Inviting new committers to a podling

[Bertrand Delacretaz]

Hi,

Two small additions to Dave's list:

On Wed, May 2, 2018 at 3:40 AM, Dave Fisher  wrote:
> (1) Discuss, propose and approve on private@. Provide permalink to threads on 
> whimsy.
> (2) In case of PPMC then ACK to IPMC.
> (3) Invite individual to role using email templates. PPMC may develop their 
> own version.
> (4) New committer submits and secretary records ICLA if needed.
> (5) Create account if new. ...

(6) Add the new account ID to https://whimsy.apache.org/roster/ppmc/
with the appropriate roles

(7) Announce the newly elected people on your dev list. As a
tradition, invite them to introduce themselves there.

That last point is more a community thing, so not policy obviously.

-Bertrand

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

Re: Inviting new committers to a podling

[Dave Fisher]

Hi Craig,

I can see that in order for the secretary and incubator governance to scale we 
need a prescriptive process in terms of steps which can have whimsical tooling.

(1) Discuss, propose and approve on private@. Provide permalink to threads on 
whimsy.

(2) In case of PPMC then ACK to IPMC.

(3) Invite individual to role using email templates. PPMC may develop their own 
version.

(4) New committer submits and secretary records ICLA if needed.

(5) Create account if new.

I think it is important to discuss the text and I would invert the description 
to emphasize easiest trust situations first and include some guidance. Small 
TLPs last better with a lower bar. Smaller podlings do better with PPMC and 
Committer being the same list.

I think it will help the Foundation scale.

Regards,
Dave

Sent from my iPhone

> On May 1, 2018, at 6:14 PM, Craig Russell  wrote:
> 
> Hi Roman,
> 
> Thanks for the feedback.
> 
>>> On May 1, 2018, at 3:23 PM, Roman Shaposhnik  wrote:
>>> 
>>> 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?
> 
> The policy appears to be: invite to be a committer whoever you want as long 
> as you can get a mentor to request the account. "There are no ASF wide 
> rules..." There are a few extra steps in the case of inviting a new PPMC 
> member. I think we can do better to guide the podling to adopt a process that 
> is in use by the great majority of TLPs.
> 
> It is fine if a TLP has a very casual approach to committers. Some, who came 
> to Apache after establishing their community processes, will invite a 
> committer by one PMC member sending an email and receiving no negative 
> responses. This is consistent with the Apache Way but I don't think it is a 
> good example for others.
> 
> It is much more scalable and easier to provide tooling if a TLP actually does 
> follow a script: discuss, vote, invite. And I believe that we should 
> encourage podlings to follow a script until they decide they don't like it 
> and are willing to document their decision in their project bylaws when they 
> graduate.
> 
> Regards,
> Craig
> 
>> Thanks,
>> Roman.
> 
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org http://db.apache.org/jdo
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

Re: Inviting new committers to a podling

[Craig Russell]

Hi Roman,

Thanks for the feedback.

> On May 1, 2018, at 3:23 PM, Roman Shaposhnik  wrote:
> 
>> 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?

The policy appears to be: invite to be a committer whoever you want as long as 
you can get a mentor to request the account. "There are no ASF wide rules..." 
There are a few extra steps in the case of inviting a new PPMC member. I think 
we can do better to guide the podling to adopt a process that is in use by the 
great majority of TLPs.

It is fine if a TLP has a very casual approach to committers. Some, who came to 
Apache after establishing their community processes, will invite a committer by 
one PMC member sending an email and receiving no negative responses. This is 
consistent with the Apache Way but I don't think it is a good example for 
others.

It is much more scalable and easier to provide tooling if a TLP actually does 
follow a script: discuss, vote, invite. And I believe that we should encourage 
podlings to follow a script until they decide they don't like it and are 
willing to document their decision in their project bylaws when they graduate.

Regards,
Craig

> Thanks,
> Roman.

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org http://db.apache.org/jdo


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

Re: Inviting new committers to a podling

[Roman Shaposhnik]

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 
> https://incubator.apache.org/guides/ppmc.html :
>
> 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 
> http://www.apache.org/dev/pmc.html#newcommitter 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: 
> http://community.apache.org/newcommitter.html#new-committer-process

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?

Thanks,
Roman.

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

Re: Inviting new committers to a podling

[Carlos Santana]

Hi Craig

In general I agree with:
- Document more details about the process
- Add standard templates for inviting, accepting and welcoming emails to
nominee

I think the process currently describe it works and I don't see why the
need for the change
https://incubator.apache.org/guides/ppmc.html
Section: Adding new committers
Section: Voting in a new PPMC member

We have followed this process for some recent members we added to OpenWhisk.

For PPMC members:
We held a vote on ppmc private, give the minimum 72 hours for the vote, and
close the vote when there are 3 or more votes.
But we don't require ALL members to vote +1 to move forward, this would be
extremely difficult to get ALL votes.
Then we do the [NOTICE] to IPMC private list as indicated in the process
doc, with a minimum of 72 hours to hear back from IPMC on any objections
this takes care of the PPMC member being added in isolation by the PPMC.
Once more than 72 hours has pass and not negative feedback from IPMC we
send invitation to new member, they accept, mentor requires Apache account.

For Committers members:
We follow similar process as ppmc new member.
We held a vote on ppmc private, give the minimum 72 hours for the vote, and
close the vote when there are 3 or more votes.
But we don't require ALL members to vote +1 to move forward, this would be
extremely difficult to get ALL votes.
Once more than 72 hours has pass and not negative feedback from IPMC we
send invitation to new member, they accept, mentor requires Apache account.

The only difference is we don't send an email [NOTICE] to private IPM for
them to evaluate the nominee and reject in 72 hours.

Would adding the step to send a [NOTICE] to private IPMC for Committers
would address your concerns?

I would be against changing the documented process to be more strict, to
require ALL PPMC members to vote +1, and at least 3 +1 IPMC to vote get
someone added as a Committer or PPMC member.

-- Carlos


On Mon, Apr 30, 2018 at 7: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
> https://incubator.apache.org/guides/ppmc.html :
>
> 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
> http://www.apache.org/dev/pmc.html#newcommitter 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.
>
> 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
>
> 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: http://community.apache.org/newcommitter.html#new-committer-process
>
> 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