Re: retiring/removal of committers

[Thomas Nadeau]

Jakob/John/Suneel:

Thanks for the perspective. Its important for the community
to understand the philosophy of how Apache operates, which
your notes have done - at least for me. 

—Tom



> On Nov 29, 2017, at 8:57 PM, Jakob Homan  wrote:
> 
> This was an explanation I had previously sent to another podling I mentor:
> 
> 
> (Merit never expiring)  is not a bug.  As ASF sees it, this is a feature:
> https://www.apache.org/dev/committers.html (search for Merit Never
> Expires, an ASF axiom).  As a volunteer organization, we cannot
> require anyone to do anything on any time frame.  Inactive committers
> are in no way a drag on the community.  Instead they are a resource
> that can often be activated when needed with a simple ping.  By virtue
> of having been elected committers or PMCers, they are trusted to know
> when and how to engage with the community when they are able to and in
> such a way that keeps it healthy.  For example, if you've not been
> active for a year, suddenly showing up and +1ing a megabyte patch in a
> bit of code you were never involved in would be a jerk thing to do and
> committers are trusted not to be jerks.  A very large pool of
> committers, of varying activity and contribution is the goal here -
> not a tight, exclusionary group of focused (probably paid) 10x-ers...
> 
> -Jakob
> 
> On 29 November 2017 at 14:42, John D. Ament  wrote:
>> There is one out.  When a podling graduates, its customary to keep everyone
>> on.  However, if there are people who are no longer interested in the
>> project and the project chooses to not include them, its not uncommon that
>> they be left off the graduation.  They would still be open to be included
>> later on if they contribute once again.
>> 
>> John
>> 
>> On Wed, Nov 29, 2017 at 4:26 PM Thomas Nadeau  wrote:
>> 
>>> 
>>>I think that is why we were having it - no one knew about Apache’s
>>> rules around this.
>>> That seems to settle the matter: once you are in, you are in.
>>> 
>>>—Tom
>>> 
>>> 
 On Nov 29, 2017, at 3:42 PM, Suneel Marthi 
>>> wrote:
 
 Fyi... committership never expires in ASF, unless the committer chooses
>>> to
 go Emeritus. So not sure if this discussion is needed.
 
 On Wed, Nov 29, 2017 at 3:23 PM, Thomas Nadeau 
 wrote:
 
