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 <[email protected]> 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 <[email protected]>
> 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
>>
>>
>>
>>
>>
