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 <jgho...@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 <johndam...@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 <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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
