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