> 
>   One action I took from the last grooming meeting was to
> investigate with the community, what process and policies we want to use
> around the retirement and/or removal of Committers on the project. As
>>> our
> mentors have told us before, the community here is empowered to decide
>>> the
> criteria for how people are voted as committers, and the implication is
> that the reverse is true too. However, after discussing this on our call
> this week, it doesn’t seem there is any criteria defined; therefore, I
> wanted to open up the discussion on this.
> 
>   To start, The Apache PMC guide says this about removal of
> Committers/PMC members:
> 
> [http://www.apache.org/dev/pmc.html#pmc-removal <
> http://www.apache.org/dev/pmc.html#pmc-removal>]
> 
> Projects can establish their own policy on handling inactive members, as
> long as it is applied consistently.
> 
> It is not a problem to retain members of the PMC who have become
>>> inactive,
> and it can make it easier for them to stay in touch with the project if
> they choose to become active again.
> 
> Typically, PMC members who are no longer able to participate will resign
> from the PMC. However, if a PMC chooses to remove one of its members
>>> (i.e.
> without that member's consent), then it must request the Board to make
>>> that
> decision (which is typically done with a resolution at the Board's next
> meeting). The PMC chair should send and email to the board@ mailing
>>> list
> detailing the request for removal and the justification the PMC has for
> that removal, and cc: the project's private@ list.
> 
> 
>   So with that in mind, it looks like we need to augment the
> guidelines Tal started on the wiki [https://cwiki.apache.org/
> confluence/display/ARIATOSCA/Becoming+a+Committer <
> 
>>> https://cwiki.apache.org/confluence/display/ARIATOSCA/Becoming+a+Committer
 ]
> to include removal/retirement/inactive PMC/committers.
> To get the ball rolling, I wanted to make some suggestions for
> (de)selection criteria that I’ve used in other OSS projects:
> 
>   Open Daylight uses this process:
> 
> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process <
> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process>
> 
>   OPNFV uses this:
> 
> https://wiki.opnfv.org/display/DEV/Committer+Removal <
> 

Re: retiring/removal of committers

[Jakob Homan]

This was an explanation I had previously sent to another podling I mentor:


(Merit never expiring)  is not a bug.  As ASF sees it, this is a feature:
https://www.apache.org/dev/committers.html (search for Merit Never
Expires, an ASF axiom).  As a volunteer organization, we cannot
require anyone to do anything on any time frame.  Inactive committers
are in no way a drag on the community.  Instead they are a resource
that can often be activated when needed with a simple ping.  By virtue
of having been elected committers or PMCers, they are trusted to know
when and how to engage with the community when they are able to and in
such a way that keeps it healthy.  For example, if you've not been
active for a year, suddenly showing up and +1ing a megabyte patch in a
bit of code you were never involved in would be a jerk thing to do and
committers are trusted not to be jerks.  A very large pool of
committers, of varying activity and contribution is the goal here -
not a tight, exclusionary group of focused (probably paid) 10x-ers...

-Jakob

On 29 November 2017 at 14:42, John D. Ament  wrote:
> There is one out.  When a podling graduates, its customary to keep everyone
> on.  However, if there are people who are no longer interested in the
> project and the project chooses to not include them, its not uncommon that
> they be left off the graduation.  They would still be open to be included
> later on if they contribute once again.
>
> John
>
> On Wed, Nov 29, 2017 at 4:26 PM Thomas Nadeau  wrote:
>
>>
>> I think that is why we were having it - no one knew about Apache’s
>> rules around this.
>> That seems to settle the matter: once you are in, you are in.
>>
>> —Tom
>>
>>
>> > On Nov 29, 2017, at 3:42 PM, Suneel Marthi 
>> wrote:
>> >
>> > Fyi... committership never expires in ASF, unless the committer chooses
>> to
>> > go Emeritus. So not sure if this discussion is needed.
>> >
>> > On Wed, Nov 29, 2017 at 3:23 PM, Thomas Nadeau 
>> > wrote:
>> >
>> >>
>> >>One action I took from the last grooming meeting was to
>> >> investigate with the community, what process and policies we want to use
>> >> around the retirement and/or removal of Committers on the project. As
>> our
>> >> mentors have told us before, the community here is empowered to decide
>> the
>> >> criteria for how people are voted as committers, and the implication is
>> >> that the reverse is true too. However, after discussing this on our call
>> >> this week, it doesn’t seem there is any criteria defined; therefore, I
>> >> wanted to open up the discussion on this.
>> >>
>> >>To start, The Apache PMC guide says this about removal of
>> >> Committers/PMC members:
>> >>
>> >> [http://www.apache.org/dev/pmc.html#pmc-removal <
>> >> http://www.apache.org/dev/pmc.html#pmc-removal>]
>> >>
>> >> Projects can establish their own policy on handling inactive members, as
>> >> long as it is applied consistently.
>> >>
>> >> It is not a problem to retain members of the PMC who have become
>> inactive,
>> >> and it can make it easier for them to stay in touch with the project if
>> >> they choose to become active again.
>> >>
>> >> Typically, PMC members who are no longer able to participate will resign
>> >> from the PMC. However, if a PMC chooses to remove one of its members
>> (i.e.
>> >> without that member's consent), then it must request the Board to make
>> that
>> >> decision (which is typically done with a resolution at the Board's next
>> >> meeting). The PMC chair should send and email to the board@ mailing
>> list
>> >> detailing the request for removal and the justification the PMC has for
>> >> that removal, and cc: the project's private@ list.
>> >>
>> >>
>> >>So with that in mind, it looks like we need to augment the
>> >> guidelines Tal started on the wiki [https://cwiki.apache.org/
>> >> confluence/display/ARIATOSCA/Becoming+a+Committer <
>> >>
>> https://cwiki.apache.org/confluence/display/ARIATOSCA/Becoming+a+Committer
>> >]
>> >> to include removal/retirement/inactive PMC/committers.
>> >> To get the ball rolling, I wanted to make some suggestions for
>> >> (de)selection criteria that I’ve used in other OSS projects:
>> >>
>> >>Open Daylight uses this process:
>> >>
>> >> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process <
>> >> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process>
>> >>
>> >>OPNFV uses this:
>> >>
>> >> https://wiki.opnfv.org/display/DEV/Committer+Removal <
>> >> https://wiki.opnfv.org/display/DEV/Committer+Removal>
>> >>
>> >>Basically the process everyone basically uses allows a current
>> >> committer to elect to step down and there is a simple, straight-forward
>> >> process for this.
>> >> In other cases its a little more than the obvious: if someone isn’t
>> >> contributing to the project for an obviously prolonged time and 

Re: retiring/removal of committers

[John D. Ament]

There is one out.  When a podling graduates, its customary to keep everyone
on.  However, if there are people who are no longer interested in the
project and the project chooses to not include them, its not uncommon that
they be left off the graduation.  They would still be open to be included
later on if they contribute once again.

John

On Wed, Nov 29, 2017 at 4:26 PM Thomas Nadeau  wrote:

>
> I think that is why we were having it - no one knew about Apache’s
> rules around this.
> That seems to settle the matter: once you are in, you are in.
>
> —Tom
>
>
> > On Nov 29, 2017, at 3:42 PM, Suneel Marthi 
> wrote:
> >
> > Fyi... committership never expires in ASF, unless the committer chooses
> to
> > go Emeritus. So not sure if this discussion is needed.
> >
> > On Wed, Nov 29, 2017 at 3:23 PM, Thomas Nadeau 
> > wrote:
> >
> >>
> >>One action I took from the last grooming meeting was to
> >> investigate with the community, what process and policies we want to use
> >> around the retirement and/or removal of Committers on the project. As
> our
> >> mentors have told us before, the community here is empowered to decide
> the
> >> criteria for how people are voted as committers, and the implication is
> >> that the reverse is true too. However, after discussing this on our call
> >> this week, it doesn’t seem there is any criteria defined; therefore, I
> >> wanted to open up the discussion on this.
> >>
> >>To start, The Apache PMC guide says this about removal of
> >> Committers/PMC members:
> >>
> >> [http://www.apache.org/dev/pmc.html#pmc-removal <
> >> http://www.apache.org/dev/pmc.html#pmc-removal>]
> >>
> >> Projects can establish their own policy on handling inactive members, as
> >> long as it is applied consistently.
> >>
> >> It is not a problem to retain members of the PMC who have become
> inactive,
> >> and it can make it easier for them to stay in touch with the project if
> >> they choose to become active again.
> >>
> >> Typically, PMC members who are no longer able to participate will resign
> >> from the PMC. However, if a PMC chooses to remove one of its members
> (i.e.
> >> without that member's consent), then it must request the Board to make
> that
> >> decision (which is typically done with a resolution at the Board's next
> >> meeting). The PMC chair should send and email to the board@ mailing
> list
> >> detailing the request for removal and the justification the PMC has for
> >> that removal, and cc: the project's private@ list.
> >>
> >>
> >>So with that in mind, it looks like we need to augment the
> >> guidelines Tal started on the wiki [https://cwiki.apache.org/
> >> confluence/display/ARIATOSCA/Becoming+a+Committer <
> >>
> https://cwiki.apache.org/confluence/display/ARIATOSCA/Becoming+a+Committer
> >]
> >> to include removal/retirement/inactive PMC/committers.
> >> To get the ball rolling, I wanted to make some suggestions for
> >> (de)selection criteria that I’ve used in other OSS projects:
> >>
> >>Open Daylight uses this process:
> >>
> >> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process <
> >> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process>
> >>
> >>OPNFV uses this:
> >>
> >> https://wiki.opnfv.org/display/DEV/Committer+Removal <
> >> https://wiki.opnfv.org/display/DEV/Committer+Removal>
> >>
> >>Basically the process everyone basically uses allows a current
> >> committer to elect to step down and there is a simple, straight-forward
> >> process for this.
> >> In other cases its a little more than the obvious: if someone isn’t
> >> contributing to the project for an obviously prolonged time and hasn’t
> >> verified they’re on a leave of absence or something, then they are
> simply
> >> notified with some notice to respond after which they are removed.
>  All of
> >> the examples also have solutions to more dire situations, but I’ve
> >> literally never seen that happen in any project I’ve worked on in like 6
> >> years.
> >>
> >>I’d like to propose a simple copy/paste of the OPNFV rules which
> >> seem to cover what is needed except for obviously changing the mailing
> >> list/TSC contacts.  We need to change “TSC” to “AriaTosca PPMC”.  There
> are
> >> things to clean up in there too like references to IRC - Apache requires
> >> everything to be on the dev mailer officially.
> >>
> >>—Tom
> >>
> >>
> >>
> >>
> >>
>
>

Re: retiring/removal of committers

[Thomas Nadeau]

I think that is why we were having it - no one knew about Apache’s 
rules around this.
That seems to settle the matter: once you are in, you are in.

—Tom


> On Nov 29, 2017, at 3:42 PM, Suneel Marthi  wrote:
> 
> Fyi... committership never expires in ASF, unless the committer chooses to
> go Emeritus. So not sure if this discussion is needed.
> 
> On Wed, Nov 29, 2017 at 3:23 PM, Thomas Nadeau 
> wrote:
> 
>> 
>>One action I took from the last grooming meeting was to
>> investigate with the community, what process and policies we want to use
>> around the retirement and/or removal of Committers on the project. As our
>> mentors have told us before, the community here is empowered to decide the
>> criteria for how people are voted as committers, and the implication is
>> that the reverse is true too. However, after discussing this on our call
>> this week, it doesn’t seem there is any criteria defined; therefore, I
>> wanted to open up the discussion on this.
>> 
>>To start, The Apache PMC guide says this about removal of
>> Committers/PMC members:
>> 
>> [http://www.apache.org/dev/pmc.html#pmc-removal <
>> http://www.apache.org/dev/pmc.html#pmc-removal>]
>> 
>> Projects can establish their own policy on handling inactive members, as
>> long as it is applied consistently.
>> 
>> It is not a problem to retain members of the PMC who have become inactive,
>> and it can make it easier for them to stay in touch with the project if
>> they choose to become active again.
>> 
>> Typically, PMC members who are no longer able to participate will resign
>> from the PMC. However, if a PMC chooses to remove one of its members (i.e.
>> without that member's consent), then it must request the Board to make that
>> decision (which is typically done with a resolution at the Board's next
>> meeting). The PMC chair should send and email to the board@ mailing list
>> detailing the request for removal and the justification the PMC has for
>> that removal, and cc: the project's private@ list.
>> 
>> 
>>So with that in mind, it looks like we need to augment the
>> guidelines Tal started on the wiki [https://cwiki.apache.org/
>> confluence/display/ARIATOSCA/Becoming+a+Committer <
>> https://cwiki.apache.org/confluence/display/ARIATOSCA/Becoming+a+Committer>]
>> to include removal/retirement/inactive PMC/committers.
>> To get the ball rolling, I wanted to make some suggestions for
>> (de)selection criteria that I’ve used in other OSS projects:
>> 
>>Open Daylight uses this process:
>> 
>> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process <
>> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process>
>> 
>>OPNFV uses this:
>> 
>> https://wiki.opnfv.org/display/DEV/Committer+Removal <
>> https://wiki.opnfv.org/display/DEV/Committer+Removal>
>> 
>>Basically the process everyone basically uses allows a current
>> committer to elect to step down and there is a simple, straight-forward
>> process for this.
>> In other cases its a little more than the obvious: if someone isn’t
>> contributing to the project for an obviously prolonged time and hasn’t
>> verified they’re on a leave of absence or something, then they are simply
>> notified with some notice to respond after which they are removed.   All of
>> the examples also have solutions to more dire situations, but I’ve
>> literally never seen that happen in any project I’ve worked on in like 6
>> years.
>> 
>>I’d like to propose a simple copy/paste of the OPNFV rules which
>> seem to cover what is needed except for obviously changing the mailing
>> list/TSC contacts.  We need to change “TSC” to “AriaTosca PPMC”.  There are
>> things to clean up in there too like references to IRC - Apache requires
>> everything to be on the dev mailer officially.
>> 
>>—Tom
>> 
>> 
>> 
>> 
>> 

Re: retiring/removal of committers

[Suneel Marthi]

Fyi... committership never expires in ASF, unless the committer chooses to
go Emeritus. So not sure if this discussion is needed.

On Wed, Nov 29, 2017 at 3:23 PM, Thomas Nadeau 
wrote:

>
> One action I took from the last grooming meeting was to
> investigate with the community, what process and policies we want to use
> around the retirement and/or removal of Committers on the project. As our
> mentors have told us before, the community here is empowered to decide the
> criteria for how people are voted as committers, and the implication is
> that the reverse is true too. However, after discussing this on our call
> this week, it doesn’t seem there is any criteria defined; therefore, I
> wanted to open up the discussion on this.
>
> To start, The Apache PMC guide says this about removal of
> Committers/PMC members:
>
> [http://www.apache.org/dev/pmc.html#pmc-removal <
> http://www.apache.org/dev/pmc.html#pmc-removal>]
>
> Projects can establish their own policy on handling inactive members, as
> long as it is applied consistently.
>
> It is not a problem to retain members of the PMC who have become inactive,
> and it can make it easier for them to stay in touch with the project if
> they choose to become active again.
>
> Typically, PMC members who are no longer able to participate will resign
> from the PMC. However, if a PMC chooses to remove one of its members (i.e.
> without that member's consent), then it must request the Board to make that
> decision (which is typically done with a resolution at the Board's next
> meeting). The PMC chair should send and email to the board@ mailing list
> detailing the request for removal and the justification the PMC has for
> that removal, and cc: the project's private@ list.
>
>
> So with that in mind, it looks like we need to augment the
> guidelines Tal started on the wiki [https://cwiki.apache.org/
> confluence/display/ARIATOSCA/Becoming+a+Committer <
> https://cwiki.apache.org/confluence/display/ARIATOSCA/Becoming+a+Committer>]
> to include removal/retirement/inactive PMC/committers.
> To get the ball rolling, I wanted to make some suggestions for
> (de)selection criteria that I’ve used in other OSS projects:
>
> Open Daylight uses this process:
>
> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process <
> https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process>
>
> OPNFV uses this:
>
> https://wiki.opnfv.org/display/DEV/Committer+Removal <
> https://wiki.opnfv.org/display/DEV/Committer+Removal>
>
> Basically the process everyone basically uses allows a current
> committer to elect to step down and there is a simple, straight-forward
> process for this.
> In other cases its a little more than the obvious: if someone isn’t
> contributing to the project for an obviously prolonged time and hasn’t
> verified they’re on a leave of absence or something, then they are simply
> notified with some notice to respond after which they are removed.   All of
> the examples also have solutions to more dire situations, but I’ve
> literally never seen that happen in any project I’ve worked on in like 6
> years.
>
> I’d like to propose a simple copy/paste of the OPNFV rules which
> seem to cover what is needed except for obviously changing the mailing
> list/TSC contacts.  We need to change “TSC” to “AriaTosca PPMC”.  There are
> things to clean up in there too like references to IRC - Apache requires
> everything to be on the dev mailer officially.
>
> —Tom
>
>
>
>
>

retiring/removal of committers

[Thomas Nadeau]

One action I took from the last grooming meeting was to investigate 
with the community, what process and policies we want to use around the 
retirement and/or removal of Committers on the project. As our mentors have 
told us before, the community here is empowered to decide the criteria for how 
people are voted as committers, and the implication is that the reverse is true 
too. However, after discussing this on our call this week, it doesn’t seem 
there is any criteria defined; therefore, I wanted to open up the discussion on 
this. 

To start, The Apache PMC guide says this about removal of 
Committers/PMC members:

[http://www.apache.org/dev/pmc.html#pmc-removal 
]

Projects can establish their own policy on handling inactive members, as long 
as it is applied consistently.

It is not a problem to retain members of the PMC who have become inactive, and 
it can make it easier for them to stay in touch with the project if they choose 
to become active again.

Typically, PMC members who are no longer able to participate will resign from 
the PMC. However, if a PMC chooses to remove one of its members (i.e. without 
that member's consent), then it must request the Board to make that decision 
(which is typically done with a resolution at the Board's next meeting). The 
PMC chair should send and email to the board@ mailing list detailing the 
request for removal and the justification the PMC has for that removal, and cc: 
the project's private@ list.


So with that in mind, it looks like we need to augment the guidelines 
Tal started on the wiki 
[https://cwiki.apache.org/confluence/display/ARIATOSCA/Becoming+a+Committer 
] 
to include removal/retirement/inactive PMC/committers.
To get the ball rolling, I wanted to make some suggestions for (de)selection 
criteria that I’ve used in other OSS projects:

Open Daylight uses this process:

https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process 


OPNFV uses this:

https://wiki.opnfv.org/display/DEV/Committer+Removal 


Basically the process everyone basically uses allows a current 
committer to elect to step down and there is a simple, straight-forward process 
for this.
In other cases its a little more than the obvious: if someone isn’t 
contributing to the project for an obviously prolonged time and hasn’t verified 
they’re on a leave of absence or something, then they are simply notified with 
some notice to respond after which they are removed.   All of the examples also 
have solutions to more dire situations, but I’ve literally never seen that 
happen in any project I’ve worked on in like 6 years. 

I’d like to propose a simple copy/paste of the OPNFV rules which seem 
to cover what is needed except for obviously changing the mailing list/TSC 
contacts.  We need to change “TSC” to “AriaTosca PPMC”.  There are things to 
clean up in there too like references to IRC - Apache requires everything to be 
on the dev mailer officially.

—Tom