You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ariatosca.apache.org by Thomas Nadeau <tn...@gmail.com> on 2017/11/29 20:23:30 UTC
retiring/removal of committers
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
Posted by Thomas Nadeau <tn...@lucidvision.com>.
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 <jg...@gmail.com> 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 <jo...@apache.org> 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 <tn...@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 <su...@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 <tn...@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
Re: retiring/removal of committers
Posted by Jakob Homan <jg...@gmail.com>.
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 <jo...@apache.org> 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 <tn...@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 <su...@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 <tn...@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
>> >>
>> >>
>> >>
>> >>
>> >>
>>
>>
Re: retiring/removal of committers
Posted by "John D. Ament" <jo...@apache.org>.
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 <tn...@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 <su...@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 <tn...@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
> >>
> >>
> >>
> >>
> >>
>
>
Re: retiring/removal of committers
Posted by Thomas Nadeau <tn...@gmail.com>.
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 <su...@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 <tn...@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
>>
>>
>>
>>
>>
Re: retiring/removal of committers
Posted by Suneel Marthi <su...@gmail.com>.
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 <tn...@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
>
>
>
>
>