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 <tnadeaua...@gmail.com> 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 > > > > >
