[DISCUSS] PMC/Committer Emiratus status

[Asaf Mesika <as...@gmail.com>]

Hi,

Following the discussion I've started in Pulsar bi-weekly meetings.

= The idea
PMC and Committers members will transition into Emeritus status after X
months of inactivity, or voluntarily.

= Why?
- Gain real visibility into the health of the project in terms of real
active PMC / Committers members.
- Have the alert threshold set correctly as to when it's time to start
working on recruiting new PMC / Committers members.

= Is there any precedence?
Yes. A lot.
Many CNCF projects do it.
Many Apache projects do it.
Apache foundations rules allow it.

Read below to see examples and links.


= Examples

=== etcD project <https://github.com/etcd-io/etcd/blob/main/GOVERNANCE.md>

Quote

Life priorities, interests, and passions can change. Maintainers can retire
and move to the emeritus status
<https://github.com/etcd-io/etcd/blob/main/README.md#etcd-emeritus-maintainers>.
If a maintainer needs to step down, they should inform other maintainers,
if possible, help find someone to pick up the related work. At the very
least, ensure the related work can be continued. Afterward they can remove
themselves from list of existing maintainers.

If a maintainer is not been performing their duties for period of 12
months, they can be removed by other maintainers. In that case inactive
maintainer will be first notified via an email. If situation doesn't
improve, they will be removed. If an emeritus maintainer wants to regain an
active role, they can do so by renewing their contributions. Active
maintainers should welcome such a move. Retiring of other maintainers or
regaining the status should require approval of at least two active
maintainers.

=== Apache Gump
According to this link <https://gump.apache.org/bylaws.html>, they have
emeritus status for maintainers and PMC members and policy to transition.

QUOTE
Committer access is by invitation only and must be approved by lazy
consensus of the active PMC members. A Committer is considered emeritus by
their own declaration or by not contributing in any form to the project for
over six months. An emeritus committer may request reinstatement of commit
access from the PMC. Such reinstatement is subject to lazy consensus of
active PMC members.

Membership of the PMC is by invitation only and must be approved by a lazy
consensus of active PMC members. A PMC member is considered "emeritus" by
their own declaration or by not contributing in any form to the project for
over six months. An emeritus member may request reinstatement to the PMC.
Such reinstatement is subject to lazy consensus of the active PMC members.
Membership of the PMC can be revoked by an unanimous vote of all the active
PMC members other than the member in question.

END QUOTE

There are many more: Apache Hive
<https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Committers>,
Apache Orc <https://github.com/apache/orc/blob/main/site/develop/bylaws.md>,
...

= What does Apache thinks about this?

According to this link <https://www.apache.org/dev/pmc.html#pmc-removal>,
any project can have their policies for retire an inactive PMC member.

QUOTE
SHOULD A PMC REMOVE INACTIVE MEMBERS?
<https://www.apache.org/dev/pmc.html#pmc-removal>

Projects can establish their own policy on handling inactive members, as
long as they apply it 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
(without that member's request or consent), 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 an email to the board@
mailing list detailing the request for removal and the justification the
PMC has for that removal, and copy the project's private@ list.

END QUOTE


= Summary
I believe that Apache Pulsar has the responsibility with respect to its
users to reflect the real number of people actively in the project - its
PMC members.

Re: [DISCUSS] PMC/Committer Emiratus status

["P. Taylor Goetz" <pt...@gmail.com>]

Thanks Dave. All the points you raised are valid.

To be clear, my main point is that there’s no good reason to remove inactive contributors from Committership/PMC Membership. Period.

I’ll concede that PMCs have the freedom decide on their own if and how to publish their community roster. But I would argue that removing inactive members from such lists is potentially insulting to members who were influential in the project but found reasons to move on.It just doesn’t jibe with my interpretation of the Apache Way.

- Taylor

> On Mar 7, 2023, at 8:10 PM, Dave Fisher <wa...@comcast.net> wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Mar 7, 2023, at 3:34 PM, P. Taylor Goetz <pt...@gmail.com> wrote:
>> 
>> 
>> 
>>> On Mar 7, 2023, at 6:36 AM, Enrico Olivelli <eo...@gmail.com> wrote:
>>> 
>>> Websites tend to quickly become obsolete about this kind of thing,
>>> because really
>>> nobody takes care of its own "status" on a project, or that it is
>>> "visible" on the website.
>>> It is not for the benefit of anyone.
>> 
>> I would beg to differ here. It would show who’s contributed to the project, and their current activity status. It preserves, rather than rewrites, the history of the project.
> 
> We have such a list and there is “bit rot”
>> 
>> If it’s a burden to update a text file, then automate the task. Git history, JIRA history, and mailing list history are all preserved by ASF infrastructure. There are plenty of data sources available to mine to determine an “activity level”. The ASF already has a bunch of tools that give this type of 30k foot view.
> 
> I am familiar with many of the tools. I’ve worked on the massive Python program that evaluates the incubator podlings. This ask is a rather large undertaking. Certain parts of GitHub activity are hard to do. There is a lot of lists to correlate like the mapping between apacheid, names, GitHub id, and extra emails. One would need to learn the structure of whimsy’s ldap files, pony mail’s api, GitHub’s api, etcetera. This is not a hand wave. It’s real work. It would likely require ASF member privileges.
> 
> If it were pursued then I would be more interested in contributions from non-committers.
>> 
>> 
>>> 
>>> Also when you become "inactive" you are for sure not interested in
>>> updating the website, because you slowly
>>> lose interest in the project :-)
>> 
>> Again, automate it if you feel it’s an undue burden.
>> 
>>> 
>>> Everybody (should) participate as an individual, what's the benefit of
>>> having you listed on the website ?
>> 
>> I’ll offer a hypothetical of which there are plenty of real-world examples:
>> 
>> Suppose I started an open source project “FooBar” that gained a decent following and OSS community. Then donated it to the ASF to ensure both the community and project would have a chance to continue, even without me. I go through the Incubator to propose a new project and it gets accepted. The community does the hard work of graduating from the Incubator and it becomes a TLP “Apache FooBar”. Now that it’s, according to the ASF guidelines, an active, sustainable community, I decide to pull back a little to pursue other opportunities.
>> 
>> Should the record of those contributions be removed from the project website? What if a PMC member dies? Should the record of contributions be removed?
>> 
>>> 
>>> I really remember the first time I was invited as a committer in an
>>> ASF, I felt really proud of myself,
>>> and also seeing myself listed in the main pom.xml of the project or in
>>> the list of committers was cool.
>>> So this is great for new contributors or in order to praise the
>>> efforts of someone who spent so much
>>> time in the community in order to be asked to join the group of people
>>> responsible for the project.
>> 
>> Yes, for many being invited as a Committer/PMC Member is a proud moment and significant achievement. Why should it have an expiration date?
>> 
>>> But after some time, when you participate in an OSS community, and you
>>> really care about the project,
>>> you don't care if you are listed here or there.
>> 
>> Some people do and have every right to.
>> 
>> If Linus Torvalds decides to no longer partificipate in Linux development, should the Linux Foundation remove him from the list of contributors?
>> 
>>> 
>>> Regarding the "themes" on which someone could be "more expert" or not.
>>> This is also a piece of information that becomes obsolete.
>>> The community is dynamic, people who "knew" well something in the past
>>> but maybe they are no more up-to-date now.
>>> 
>>> What's the goal ? To say Foo Bar is the "Pulsar Schema Registry expert" ?
>>> 
>>> Personally I won't feel good to say that I am "the" expert for X, Y,
>>> Z, even if there are a few places in which I have spent
>>> days of work and I made substantial contributions (or new features
>>> initially contributed by myself).
>>> 
>>> If you want to reach out to someone expert on a piece of code you use
>>> the GH UI and see the latest commits (of "git log")
>>> or search into the mailing list archives or in the GH issues and you
>>> will find the same names around a given topic.
>> 
>> I don’t have a strong opinion on this and would leave it to the Pulsar dev community to sort out.
> 
> About 15 years ago the ASF asked projects to remove @author tags from source because it was blocking contributions. People were treating authors like code owners. I agree with Enrico here.
> 
>> 
>> I am passionate about preserving history (a recurring theme within the ASF). Removing people from contributor lists because they’ve since moved on to “make the project look more active” rubs me the wrong way and, IMHO, betrays the spirit of the ASF.
>> 
>>> If we want to list the PMC members/committers I suggest building
>>> something automated that simply shows the list.
> 
> This part is easy as we can make use of the yaml that whimsy.Apache.org <http://whimsy.apache.org/> creates.
>> 
>> Go for iit! We software developers seem to have a knack of automating tedious tasks. ;)
> .
>> 
>>> Enrico
>> 
>> -Taylor
> 
> Dave

Re: [DISCUSS] PMC/Committer Emiratus status

[Dave Fisher <wa...@comcast.net>]

Sent from my iPhone

> On Mar 7, 2023, at 3:34 PM, P. Taylor Goetz <pt...@gmail.com> wrote:
> 
> 
> 
>> On Mar 7, 2023, at 6:36 AM, Enrico Olivelli <eo...@gmail.com> wrote:
>> 
>> Websites tend to quickly become obsolete about this kind of thing,
>> because really
>> nobody takes care of its own "status" on a project, or that it is
>> "visible" on the website.
>> It is not for the benefit of anyone.
> 
> I would beg to differ here. It would show who’s contributed to the project, and their current activity status. It preserves, rather than rewrites, the history of the project.

We have such a list and there is “bit rot”
> 
> If it’s a burden to update a text file, then automate the task. Git history, JIRA history, and mailing list history are all preserved by ASF infrastructure. There are plenty of data sources available to mine to determine an “activity level”. The ASF already has a bunch of tools that give this type of 30k foot view.

I am familiar with many of the tools. I’ve worked on the massive Python program that evaluates the incubator podlings. This ask is a rather large undertaking. Certain parts of GitHub activity are hard to do. There is a lot of lists to correlate like the mapping between apacheid, names, GitHub id, and extra emails. One would need to learn the structure of whimsy’s ldap files, pony mail’s api, GitHub’s api, etcetera. This is not a hand wave. It’s real work. It would likely require ASF member privileges.

If it were pursued then I would be more interested in contributions from non-committers.
> 
> 
>> 
>> Also when you become "inactive" you are for sure not interested in
>> updating the website, because you slowly
>> lose interest in the project :-)
> 
> Again, automate it if you feel it’s an undue burden.
> 
>> 
>> Everybody (should) participate as an individual, what's the benefit of
>> having you listed on the website ?
> 
> I’ll offer a hypothetical of which there are plenty of real-world examples:
> 
> Suppose I started an open source project “FooBar” that gained a decent following and OSS community. Then donated it to the ASF to ensure both the community and project would have a chance to continue, even without me. I go through the Incubator to propose a new project and it gets accepted. The community does the hard work of graduating from the Incubator and it becomes a TLP “Apache FooBar”. Now that it’s, according to the ASF guidelines, an active, sustainable community, I decide to pull back a little to pursue other opportunities.
> 
> Should the record of those contributions be removed from the project website? What if a PMC member dies? Should the record of contributions be removed?
> 
>> 
>> I really remember the first time I was invited as a committer in an
>> ASF, I felt really proud of myself,
>> and also seeing myself listed in the main pom.xml of the project or in
>> the list of committers was cool.
>> So this is great for new contributors or in order to praise the
>> efforts of someone who spent so much
>> time in the community in order to be asked to join the group of people
>> responsible for the project.
> 
> Yes, for many being invited as a Committer/PMC Member is a proud moment and significant achievement. Why should it have an expiration date?
> 
>> But after some time, when you participate in an OSS community, and you
>> really care about the project,
>> you don't care if you are listed here or there.
> 
> Some people do and have every right to.
> 
> If Linus Torvalds decides to no longer partificipate in Linux development, should the Linux Foundation remove him from the list of contributors?
> 
>> 
>> Regarding the "themes" on which someone could be "more expert" or not.
>> This is also a piece of information that becomes obsolete.
>> The community is dynamic, people who "knew" well something in the past
>> but maybe they are no more up-to-date now.
>> 
>> What's the goal ? To say Foo Bar is the "Pulsar Schema Registry expert" ?
>> 
>> Personally I won't feel good to say that I am "the" expert for X, Y,
>> Z, even if there are a few places in which I have spent
>> days of work and I made substantial contributions (or new features
>> initially contributed by myself).
>> 
>> If you want to reach out to someone expert on a piece of code you use
>> the GH UI and see the latest commits (of "git log")
>> or search into the mailing list archives or in the GH issues and you
>> will find the same names around a given topic.
> 
> I don’t have a strong opinion on this and would leave it to the Pulsar dev community to sort out.

About 15 years ago the ASF asked projects to remove @author tags from source because it was blocking contributions. People were treating authors like code owners. I agree with Enrico here.

> 
> I am passionate about preserving history (a recurring theme within the ASF). Removing people from contributor lists because they’ve since moved on to “make the project look more active” rubs me the wrong way and, IMHO, betrays the spirit of the ASF.
> 
>> If we want to list the PMC members/committers I suggest building
>> something automated that simply shows the list.

This part is easy as we can make use of the yaml that whimsy.Apache.org creates.
> 
> Go for iit! We software developers seem to have a knack of automating tedious tasks. ;)
.
> 
>> Enrico
> 
> -Taylor

Dave
> 

Re: [DISCUSS] PMC/Committer Emiratus status

["P. Taylor Goetz" <pt...@gmail.com>]

> On Mar 7, 2023, at 6:36 AM, Enrico Olivelli <eo...@gmail.com> wrote:
> 
> Websites tend to quickly become obsolete about this kind of thing,
> because really
> nobody takes care of its own "status" on a project, or that it is
> "visible" on the website.
> It is not for the benefit of anyone.

I would beg to differ here. It would show who’s contributed to the project, and their current activity status. It preserves, rather than rewrites, the history of the project.

If it’s a burden to update a text file, then automate the task. Git history, JIRA history, and mailing list history are all preserved by ASF infrastructure. There are plenty of data sources available to mine to determine an “activity level”. The ASF already has a bunch of tools that give this type of 30k foot view.


> 
> Also when you become "inactive" you are for sure not interested in
> updating the website, because you slowly
> lose interest in the project :-)

Again, automate it if you feel it’s an undue burden.

> 
> Everybody (should) participate as an individual, what's the benefit of
> having you listed on the website ?

I’ll offer a hypothetical of which there are plenty of real-world examples:

Suppose I started an open source project “FooBar” that gained a decent following and OSS community. Then donated it to the ASF to ensure both the community and project would have a chance to continue, even without me. I go through the Incubator to propose a new project and it gets accepted. The community does the hard work of graduating from the Incubator and it becomes a TLP “Apache FooBar”. Now that it’s, according to the ASF guidelines, an active, sustainable community, I decide to pull back a little to pursue other opportunities.

Should the record of those contributions be removed from the project website? What if a PMC member dies? Should the record of contributions be removed?

> 
> I really remember the first time I was invited as a committer in an
> ASF, I felt really proud of myself,
> and also seeing myself listed in the main pom.xml of the project or in
> the list of committers was cool.
> So this is great for new contributors or in order to praise the
> efforts of someone who spent so much
> time in the community in order to be asked to join the group of people
> responsible for the project.

Yes, for many being invited as a Committer/PMC Member is a proud moment and significant achievement. Why should it have an expiration date?

> But after some time, when you participate in an OSS community, and you
> really care about the project,
> you don't care if you are listed here or there.

Some people do and have every right to.

If Linus Torvalds decides to no longer partificipate in Linux development, should the Linux Foundation remove him from the list of contributors?

> 
> Regarding the "themes" on which someone could be "more expert" or not.
> This is also a piece of information that becomes obsolete.
> The community is dynamic, people who "knew" well something in the past
> but maybe they are no more up-to-date now.
> 
> What's the goal ? To say Foo Bar is the "Pulsar Schema Registry expert" ?
> 
> Personally I won't feel good to say that I am "the" expert for X, Y,
> Z, even if there are a few places in which I have spent
> days of work and I made substantial contributions (or new features
> initially contributed by myself).
> 
> If you want to reach out to someone expert on a piece of code you use
> the GH UI and see the latest commits (of "git log")
> or search into the mailing list archives or in the GH issues and you
> will find the same names around a given topic.

I don’t have a strong opinion on this and would leave it to the Pulsar dev community to sort out.

I am passionate about preserving history (a recurring theme within the ASF). Removing people from contributor lists because they’ve since moved on to “make the project look more active” rubs me the wrong way and, IMHO, betrays the spirit of the ASF.

> If we want to list the PMC members/committers I suggest building
> something automated that simply shows the list.

Go for iit! We software developers seem to have a knack of automating tedious tasks. ;)

> Enrico

-Taylor

Re: [DISCUSS] PMC/Committer Emiratus status

[Enrico Olivelli <eo...@gmail.com>]

I have found this interesting reading about this topic
 https://www.apache.org/dev/pmc.html#pmc-removal

Quoting it here:
"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 (without that member's request or consent), 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 an
email to the board@ mailing list detailing the request for removal and
the justification the PMC has for that removal, and copy the project's
private@ list."

So basically if we ever wanted to remove someone we have to deal with
the ASF board and explain the reasons for it.
I have been around for a few years in the ASF and I have seen PMC
members removed only for very strong cases and not due to "inactive"
status


Enrico

Il giorno ven 10 mar 2023 alle ore 06:52 Michael Marshall
<mm...@apache.org> ha scritto:
>
> Stepping back slightly, this thread started with a desire to:
>
> > Gain real visibility into the health of the project in terms of real
> > active PMC / Committers members.
>
> What if instead we ask how we as a community can show prospective and
> new users that Apache Pulsar is a healthy project?
>
> For me, when I first came to the Pulsar project, I didn't know
> anything about The Apache Way, and I didn't know what a PMC was.
> Instead, I thought the project seemed healthy because the tech was
> exciting and when I opened GitHub issues, people who made many
> contributions to the project answered my questions and helped me start
> making my own contributions.
>
> Each person will judge project health differently.
>
> Our goal could be to identify key ways that Pulsar is healthy and
> showcase those. We could also identify ways that we have room to grow
> and discuss improving those on this list.
>
> Some potentially meaningful measures of project health: accuracy and
> helpfulness of documentation, release frequency, number of emails on
> the mailing list, number of new committers/PMC members, number of
> commits, time to first response on an opened GitHub
> issue/discussion/pr, time to remediate security vulnerabilities,
> successful upgrades with no surprises, and the list goes on.
>
> In my experience, the user touch points like documentation and
> responsiveness to questions matter most to users.
>
> If we find that user issues/discussions are not getting feedback
> quickly enough, perhaps it would be interesting to coordinate among
> contributors times where a specific person volunteers to triage GitHub
> issues and discussions. That could help lighten the load on some of
> the main contributors that handle these tasks all of the time, while
> also giving contributors a chance to gain experience in the project
> and build merit in the project.
>
> In response to the original proposal, I am not in favor of adding
> active/inactive flags to PMC members and committers. Ultimately, I
> think there are better ways to show our users that we have a healthy
> project.
>
> Thanks,
> Michael
>
>
> On Thu, Mar 9, 2023 at 3:22 AM Asaf Mesika <as...@gmail.com> wrote:
> >
> > Enrico, I was referring to this part of the quote:
> >
> > do a PMC roll
> > > call on private@pulsar.a.o <ma...@pulsar.a.o> and ask whether
> > > current PMC members self describe as “active” or “inactive”. That status
> > > could then be reflected on the Community section of the pulsar website.
> >
> > The idea P. Taylor Goetz offered would be a yearly "chore" done by the PMC
> > chair, helped by PMC members, to "poll" that status, verify it, and if all
> > is verified, voted upon, then the website updated.
> > In that suggestion, the website wouldn't rot, no?
> > PMC membership / committer membership don't expire in that suggestion.
> >
> > On Tue, Mar 7, 2023 at 1:37 PM Enrico Olivelli <eo...@gmail.com> wrote:
> >
> > > Il giorno lun 6 mar 2023 alle ore 23:12 Asaf Mesika
> > > <as...@gmail.com> ha scritto:
> > > >
> > > > Tison,
> > > >
> > > > The suggestion was stated a bit differently:
> > > >
> > > > Quote:
> > > >
> > > > Rather, I would recommend a project-level “active/inactive” flag that PMC
> > > > members can voluntarily apply to themselves. For example, do a PMC roll
> > > > call on private@pulsar.a.o <ma...@pulsar.a.o> and ask whether
> > > > current PMC members self describe as “active” or “inactive”. That status
> > > > could then be reflected on the Community section of the pulsar website.
> > >
> > > Websites tend to quickly become obsolete about this kind of thing,
> > > because really
> > > nobody takes care of its own "status" on a project, or that it is
> > > "visible" on the website.
> > > It is not for the benefit of anyone.
> > >
> > > Also when you become "inactive" you are for sure not interested in
> > > updating the website, because you slowly
> > > lose interest in the project :-)
> > >
> > > Everybody (should) participate as an individual, what's the benefit of
> > > having you listed on the website ?
> > >
> > > I really remember the first time I was invited as a committer in an
> > > ASF, I felt really proud of myself,
> > > and also seeing myself listed in the main pom.xml of the project or in
> > > the list of committers was cool.
> > > So this is great for new contributors or in order to praise the
> > > efforts of someone who spent so much
> > > time in the community in order to be asked to join the group of people
> > > responsible for the project.
> > >
> > > But after some time, when you participate in an OSS community, and you
> > > really care about the project,
> > > you don't care if you are listed here or there.
> > >
> > > Regarding the "themes" on which someone could be "more expert" or not.
> > > This is also a piece of information that becomes obsolete.
> > > The community is dynamic, people who "knew" well something in the past
> > > but maybe they are no more up-to-date now.
> > >
> > > What's the goal ? To say Foo Bar is the "Pulsar Schema Registry expert" ?
> > >
> > > Personally I won't feel good to say that I am "the" expert for X, Y,
> > > Z, even if there are a few places in which I have spent
> > > days of work and I made substantial contributions (or new features
> > > initially contributed by myself).
> > >
> > > If you want to reach out to someone expert on a piece of code you use
> > > the GH UI and see the latest commits (of "git log")
> > > or search into the mailing list archives or in the GH issues and you
> > > will find the same names around a given topic.
> > >
> > > For Pulsar this is the OFFICIAL page of the folks that are
> > > "responsible" for the project
> > > https://people.apache.org/phonebook.html?pmc=pulsar
> > >
> > > If you really want to see who are the all the ASF committers you can
> > > always go here
> > > https://people.apache.org/committer-index.html
> > >
> > > If we want to list the PMC members/committers I suggest building
> > > something automated that simply shows the list.
> > >
> > >
> > > Enrico
> > >
> > >
> > >
> > >
> > >
> > > No > reply from a PMC member? Mark them inactive until they request a
> > > change.
> > > >
> > > > End Quote
> > > >
> > > >
> > > > On Mon, Mar 6, 2023 at 6:13 PM tison <wa...@gmail.com> wrote:
> > > >
> > > > > I won't object if any PMC member or committer is willing to set their
> > > > > personal status; e.g., open to topics of a specific domain, "inactive"
> > > > > or "don't
> > > > > disturb"
> > > > >
> > > > > Best,
> > > > > tison.
> > > > >
> > > > >
> > > > > Asaf Mesika <as...@gmail.com> 于2023年3月7日周二 00:05写道：
> > > > >
> > > > > > Do other think it's a good thing to adopt P. Taylor Goetz idea of
> > > active
> > > > > > flag and the process suggested?
> > > > > >
> > > > > >
> > > > > > On Mon, Mar 6, 2023 at 2:03 PM tison <wa...@gmail.com> wrote:
> > > > > >
> > > > > > > Hi Yu,
> > > > > > >
> > > > > > > You can start by adding a page on the contribution guide or a
> > > table in
> > > > > > the
> > > > > > > README of the main repo/site repo to state that you're an expert
> > > in the
> > > > > > > document domain.
> > > > > > >
> > > > > > > I have an in-house landscape about Pulsar modules, the broader
> > > > > ecosystem,
> > > > > > > and their active contributors/maintainers. Since people may not
> > > want to
> > > > > > be
> > > > > > > referred to publicly by another person, I don't make it public.
> > > > > > >
> > > > > > > Finding experts can be a skill to collaborate in a community. You
> > > can
> > > > > > find
> > > > > > > them when browsing relative PRs, analyzing the commit history,
> > > meeting
> > > > > > them
> > > > > > > in the community, and having conversations. I don't have the
> > > motivation
> > > > > > to
> > > > > > > maintain such a table publicly.
> > > > > > >
> > > > > > > Scala has a table of domain experts that can help[1]. If you like
> > > it,
> > > > > you
> > > > > > > can list yourself and try to bring other experts to list
> > > themselves.
> > > > > The
> > > > > > > ASF shares a sense that "The Foundation belongs to *you*". You're
> > > > > > already a
> > > > > > > PMC member and able to drive such an effort.
> > > > > > >
> > > > > > > Best,
> > > > > > > tison.
> > > > > > >
> > > > > > > [1] https://github.com/scala/scala#get-in-touch
> > > > > > >
> > > > > > >
> > > > > > > Yu <li...@apache.org> 于2023年3月6日周一 19:48写道：
> > > > > > >
> > > > > > > > Hi Asaf,
> > > > > > > >
> > > > > > > > Thanks for bringing this up!
> > > > > > > >
> > > > > > > > If I may put my two pennies' worth:
> > > > > > > >
> > > > > > > > To be honest, this idea flashed across my mind previously. I
> > > talked
> > > > > > about
> > > > > > > > this to my colleague, and he was surprised that I was willing to
> > > be
> > > > > > > > deprived of benefits (at that time, I was a PMC member already).
> > > > > > > >
> > > > > > > > PMC members are vital promotors and driving forces of a
> > > community.
> > > > > > > Ideally,
> > > > > > > > they should be direction leaders and make great contributions
> > > > > > > > *continuously*. No one should enjoy the benefits of honor but not
> > > > > > > > contribute much *all the time*. Setting retirement bars for PMC
> > > > > members
> > > > > > > > reminds us to contribute and provide value. Maybe I'm a little
> > > > > > aggressive
> > > > > > > > :-)
> > > > > > > >
> > > > > > > > ~~~~~~
> > > > > > > >
> > > > > > > > +1 but a long list of PMC members with many inactive members
> > > does not
> > > > > > > > create a good feeling since "false prosperity" is no better than
> > > > > "real
> > > > > > > > contributions".
> > > > > > > >
> > > > > > > > > 3. Merit doesn’t expire.
> > > > > > > >
> > > > > > > > ~~~~~~
> > > > > > > >
> > > > > > > > Compared to my previous thought, Goetz has proposed a better idea
> > > > > > since:
> > > > > > > >
> > > > > > > > 1. It's mild and can be accepted by many PMC members. A kind of
> > > life
> > > > > > > wisdom
> > > > > > > > :-)
> > > > > > > >
> > > > > > > > 2. People who need help (e.g., PIP approvals / PR comments / ...)
> > > > > from
> > > > > > > PMC
> > > > > > > > members can check the flags to know who is available to help.
> > > > > > > >
> > > > > > > > Except for flags, I suggest adding "area of expertise" for PMC
> > > > > members
> > > > > > > and
> > > > > > > > committers, so people will know who are the most suitable
> > > experts to
> > > > > > ask
> > > > > > > > for help or collaborate.
> > > > > > > >
> > > > > > > > > 1. You can maintain active/inactive status at the project level
> > > > > with
> > > > > > a
> > > > > > > > simple flag on a community page, without removing people from the
> > > > > PMC.
> > > > > > > > > 2. By making it an informal, self-reported flag, you avoid the
> > > > > > overhead
> > > > > > > > of board resolutions, etc. and just manage it at the community
> > > level.
> > > > > > If
> > > > > > > > someone wants to change their status, they can just say so or
> > > submit
> > > > > a
> > > > > > > pull
> > > > > > > > request to change their status on the pulsar website.
> > > > > > > >
> > > > > > > > ~~~~~~
> > > > > > > >
> > > > > > > > Yu
> > > > > > > >
> > > > > > > > On Sun, Mar 5, 2023 at 10:31 PM Asaf Mesika <
> > > asaf.mesika@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Thanks to everyone who took the time to carefully answer with
> > > > > > detailed
> > > > > > > > > explanations.
> > > > > > > > > I personally learned a lot about Apache projects this way
> > > (made me
> > > > > > read
> > > > > > > > > about it some more).
> > > > > > > > >
> > > > > > > > > So my personal recap is:
> > > > > > > > >
> > > > > > > > >    - The goal of knowing the health of the Apache Pulsar
> > > community
> > > > > > can
> > > > > > > be
> > > > > > > > >    achieved by taking a look at monthly active contributors
> > > over
> > > > > time
> > > > > > > > >    displayed on the community page.
> > > > > > > > >       - It could be nice getting those numbers on the mailing
> > > list
> > > > > > > itself
> > > > > > > > >       as well.
> > > > > > > > >    - Calculating the engagement is not an easy task.
> > > > > > > > >    - Kicking people off is not something you'd like to do in
> > > > > general
> > > > > > > and
> > > > > > > > >    specifically for volunteers.
> > > > > > > > >    - People's credit for work, which is also expressed in PMC
> > > > > > > membership
> > > > > > > > >    never expires due to Merit never expires - your work credit
> > > and
> > > > > > > earned
> > > > > > > > >    right should not expire.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I personally see PMC members answering someone not a PMC member
> > > > > nor a
> > > > > > > > > comitter on this topic as a very healthy community indicator :)
> > > > > > > > >
> > > > > > > > > Thanks !
> > > > > > > > >
> > > > > > > > > Asaf
> > > > > > > > >
> > > > > > > > > On Fri, Mar 3, 2023 at 10:22 AM Enrico Olivelli <
> > > > > eolivelli@gmail.com
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > This is an interesting discussion.
> > > > > > > > > > Good to see this kind of a discussion on the dev@ mailing
> > > list,
> > > > > > this
> > > > > > > > > > way more people are aware of the fact that we are a project
> > > in
> > > > > the
> > > > > > > ASF
> > > > > > > > > > and there is a Project Management Committee.
> > > > > > > > > >
> > > > > > > > > > I have been following a few Apache projects for a while, and
> > > I
> > > > > > > believe
> > > > > > > > > > that this kind of discussions should be run on the private@
> > > > > > mailing
> > > > > > > > > > list.
> > > > > > > > > > It is the PMC that usually deals with this stuff.
> > > > > > > > > >
> > > > > > > > > > As Tison said, the common practice is that you never remove
> > > > > anyone
> > > > > > > > > > from a PMC or from the Committers list.
> > > > > > > > > >
> > > > > > > > > > This happens only in rare cases where an individual behaves
> > > in
> > > > > > such a
> > > > > > > > > > way that the Project or the Foundation could be damaged,
> > > > > > > > > > for instance if you speak on behalf of the project and you
> > > offend
> > > > > > > > > > someone publicly.
> > > > > > > > > >
> > > > > > > > > > Inactive contributors/committers/PMC members do not do any
> > > harm
> > > > > to
> > > > > > a
> > > > > > > > > > project.
> > > > > > > > > >
> > > > > > > > > > Some projects have some rules that you cannot participate in
> > > > > > official
> > > > > > > > > > VOTEs if you are not "active".
> > > > > > > > > >
> > > > > > > > > > If anyone has some problems with someone in the community,
> > > then
> > > > > > they
> > > > > > > > > > can reach out to private@pulsar.apache.org and the PMC will
> > > > > listen
> > > > > > > to
> > > > > > > > > > the problem and take actions.
> > > > > > > > > >
> > > > > > > > > > my 2 cents
> > > > > > > > > >
> > > > > > > > > > Enrico
> > > > > > > > > >
> > > > > > > > > > Il giorno ven 3 mar 2023 alle ore 04:39 Yunze Xu
> > > > > > > > > > <yz...@streamnative.io.invalid> ha scritto:
> > > > > > > > > > >
> > > > > > > > > > > As a PMC member, I don't like playing a game of
> > > determining who
> > > > > > > > should
> > > > > > > > > > > be removed from PMC as well.
> > > > > > > > > > >
> > > > > > > > > > > I hear a viewpoint that someone is only participating in
> > > the
> > > > > > > > community
> > > > > > > > > > > only to join a PMC so that he can benefit from it. After
> > > > > > becoming a
> > > > > > > > > > > PMC member, he is never active in the community. It might
> > > be
> > > > > true
> > > > > > > but
> > > > > > > > > > > I think it's acceptable. Making such a rule won't prevent
> > > such
> > > > > > > cases.
> > > > > > > > > > > If he wants, he can make use of the rule and keep himself
> > > > > > "active"
> > > > > > > to
> > > > > > > > > > > avoid being kicked out of the PMC. Though the active state
> > > is
> > > > > > fake.
> > > > > > > > > > >
> > > > > > > > > > > I'm not against the way to remove (or something else that
> > > > > sounds
> > > > > > > > good)
> > > > > > > > > > > a PMC member because none of these ways is perfect.
> > > However,
> > > > > I'm
> > > > > > > > > > > STRONGLY AGAINST changing a rule that has been applied for
> > > some
> > > > > > > time
> > > > > > > > > > > unless it can be proved the rule is very harmful to the
> > > > > > community.
> > > > > > > > > > > You mentioned
> > > https://www.apache.org/dev/pmc.html#pmc-removal.
> > > > > > But
> > > > > > > > > > > please don't ignore the first sentence:
> > > > > > > > > > >
> > > > > > > > > > > > Projects can establish their own policy on handling
> > > inactive
> > > > > > > > members,
> > > > > > > > > > as long as they apply it CONSISTENTLY.
> > > > > > > > > > >
> > > > > > > > > > > In addition, Dave and Tison both mentioned we have some
> > > boards
> > > > > or
> > > > > > > > > > > webpages to see how many people are active. We don't need
> > > to
> > > > > > remove
> > > > > > > > > > > some PMC members just for knowing who were still active
> > > > > recently.
> > > > > > > > > > >
> > > > > > > > > > > BTW, I'm also curious about the motivation of this
> > > proposal.
> > > > > I'm
> > > > > > > > > > > wondering how do the inactive PMC members harm the
> > > community?
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Yunze
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Mar 3, 2023 at 10:14 AM tison <
> > > wander4096@gmail.com>
> > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi,
> > > > > > > > > > > >
> > > > > > > > > > > > In the proposal, it's unclear if you'd like to _mark_ the
> > > > > > > inactive
> > > > > > > > > > members
> > > > > > > > > > > > in emeritus status or _remove_ them from the LDAP group.
> > > > > > > > > > > >
> > > > > > > > > > > > I saw a similar discussion in the Flink community,
> > > resulting
> > > > > in
> > > > > > > > > > "active"
> > > > > > > > > > > > sentences in its Bylaws[1]. Here is some consensus there:
> > > > > > > > > > > >
> > > > > > > > > > > > 1. Merits never expire. There's no reason to _remove_ a
> > > > > > committer
> > > > > > > > or
> > > > > > > > > > PMC
> > > > > > > > > > > > member from the LDAP group because of inactive following
> > > the
> > > > > > > Apache
> > > > > > > > > > way. I
> > > > > > > > > > > > remember numbered cases a member got removed because they
> > > > > > _keep_
> > > > > > > > > > harming
> > > > > > > > > > > > the community.
> > > > > > > > > > > > 2. Emeritus status is set for unblocking consensus. The
> > > Flink
> > > > > > > > > community
> > > > > > > > > > > > experienced some votes that could not get the required
> > > > > > approvals
> > > > > > > in
> > > > > > > > > > time
> > > > > > > > > > > > and thus tried to unblock consensus by setting some
> > > members
> > > > > > with
> > > > > > > > > > binding
> > > > > > > > > > > > votes in emeritus status. Do we spot concrete issues
> > > that the
> > > > > > > > Pulsar
> > > > > > > > > > > > community cannot work well with current PMC members and
> > > > > > > committers
> > > > > > > > > > group?
> > > > > > > > > > > > 3. Emeritus status is voluntary. I know that in other
> > > > > > > foundations,
> > > > > > > > it
> > > > > > > > > > can
> > > > > > > > > > > > be judged or eagerly applied, but in ASF, we share a
> > > > > "Community
> > > > > > > of
> > > > > > > > > > Peers"
> > > > > > > > > > > > sense that everyone is a volunteer. They won't be "fired"
> > > > > > because
> > > > > > > > of
> > > > > > > > > > "low
> > > > > > > > > > > > productivity".
> > > > > > > > > > > >
> > > > > > > > > > > > > Gain real visibility into the health of the project in
> > > > > terms
> > > > > > of
> > > > > > > > > real
> > > > > > > > > > > > active PMC / Committers members.
> > > > > > > > > > > >
> > > > > > > > > > > > On the community page, we already have a monthly active
> > > > > > > contributor
> > > > > > > > > > graph.
> > > > > > > > > > > > It's an insight concept; I don't think we should _remove_
> > > > > > members
> > > > > > > > for
> > > > > > > > > > such
> > > > > > > > > > > > a reason.
> > > > > > > > > > > >
> > > > > > > > > > > > > Have the alert threshold set correctly as to when it's
> > > time
> > > > > > to
> > > > > > > > > start
> > > > > > > > > > > > working on recruiting new PMC / Committers members
> > > > > > > > > > > >
> > > > > > > > > > > > Ditto. When working in the community, you will know what
> > > > > > modules
> > > > > > > or
> > > > > > > > > > repos
> > > > > > > > > > > > lack participants. For example, I remember someone
> > > proposing
> > > > > to
> > > > > > > > > promote
> > > > > > > > > > > > more committers working on Pulsar multilingual clients.
> > > It's
> > > > > > not
> > > > > > > a
> > > > > > > > > > reason
> > > > > > > > > > > > for emeritus or removal.
> > > > > > > > > > > >
> > > > > > > > > > > > ---
> > > > > > > > > > > >
> > > > > > > > > > > > Generally, committers and PMC members have "Earned
> > > Authority"
> > > > > > to
> > > > > > > be
> > > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > > > group. They share a high trust level, and I have numerous
> > > > > > > examples
> > > > > > > > > that
> > > > > > > > > > > > returned members do outstanding work. If we don't have
> > > some
> > > > > > > > critical
> > > > > > > > > > issues
> > > > > > > > > > > > to introduce an emeritus status, and such members do no
> > > harm,
> > > > > > why
> > > > > > > > do
> > > > > > > > > > we set
> > > > > > > > > > > > a bar if they return?
> > > > > > > > > > > >
> > > > > > > > > > > > Best,
> > > > > > > > > > > > tison.
> > > > > > > > > > > >
> > > > > > > > > > > > [1]
> > > > > > > https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Dave Fisher <wa...@apache.org> 于2023年3月3日周五 09:37写道：
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > >
> > > > > > > > > > > > > > On Mar 2, 2023, at 11:58 AM, Asaf Mesika <
> > > > > > > > asaf.mesika@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Following the discussion I've started in Pulsar
> > > bi-weekly
> > > > > > > > > meetings.
> > > > > > > > > > > > >
> > > > > > > > > > > > > As I said when you brought this up, I don’t think it
> > > is a
> > > > > > good
> > > > > > > > > idea,
> > > > > > > > > > not a
> > > > > > > > > > > > > good idea at all.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Projects can establish their own policy on handling
> > > > > > inactive
> > > > > > > > > > members, as
> > > > > > > > > > > > > > long as they apply it consistently.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > As a PMC member I have no desire to play a game of
> > > > > > consistently
> > > > > > > > > > tossing
> > > > > > > > > > > > > PMC members who somehow haven’t met an engagement
> > > criteria.
> > > > > > > That
> > > > > > > > is
> > > > > > > > > > an
> > > > > > > > > > > > > anti-pattern to building a community. It would be
> > > > > disruptive
> > > > > > > and
> > > > > > > > > time
> > > > > > > > > > > > > consuming.
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > = The idea
> > > > > > > > > > > > > > PMC and Committers members will transition into
> > > Emeritus
> > > > > > > status
> > > > > > > > > > after X
> > > > > > > > > > > > > > months of inactivity, or voluntarily.
> > > > > > > > > > > > >
> > > > > > > > > > > > > PMC members have the opportunity with or without this
> > > > > > proposal
> > > > > > > to
> > > > > > > > > > > > > voluntarily resign as PMC members with or without
> > > giving up
> > > > > > > their
> > > > > > > > > > commit
> > > > > > > > > > > > > bit.
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > = Why?
> > > > > > > > > > > > > > - Gain real visibility into the health of the
> > > project in
> > > > > > > terms
> > > > > > > > of
> > > > > > > > > > real
> > > > > > > > > > > > > > active PMC / Committers members.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Here is an exercise. Generate activity reports to show
> > > > > > > criteria.
> > > > > > > > We
> > > > > > > > > > can
> > > > > > > > > > > > > correlate between the rosters and all of our GitHub
> > > > > > > repositories.
> > > > > > > > > > Also
> > > > > > > > > > > > > Mailing lists and slack which only goes back 90 days. I
> > > > > would
> > > > > > > be
> > > > > > > > > > better
> > > > > > > > > > > > > persuaded if you did that to actually show and prove
> > > that
> > > > > > there
> > > > > > > > is
> > > > > > > > > a
> > > > > > > > > > > > > problem. I think you will find that it is a large
> > > amount of
> > > > > > > > effort
> > > > > > > > > > with
> > > > > > > > > > > > > little value in the end.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > - Have the alert threshold set correctly as to when
> > > it's
> > > > > > time
> > > > > > > > to
> > > > > > > > > > start
> > > > > > > > > > > > > > working on recruiting new PMC / Committers members.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Those two points are not coupled. We ARE ALWAYS be on
> > > the
> > > > > > alert
> > > > > > > > for
> > > > > > > > > > new
> > > > > > > > > > > > > committers and PMC Members. This PMC has been ACTIVE in
> > > > > > > > recognizing
> > > > > > > > > > many of
> > > > > > > > > > > > > those who are deserving.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Here are the Pulsar Board reports:
> > > > > > > > > > > > > https://whimsy.apache.org/board/minutes/Pulsar
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > = Is there any precedence?
> > > > > > > > > > > > > > Yes. A lot.
> > > > > > > > > > > > > > Many CNCF projects do it.
> > > > > > > > > > > > > > Many Apache projects do it.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I’ve been on many PMC’s and I cannot think of one that
> > > does
> > > > > > > this.
> > > > > > > > > > You’ve
> > > > > > > > > > > > > come up with a few examples below, but I won’t be
> > > > > persuaded.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Apache foundations rules allow it.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Read below to see examples and links.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > = Examples
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > === etcD project <
> > > > > > > > > > > > >
> > > https://github.com/etcd-io/etcd/blob/main/GOVERNANCE.md>
> > > > > > > > > > > > >
> > > > > > > > > > > > > I don’t care about how another Foundation does it.
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Quote
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Life priorities, interests, and passions can change.
> > > > > > > > Maintainers
> > > > > > > > > > can
> > > > > > > > > > > > > retire
> > > > > > > > > > > > > > and move to the emeritus status
> > > > > > > > > > > > > > <
> > > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > https://github.com/etcd-io/etcd/blob/main/README.md#etcd-emeritus-maintainers
> > > > > > > > > > > > > >.
> > > > > > > > > > > > > > If a maintainer needs to step down, they should
> > > inform
> > > > > > other
> > > > > > > > > > maintainers,
> > > > > > > > > > > > > > if possible, help find someone to pick up the related
> > > > > work.
> > > > > > > At
> > > > > > > > > the
> > > > > > > > > > very
> > > > > > > > > > > > > > least, ensure the related work can be continued.
> > > > > Afterward
> > > > > > > they
> > > > > > > > > can
> > > > > > > > > > > > > remove
> > > > > > > > > > > > > > themselves from list of existing maintainers.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If a maintainer is not been performing their duties
> > > for
> > > > > > > period
> > > > > > > > of
> > > > > > > > > > 12
> > > > > > > > > > > > > > months, they can be removed by other maintainers. In
> > > that
> > > > > > > case
> > > > > > > > > > inactive
> > > > > > > > > > > > > > maintainer will be first notified via an email. If
> > > > > > situation
> > > > > > > > > > doesn't
> > > > > > > > > > > > > > improve, they will be removed. If an emeritus
> > > maintainer
> > > > > > > wants
> > > > > > > > to
> > > > > > > > > > regain
> > > > > > > > > > > > > an
> > > > > > > > > > > > > > active role, they can do so by renewing their
> > > > > > contributions.
> > > > > > > > > Active
> > > > > > > > > > > > > > maintainers should welcome such a move. Retiring of
> > > other
> > > > > > > > > > maintainers or
> > > > > > > > > > > > > > regaining the status should require approval of at
> > > least
> > > > > > two
> > > > > > > > > active
> > > > > > > > > > > > > > maintainers.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > === Apache Gump
> > > > > > > > > > > > > > According to this link <
> > > > > > https://gump.apache.org/bylaws.html
> > > > > > > >,
> > > > > > > > > > they have
> > > > > > > > > > > > > > emeritus status for maintainers and PMC members and
> > > > > policy
> > > > > > to
> > > > > > > > > > transition.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Gump is a tiny project that does not release code. The
> > > two
> > > > > > PMC
> > > > > > > > > > members was
> > > > > > > > > > > > > added in 2014. The rest were in 2004 - 2006. The
> > > project
> > > > > is a
> > > > > > > > build
> > > > > > > > > > system
> > > > > > > > > > > > > that other projects used to use. I don’t even know if
> > > any
> > > > > > > project
> > > > > > > > > > still
> > > > > > > > > > > > > uses it. In fact that are just keeping it up for
> > > Tomcat.
> > > > > See
> > > > > > > > > > > > > https://whimsy.apache.org/board/minutes/Gump
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > QUOTE
> > > > > > > > > > > > > > Committer access is by invitation only and must be
> > > > > approved
> > > > > > > by
> > > > > > > > > lazy
> > > > > > > > > > > > > > consensus of the active PMC members. A Committer is
> > > > > > > considered
> > > > > > > > > > emeritus
> > > > > > > > > > > > > by
> > > > > > > > > > > > > > their own declaration or by not contributing in any
> > > form
> > > > > to
> > > > > > > the
> > > > > > > > > > project
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > over six months. An emeritus committer may request
> > > > > > > > reinstatement
> > > > > > > > > of
> > > > > > > > > > > > > commit
> > > > > > > > > > > > > > access from the PMC. Such reinstatement is subject to
> > > > > lazy
> > > > > > > > > > consensus of
> > > > > > > > > > > > > > active PMC members.
> > > > > > > > > > > > >
> > > > > > > > > > > > > All of their committers except for on of 16 are ASF
> > > > > Members.
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Membership of the PMC is by invitation only and must
> > > be
> > > > > > > > approved
> > > > > > > > > > by a
> > > > > > > > > > > > > lazy
> > > > > > > > > > > > > > consensus of active PMC members. A PMC member is
> > > > > considered
> > > > > > > > > > "emeritus" by
> > > > > > > > > > > > > > their own declaration or by not contributing in any
> > > form
> > > > > to
> > > > > > > the
> > > > > > > > > > project
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > over six months. An emeritus member may request
> > > > > > reinstatement
> > > > > > > > to
> > > > > > > > > > the PMC.
> > > > > > > > > > > > > > Such reinstatement is subject to lazy consensus of
> > > the
> > > > > > active
> > > > > > > > PMC
> > > > > > > > > > > > > members.
> > > > > > > > > > > > > > Membership of the PMC can be revoked by an unanimous
> > > vote
> > > > > > of
> > > > > > > > all
> > > > > > > > > > the
> > > > > > > > > > > > > active
> > > > > > > > > > > > > > PMC members other than the member in question.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > END QUOTE
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > There are many more: Apache Hive
> > > > > > > > > > > > > > <
> > > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Committers
> > > > > > > > > > > > > >,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hive has 56 PMC Members and 106 Committers. I can tell
> > > from
> > > > > > > their
> > > > > > > > > > roster
> > > > > > > > > > > > > that many do not seem to be engaged any more.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Board reports:
> > > > > https://whimsy.apache.org/board/minutes/Hive
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Apache Orc <
> > > > > > > > > > > > >
> > > > > > https://github.com/apache/orc/blob/main/site/develop/bylaws.md
> > > > > > > >,
> > > > > > > > > > > > >
> > > > > > > > > > > > > They are actively working to regrow, but I doubt they
> > > are
> > > > > > > kicking
> > > > > > > > > > out many
> > > > > > > > > > > > > PMC members. You could read their board reports:
> > > > > > > > > > > > > https://whimsy.apache.org/board/minutes/ORC
> > > > > > > > > > > > >
> > > > > > > > > > > > > > ...
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > = What does Apache thinks about this?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > According to this link <
> > > > > > > > > > https://www.apache.org/dev/pmc.html#pmc-removal
> > > > > > > > > > > > > >,
> > > > > > > > > > > > > > any project can have their policies for retire an
> > > > > inactive
> > > > > > > PMC
> > > > > > > > > > member.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > QUOTE
> > > > > > > > > > > > > > SHOULD A PMC REMOVE INACTIVE MEMBERS?
> > > > > > > > > > > > > > <https://www.apache.org/dev/pmc.html#pmc-removal>
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Projects can establish their own policy on handling
> > > > > > inactive
> > > > > > > > > > members, as
> > > > > > > > > > > > > > long as they apply it 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
> > > > > > > > > > > > > > (without that member's request or consent), 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 an
> > > email
> > > > > > to
> > > > > > > > the
> > > > > > > > > > board@
> > > > > > > > > > > > > > mailing list detailing the request for removal and
> > > the
> > > > > > > > > > justification the
> > > > > > > > > > > > > > PMC has for that removal, and copy the project's
> > > private@
> > > > > > > > list.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > END QUOTE
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > = Summary
> > > > > > > > > > > > > > I believe that Apache Pulsar has the responsibility
> > > with
> > > > > > > > respect
> > > > > > > > > > to its
> > > > > > > > > > > > > > users to reflect the real number of people actively
> > > in
> > > > > the
> > > > > > > > > project
> > > > > > > > > > - its
> > > > > > > > > > > > > > PMC members.
> > > > > > > > > > > > >
> > > > > > > > > > > > > How would you do it consistently? How would you measure
> > > > > > > > > > disengagement?
> > > > > > > > > > > > >
> > > > > > > > > > > > > The only fair way would be to go through the exercise
> > > of
> > > > > > > > measuring
> > > > > > > > > > actual
> > > > > > > > > > > > > engagement. Once you do I think that you will
> > > understand
> > > > > why
> > > > > > it
> > > > > > > > is
> > > > > > > > > > not
> > > > > > > > > > > > > really done.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Best,
> > > > > > > > > > > > > Dave
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >

Re: [DISCUSS] PMC/Committer Emiratus status

[Michael Marshall <mm...@apache.org>]

Stepping back slightly, this thread started with a desire to:

> Gain real visibility into the health of the project in terms of real
> active PMC / Committers members.

What if instead we ask how we as a community can show prospective and
new users that Apache Pulsar is a healthy project?

For me, when I first came to the Pulsar project, I didn't know
anything about The Apache Way, and I didn't know what a PMC was.
Instead, I thought the project seemed healthy because the tech was
exciting and when I opened GitHub issues, people who made many
contributions to the project answered my questions and helped me start
making my own contributions.

Each person will judge project health differently.

Our goal could be to identify key ways that Pulsar is healthy and
showcase those. We could also identify ways that we have room to grow
and discuss improving those on this list.

Some potentially meaningful measures of project health: accuracy and
helpfulness of documentation, release frequency, number of emails on
the mailing list, number of new committers/PMC members, number of
commits, time to first response on an opened GitHub
issue/discussion/pr, time to remediate security vulnerabilities,
successful upgrades with no surprises, and the list goes on.

In my experience, the user touch points like documentation and
responsiveness to questions matter most to users.

If we find that user issues/discussions are not getting feedback
quickly enough, perhaps it would be interesting to coordinate among
contributors times where a specific person volunteers to triage GitHub
issues and discussions. That could help lighten the load on some of
the main contributors that handle these tasks all of the time, while
also giving contributors a chance to gain experience in the project
and build merit in the project.

In response to the original proposal, I am not in favor of adding
active/inactive flags to PMC members and committers. Ultimately, I
think there are better ways to show our users that we have a healthy
project.

Thanks,
Michael


On Thu, Mar 9, 2023 at 3:22 AM Asaf Mesika <as...@gmail.com> wrote:
>
> Enrico, I was referring to this part of the quote:
>
> do a PMC roll
> > call on private@pulsar.a.o <ma...@pulsar.a.o> and ask whether
> > current PMC members self describe as “active” or “inactive”. That status
> > could then be reflected on the Community section of the pulsar website.
>
> The idea P. Taylor Goetz offered would be a yearly "chore" done by the PMC
> chair, helped by PMC members, to "poll" that status, verify it, and if all
> is verified, voted upon, then the website updated.
> In that suggestion, the website wouldn't rot, no?
> PMC membership / committer membership don't expire in that suggestion.
>
> On Tue, Mar 7, 2023 at 1:37 PM Enrico Olivelli <eo...@gmail.com> wrote:
>
> > Il giorno lun 6 mar 2023 alle ore 23:12 Asaf Mesika
> > <as...@gmail.com> ha scritto:
> > >
> > > Tison,
> > >
> > > The suggestion was stated a bit differently:
> > >
> > > Quote:
> > >
> > > Rather, I would recommend a project-level “active/inactive” flag that PMC
> > > members can voluntarily apply to themselves. For example, do a PMC roll
> > > call on private@pulsar.a.o <ma...@pulsar.a.o> and ask whether
> > > current PMC members self describe as “active” or “inactive”. That status
> > > could then be reflected on the Community section of the pulsar website.
> >
> > Websites tend to quickly become obsolete about this kind of thing,
> > because really
> > nobody takes care of its own "status" on a project, or that it is
> > "visible" on the website.
> > It is not for the benefit of anyone.
> >
> > Also when you become "inactive" you are for sure not interested in
> > updating the website, because you slowly
> > lose interest in the project :-)
> >
> > Everybody (should) participate as an individual, what's the benefit of
> > having you listed on the website ?
> >
> > I really remember the first time I was invited as a committer in an
> > ASF, I felt really proud of myself,
> > and also seeing myself listed in the main pom.xml of the project or in
> > the list of committers was cool.
> > So this is great for new contributors or in order to praise the
> > efforts of someone who spent so much
> > time in the community in order to be asked to join the group of people
> > responsible for the project.
> >
> > But after some time, when you participate in an OSS community, and you
> > really care about the project,
> > you don't care if you are listed here or there.
> >
> > Regarding the "themes" on which someone could be "more expert" or not.
> > This is also a piece of information that becomes obsolete.
> > The community is dynamic, people who "knew" well something in the past
> > but maybe they are no more up-to-date now.
> >
> > What's the goal ? To say Foo Bar is the "Pulsar Schema Registry expert" ?
> >
> > Personally I won't feel good to say that I am "the" expert for X, Y,
> > Z, even if there are a few places in which I have spent
> > days of work and I made substantial contributions (or new features
> > initially contributed by myself).
> >
> > If you want to reach out to someone expert on a piece of code you use
> > the GH UI and see the latest commits (of "git log")
> > or search into the mailing list archives or in the GH issues and you
> > will find the same names around a given topic.
> >
> > For Pulsar this is the OFFICIAL page of the folks that are
> > "responsible" for the project
> > https://people.apache.org/phonebook.html?pmc=pulsar
> >
> > If you really want to see who are the all the ASF committers you can
> > always go here
> > https://people.apache.org/committer-index.html
> >
> > If we want to list the PMC members/committers I suggest building
> > something automated that simply shows the list.
> >
> >
> > Enrico
> >
> >
> >
> >
> >
> > No > reply from a PMC member? Mark them inactive until they request a
> > change.
> > >
> > > End Quote
> > >
> > >
> > > On Mon, Mar 6, 2023 at 6:13 PM tison <wa...@gmail.com> wrote:
> > >
> > > > I won't object if any PMC member or committer is willing to set their
> > > > personal status; e.g., open to topics of a specific domain, "inactive"
> > > > or "don't
> > > > disturb"
> > > >
> > > > Best,
> > > > tison.
> > > >
> > > >
> > > > Asaf Mesika <as...@gmail.com> 于2023年3月7日周二 00:05写道：
> > > >
> > > > > Do other think it's a good thing to adopt P. Taylor Goetz idea of
> > active
> > > > > flag and the process suggested?
> > > > >
> > > > >
> > > > > On Mon, Mar 6, 2023 at 2:03 PM tison <wa...@gmail.com> wrote:
> > > > >
> > > > > > Hi Yu,
> > > > > >
> > > > > > You can start by adding a page on the contribution guide or a
> > table in
> > > > > the
> > > > > > README of the main repo/site repo to state that you're an expert
> > in the
> > > > > > document domain.
> > > > > >
> > > > > > I have an in-house landscape about Pulsar modules, the broader
> > > > ecosystem,
> > > > > > and their active contributors/maintainers. Since people may not
> > want to
> > > > > be
> > > > > > referred to publicly by another person, I don't make it public.
> > > > > >
> > > > > > Finding experts can be a skill to collaborate in a community. You
> > can
> > > > > find
> > > > > > them when browsing relative PRs, analyzing the commit history,
> > meeting
> > > > > them
> > > > > > in the community, and having conversations. I don't have the
> > motivation
> > > > > to
> > > > > > maintain such a table publicly.
> > > > > >
> > > > > > Scala has a table of domain experts that can help[1]. If you like
> > it,
> > > > you
> > > > > > can list yourself and try to bring other experts to list
> > themselves.
> > > > The
> > > > > > ASF shares a sense that "The Foundation belongs to *you*". You're
> > > > > already a
> > > > > > PMC member and able to drive such an effort.
> > > > > >
> > > > > > Best,
> > > > > > tison.
> > > > > >
> > > > > > [1] https://github.com/scala/scala#get-in-touch
> > > > > >
> > > > > >
> > > > > > Yu <li...@apache.org> 于2023年3月6日周一 19:48写道：
> > > > > >
> > > > > > > Hi Asaf,
> > > > > > >
> > > > > > > Thanks for bringing this up!
> > > > > > >
> > > > > > > If I may put my two pennies' worth:
> > > > > > >
> > > > > > > To be honest, this idea flashed across my mind previously. I
> > talked
> > > > > about
> > > > > > > this to my colleague, and he was surprised that I was willing to
> > be
> > > > > > > deprived of benefits (at that time, I was a PMC member already).
> > > > > > >
> > > > > > > PMC members are vital promotors and driving forces of a
> > community.
> > > > > > Ideally,
> > > > > > > they should be direction leaders and make great contributions
> > > > > > > *continuously*. No one should enjoy the benefits of honor but not
> > > > > > > contribute much *all the time*. Setting retirement bars for PMC
> > > > members
> > > > > > > reminds us to contribute and provide value. Maybe I'm a little
> > > > > aggressive
> > > > > > > :-)
> > > > > > >
> > > > > > > ~~~~~~
> > > > > > >
> > > > > > > +1 but a long list of PMC members with many inactive members
> > does not
> > > > > > > create a good feeling since "false prosperity" is no better than
> > > > "real
> > > > > > > contributions".
> > > > > > >
> > > > > > > > 3. Merit doesn’t expire.
> > > > > > >
> > > > > > > ~~~~~~
> > > > > > >
> > > > > > > Compared to my previous thought, Goetz has proposed a better idea
> > > > > since:
> > > > > > >
> > > > > > > 1. It's mild and can be accepted by many PMC members. A kind of
> > life
> > > > > > wisdom
> > > > > > > :-)
> > > > > > >
> > > > > > > 2. People who need help (e.g., PIP approvals / PR comments / ...)
> > > > from
> > > > > > PMC
> > > > > > > members can check the flags to know who is available to help.
> > > > > > >
> > > > > > > Except for flags, I suggest adding "area of expertise" for PMC
> > > > members
> > > > > > and
> > > > > > > committers, so people will know who are the most suitable
> > experts to
> > > > > ask
> > > > > > > for help or collaborate.
> > > > > > >
> > > > > > > > 1. You can maintain active/inactive status at the project level
> > > > with
> > > > > a
> > > > > > > simple flag on a community page, without removing people from the
> > > > PMC.
> > > > > > > > 2. By making it an informal, self-reported flag, you avoid the
> > > > > overhead
> > > > > > > of board resolutions, etc. and just manage it at the community
> > level.
> > > > > If
> > > > > > > someone wants to change their status, they can just say so or
> > submit
> > > > a
> > > > > > pull
> > > > > > > request to change their status on the pulsar website.
> > > > > > >
> > > > > > > ~~~~~~
> > > > > > >
> > > > > > > Yu
> > > > > > >
> > > > > > > On Sun, Mar 5, 2023 at 10:31 PM Asaf Mesika <
> > asaf.mesika@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Thanks to everyone who took the time to carefully answer with
> > > > > detailed
> > > > > > > > explanations.
> > > > > > > > I personally learned a lot about Apache projects this way
> > (made me
> > > > > read
> > > > > > > > about it some more).
> > > > > > > >
> > > > > > > > So my personal recap is:
> > > > > > > >
> > > > > > > >    - The goal of knowing the health of the Apache Pulsar
> > community
> > > > > can
> > > > > > be
> > > > > > > >    achieved by taking a look at monthly active contributors
> > over
> > > > time
> > > > > > > >    displayed on the community page.
> > > > > > > >       - It could be nice getting those numbers on the mailing
> > list
> > > > > > itself
> > > > > > > >       as well.
> > > > > > > >    - Calculating the engagement is not an easy task.
> > > > > > > >    - Kicking people off is not something you'd like to do in
> > > > general
> > > > > > and
> > > > > > > >    specifically for volunteers.
> > > > > > > >    - People's credit for work, which is also expressed in PMC
> > > > > > membership
> > > > > > > >    never expires due to Merit never expires - your work credit
> > and
> > > > > > earned
> > > > > > > >    right should not expire.
> > > > > > > >
> > > > > > > >
> > > > > > > > I personally see PMC members answering someone not a PMC member
> > > > nor a
> > > > > > > > comitter on this topic as a very healthy community indicator :)
> > > > > > > >
> > > > > > > > Thanks !
> > > > > > > >
> > > > > > > > Asaf
> > > > > > > >
> > > > > > > > On Fri, Mar 3, 2023 at 10:22 AM Enrico Olivelli <
> > > > eolivelli@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > This is an interesting discussion.
> > > > > > > > > Good to see this kind of a discussion on the dev@ mailing
> > list,
> > > > > this
> > > > > > > > > way more people are aware of the fact that we are a project
> > in
> > > > the
> > > > > > ASF
> > > > > > > > > and there is a Project Management Committee.
> > > > > > > > >
> > > > > > > > > I have been following a few Apache projects for a while, and
> > I
> > > > > > believe
> > > > > > > > > that this kind of discussions should be run on the private@
> > > > > mailing
> > > > > > > > > list.
> > > > > > > > > It is the PMC that usually deals with this stuff.
> > > > > > > > >
> > > > > > > > > As Tison said, the common practice is that you never remove
> > > > anyone
> > > > > > > > > from a PMC or from the Committers list.
> > > > > > > > >
> > > > > > > > > This happens only in rare cases where an individual behaves
> > in
> > > > > such a
> > > > > > > > > way that the Project or the Foundation could be damaged,
> > > > > > > > > for instance if you speak on behalf of the project and you
> > offend
> > > > > > > > > someone publicly.
> > > > > > > > >
> > > > > > > > > Inactive contributors/committers/PMC members do not do any
> > harm
> > > > to
> > > > > a
> > > > > > > > > project.
> > > > > > > > >
> > > > > > > > > Some projects have some rules that you cannot participate in
> > > > > official
> > > > > > > > > VOTEs if you are not "active".
> > > > > > > > >
> > > > > > > > > If anyone has some problems with someone in the community,
> > then
> > > > > they
> > > > > > > > > can reach out to private@pulsar.apache.org and the PMC will
> > > > listen
> > > > > > to
> > > > > > > > > the problem and take actions.
> > > > > > > > >
> > > > > > > > > my 2 cents
> > > > > > > > >
> > > > > > > > > Enrico
> > > > > > > > >
> > > > > > > > > Il giorno ven 3 mar 2023 alle ore 04:39 Yunze Xu
> > > > > > > > > <yz...@streamnative.io.invalid> ha scritto:
> > > > > > > > > >
> > > > > > > > > > As a PMC member, I don't like playing a game of
> > determining who
> > > > > > > should
> > > > > > > > > > be removed from PMC as well.
> > > > > > > > > >
> > > > > > > > > > I hear a viewpoint that someone is only participating in
> > the
> > > > > > > community
> > > > > > > > > > only to join a PMC so that he can benefit from it. After
> > > > > becoming a
> > > > > > > > > > PMC member, he is never active in the community. It might
> > be
> > > > true
> > > > > > but
> > > > > > > > > > I think it's acceptable. Making such a rule won't prevent
> > such
> > > > > > cases.
> > > > > > > > > > If he wants, he can make use of the rule and keep himself
> > > > > "active"
> > > > > > to
> > > > > > > > > > avoid being kicked out of the PMC. Though the active state
> > is
> > > > > fake.
> > > > > > > > > >
> > > > > > > > > > I'm not against the way to remove (or something else that
> > > > sounds
> > > > > > > good)
> > > > > > > > > > a PMC member because none of these ways is perfect.
> > However,
> > > > I'm
> > > > > > > > > > STRONGLY AGAINST changing a rule that has been applied for
> > some
> > > > > > time
> > > > > > > > > > unless it can be proved the rule is very harmful to the
> > > > > community.
> > > > > > > > > > You mentioned
> > https://www.apache.org/dev/pmc.html#pmc-removal.
> > > > > But
> > > > > > > > > > please don't ignore the first sentence:
> > > > > > > > > >
> > > > > > > > > > > Projects can establish their own policy on handling
> > inactive
> > > > > > > members,
> > > > > > > > > as long as they apply it CONSISTENTLY.
> > > > > > > > > >
> > > > > > > > > > In addition, Dave and Tison both mentioned we have some
> > boards
> > > > or
> > > > > > > > > > webpages to see how many people are active. We don't need
> > to
> > > > > remove
> > > > > > > > > > some PMC members just for knowing who were still active
> > > > recently.
> > > > > > > > > >
> > > > > > > > > > BTW, I'm also curious about the motivation of this
> > proposal.
> > > > I'm
> > > > > > > > > > wondering how do the inactive PMC members harm the
> > community?
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Yunze
> > > > > > > > > >
> > > > > > > > > > On Fri, Mar 3, 2023 at 10:14 AM tison <
> > wander4096@gmail.com>
> > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > In the proposal, it's unclear if you'd like to _mark_ the
> > > > > > inactive
> > > > > > > > > members
> > > > > > > > > > > in emeritus status or _remove_ them from the LDAP group.
> > > > > > > > > > >
> > > > > > > > > > > I saw a similar discussion in the Flink community,
> > resulting
> > > > in
> > > > > > > > > "active"
> > > > > > > > > > > sentences in its Bylaws[1]. Here is some consensus there:
> > > > > > > > > > >
> > > > > > > > > > > 1. Merits never expire. There's no reason to _remove_ a
> > > > > committer
> > > > > > > or
> > > > > > > > > PMC
> > > > > > > > > > > member from the LDAP group because of inactive following
> > the
> > > > > > Apache
> > > > > > > > > way. I
> > > > > > > > > > > remember numbered cases a member got removed because they
> > > > > _keep_
> > > > > > > > > harming
> > > > > > > > > > > the community.
> > > > > > > > > > > 2. Emeritus status is set for unblocking consensus. The
> > Flink
> > > > > > > > community
> > > > > > > > > > > experienced some votes that could not get the required
> > > > > approvals
> > > > > > in
> > > > > > > > > time
> > > > > > > > > > > and thus tried to unblock consensus by setting some
> > members
> > > > > with
> > > > > > > > > binding
> > > > > > > > > > > votes in emeritus status. Do we spot concrete issues
> > that the
> > > > > > > Pulsar
> > > > > > > > > > > community cannot work well with current PMC members and
> > > > > > committers
> > > > > > > > > group?
> > > > > > > > > > > 3. Emeritus status is voluntary. I know that in other
> > > > > > foundations,
> > > > > > > it
> > > > > > > > > can
> > > > > > > > > > > be judged or eagerly applied, but in ASF, we share a
> > > > "Community
> > > > > > of
> > > > > > > > > Peers"
> > > > > > > > > > > sense that everyone is a volunteer. They won't be "fired"
> > > > > because
> > > > > > > of
> > > > > > > > > "low
> > > > > > > > > > > productivity".
> > > > > > > > > > >
> > > > > > > > > > > > Gain real visibility into the health of the project in
> > > > terms
> > > > > of
> > > > > > > > real
> > > > > > > > > > > active PMC / Committers members.
> > > > > > > > > > >
> > > > > > > > > > > On the community page, we already have a monthly active
> > > > > > contributor
> > > > > > > > > graph.
> > > > > > > > > > > It's an insight concept; I don't think we should _remove_
> > > > > members
> > > > > > > for
> > > > > > > > > such
> > > > > > > > > > > a reason.
> > > > > > > > > > >
> > > > > > > > > > > > Have the alert threshold set correctly as to when it's
> > time
> > > > > to
> > > > > > > > start
> > > > > > > > > > > working on recruiting new PMC / Committers members
> > > > > > > > > > >
> > > > > > > > > > > Ditto. When working in the community, you will know what
> > > > > modules
> > > > > > or
> > > > > > > > > repos
> > > > > > > > > > > lack participants. For example, I remember someone
> > proposing
> > > > to
> > > > > > > > promote
> > > > > > > > > > > more committers working on Pulsar multilingual clients.
> > It's
> > > > > not
> > > > > > a
> > > > > > > > > reason
> > > > > > > > > > > for emeritus or removal.
> > > > > > > > > > >
> > > > > > > > > > > ---
> > > > > > > > > > >
> > > > > > > > > > > Generally, committers and PMC members have "Earned
> > Authority"
> > > > > to
> > > > > > be
> > > > > > > > in
> > > > > > > > > the
> > > > > > > > > > > group. They share a high trust level, and I have numerous
> > > > > > examples
> > > > > > > > that
> > > > > > > > > > > returned members do outstanding work. If we don't have
> > some
> > > > > > > critical
> > > > > > > > > issues
> > > > > > > > > > > to introduce an emeritus status, and such members do no
> > harm,
> > > > > why
> > > > > > > do
> > > > > > > > > we set
> > > > > > > > > > > a bar if they return?
> > > > > > > > > > >
> > > > > > > > > > > Best,
> > > > > > > > > > > tison.
> > > > > > > > > > >
> > > > > > > > > > > [1]
> > > > > > https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Dave Fisher <wa...@apache.org> 于2023年3月3日周五 09:37写道：
> > > > > > > > > > >
> > > > > > > > > > > > Hi,
> > > > > > > > > > > >
> > > > > > > > > > > > > On Mar 2, 2023, at 11:58 AM, Asaf Mesika <
> > > > > > > asaf.mesika@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Following the discussion I've started in Pulsar
> > bi-weekly
> > > > > > > > meetings.
> > > > > > > > > > > >
> > > > > > > > > > > > As I said when you brought this up, I don’t think it
> > is a
> > > > > good
> > > > > > > > idea,
> > > > > > > > > not a
> > > > > > > > > > > > good idea at all.
> > > > > > > > > > > >
> > > > > > > > > > > > > Projects can establish their own policy on handling
> > > > > inactive
> > > > > > > > > members, as
> > > > > > > > > > > > > long as they apply it consistently.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > As a PMC member I have no desire to play a game of
> > > > > consistently
> > > > > > > > > tossing
> > > > > > > > > > > > PMC members who somehow haven’t met an engagement
> > criteria.
> > > > > > That
> > > > > > > is
> > > > > > > > > an
> > > > > > > > > > > > anti-pattern to building a community. It would be
> > > > disruptive
> > > > > > and
> > > > > > > > time
> > > > > > > > > > > > consuming.
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > = The idea
> > > > > > > > > > > > > PMC and Committers members will transition into
> > Emeritus
> > > > > > status
> > > > > > > > > after X
> > > > > > > > > > > > > months of inactivity, or voluntarily.
> > > > > > > > > > > >
> > > > > > > > > > > > PMC members have the opportunity with or without this
> > > > > proposal
> > > > > > to
> > > > > > > > > > > > voluntarily resign as PMC members with or without
> > giving up
> > > > > > their
> > > > > > > > > commit
> > > > > > > > > > > > bit.
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > = Why?
> > > > > > > > > > > > > - Gain real visibility into the health of the
> > project in
> > > > > > terms
> > > > > > > of
> > > > > > > > > real
> > > > > > > > > > > > > active PMC / Committers members.
> > > > > > > > > > > >
> > > > > > > > > > > > Here is an exercise. Generate activity reports to show
> > > > > > criteria.
> > > > > > > We
> > > > > > > > > can
> > > > > > > > > > > > correlate between the rosters and all of our GitHub
> > > > > > repositories.
> > > > > > > > > Also
> > > > > > > > > > > > Mailing lists and slack which only goes back 90 days. I
> > > > would
> > > > > > be
> > > > > > > > > better
> > > > > > > > > > > > persuaded if you did that to actually show and prove
> > that
> > > > > there
> > > > > > > is
> > > > > > > > a
> > > > > > > > > > > > problem. I think you will find that it is a large
> > amount of
> > > > > > > effort
> > > > > > > > > with
> > > > > > > > > > > > little value in the end.
> > > > > > > > > > > >
> > > > > > > > > > > > > - Have the alert threshold set correctly as to when
> > it's
> > > > > time
> > > > > > > to
> > > > > > > > > start
> > > > > > > > > > > > > working on recruiting new PMC / Committers members.
> > > > > > > > > > > >
> > > > > > > > > > > > Those two points are not coupled. We ARE ALWAYS be on
> > the
> > > > > alert
> > > > > > > for
> > > > > > > > > new
> > > > > > > > > > > > committers and PMC Members. This PMC has been ACTIVE in
> > > > > > > recognizing
> > > > > > > > > many of
> > > > > > > > > > > > those who are deserving.
> > > > > > > > > > > >
> > > > > > > > > > > > Here are the Pulsar Board reports:
> > > > > > > > > > > > https://whimsy.apache.org/board/minutes/Pulsar
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > = Is there any precedence?
> > > > > > > > > > > > > Yes. A lot.
> > > > > > > > > > > > > Many CNCF projects do it.
> > > > > > > > > > > > > Many Apache projects do it.
> > > > > > > > > > > >
> > > > > > > > > > > > I’ve been on many PMC’s and I cannot think of one that
> > does
> > > > > > this.
> > > > > > > > > You’ve
> > > > > > > > > > > > come up with a few examples below, but I won’t be
> > > > persuaded.
> > > > > > > > > > > >
> > > > > > > > > > > > > Apache foundations rules allow it.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Read below to see examples and links.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > = Examples
> > > > > > > > > > > > >
> > > > > > > > > > > > > === etcD project <
> > > > > > > > > > > >
> > https://github.com/etcd-io/etcd/blob/main/GOVERNANCE.md>
> > > > > > > > > > > >
> > > > > > > > > > > > I don’t care about how another Foundation does it.
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Quote
> > > > > > > > > > > > >
> > > > > > > > > > > > > Life priorities, interests, and passions can change.
> > > > > > > Maintainers
> > > > > > > > > can
> > > > > > > > > > > > retire
> > > > > > > > > > > > > and move to the emeritus status
> > > > > > > > > > > > > <
> > > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://github.com/etcd-io/etcd/blob/main/README.md#etcd-emeritus-maintainers
> > > > > > > > > > > > >.
> > > > > > > > > > > > > If a maintainer needs to step down, they should
> > inform
> > > > > other
> > > > > > > > > maintainers,
> > > > > > > > > > > > > if possible, help find someone to pick up the related
> > > > work.
> > > > > > At
> > > > > > > > the
> > > > > > > > > very
> > > > > > > > > > > > > least, ensure the related work can be continued.
> > > > Afterward
> > > > > > they
> > > > > > > > can
> > > > > > > > > > > > remove
> > > > > > > > > > > > > themselves from list of existing maintainers.
> > > > > > > > > > > > >
> > > > > > > > > > > > > If a maintainer is not been performing their duties
> > for
> > > > > > period
> > > > > > > of
> > > > > > > > > 12
> > > > > > > > > > > > > months, they can be removed by other maintainers. In
> > that
> > > > > > case
> > > > > > > > > inactive
> > > > > > > > > > > > > maintainer will be first notified via an email. If
> > > > > situation
> > > > > > > > > doesn't
> > > > > > > > > > > > > improve, they will be removed. If an emeritus
> > maintainer
> > > > > > wants
> > > > > > > to
> > > > > > > > > regain
> > > > > > > > > > > > an
> > > > > > > > > > > > > active role, they can do so by renewing their
> > > > > contributions.
> > > > > > > > Active
> > > > > > > > > > > > > maintainers should welcome such a move. Retiring of
> > other
> > > > > > > > > maintainers or
> > > > > > > > > > > > > regaining the status should require approval of at
> > least
> > > > > two
> > > > > > > > active
> > > > > > > > > > > > > maintainers.
> > > > > > > > > > > > >
> > > > > > > > > > > > > === Apache Gump
> > > > > > > > > > > > > According to this link <
> > > > > https://gump.apache.org/bylaws.html
> > > > > > >,
> > > > > > > > > they have
> > > > > > > > > > > > > emeritus status for maintainers and PMC members and
> > > > policy
> > > > > to
> > > > > > > > > transition.
> > > > > > > > > > > >
> > > > > > > > > > > > Gump is a tiny project that does not release code. The
> > two
> > > > > PMC
> > > > > > > > > members was
> > > > > > > > > > > > added in 2014. The rest were in 2004 - 2006. The
> > project
> > > > is a
> > > > > > > build
> > > > > > > > > system
> > > > > > > > > > > > that other projects used to use. I don’t even know if
> > any
> > > > > > project
> > > > > > > > > still
> > > > > > > > > > > > uses it. In fact that are just keeping it up for
> > Tomcat.
> > > > See
> > > > > > > > > > > > https://whimsy.apache.org/board/minutes/Gump
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > QUOTE
> > > > > > > > > > > > > Committer access is by invitation only and must be
> > > > approved
> > > > > > by
> > > > > > > > lazy
> > > > > > > > > > > > > consensus of the active PMC members. A Committer is
> > > > > > considered
> > > > > > > > > emeritus
> > > > > > > > > > > > by
> > > > > > > > > > > > > their own declaration or by not contributing in any
> > form
> > > > to
> > > > > > the
> > > > > > > > > project
> > > > > > > > > > > > for
> > > > > > > > > > > > > over six months. An emeritus committer may request
> > > > > > > reinstatement
> > > > > > > > of
> > > > > > > > > > > > commit
> > > > > > > > > > > > > access from the PMC. Such reinstatement is subject to
> > > > lazy
> > > > > > > > > consensus of
> > > > > > > > > > > > > active PMC members.
> > > > > > > > > > > >
> > > > > > > > > > > > All of their committers except for on of 16 are ASF
> > > > Members.
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Membership of the PMC is by invitation only and must
> > be
> > > > > > > approved
> > > > > > > > > by a
> > > > > > > > > > > > lazy
> > > > > > > > > > > > > consensus of active PMC members. A PMC member is
> > > > considered
> > > > > > > > > "emeritus" by
> > > > > > > > > > > > > their own declaration or by not contributing in any
> > form
> > > > to
> > > > > > the
> > > > > > > > > project
> > > > > > > > > > > > for
> > > > > > > > > > > > > over six months. An emeritus member may request
> > > > > reinstatement
> > > > > > > to
> > > > > > > > > the PMC.
> > > > > > > > > > > > > Such reinstatement is subject to lazy consensus of
> > the
> > > > > active
> > > > > > > PMC
> > > > > > > > > > > > members.
> > > > > > > > > > > > > Membership of the PMC can be revoked by an unanimous
> > vote
> > > > > of
> > > > > > > all
> > > > > > > > > the
> > > > > > > > > > > > active
> > > > > > > > > > > > > PMC members other than the member in question.
> > > > > > > > > > > > >
> > > > > > > > > > > > > END QUOTE
> > > > > > > > > > > > >
> > > > > > > > > > > > > There are many more: Apache Hive
> > > > > > > > > > > > > <
> > > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Committers
> > > > > > > > > > > > >,
> > > > > > > > > > > >
> > > > > > > > > > > > Hive has 56 PMC Members and 106 Committers. I can tell
> > from
> > > > > > their
> > > > > > > > > roster
> > > > > > > > > > > > that many do not seem to be engaged any more.
> > > > > > > > > > > >
> > > > > > > > > > > > Board reports:
> > > > https://whimsy.apache.org/board/minutes/Hive
> > > > > > > > > > > >
> > > > > > > > > > > > > Apache Orc <
> > > > > > > > > > > >
> > > > > https://github.com/apache/orc/blob/main/site/develop/bylaws.md
> > > > > > >,
> > > > > > > > > > > >
> > > > > > > > > > > > They are actively working to regrow, but I doubt they
> > are
> > > > > > kicking
> > > > > > > > > out many
> > > > > > > > > > > > PMC members. You could read their board reports:
> > > > > > > > > > > > https://whimsy.apache.org/board/minutes/ORC
> > > > > > > > > > > >
> > > > > > > > > > > > > ...
> > > > > > > > > > > > >
> > > > > > > > > > > > > = What does Apache thinks about this?
> > > > > > > > > > > > >
> > > > > > > > > > > > > According to this link <
> > > > > > > > > https://www.apache.org/dev/pmc.html#pmc-removal
> > > > > > > > > > > > >,
> > > > > > > > > > > > > any project can have their policies for retire an
> > > > inactive
> > > > > > PMC
> > > > > > > > > member.
> > > > > > > > > > > > >
> > > > > > > > > > > > > QUOTE
> > > > > > > > > > > > > SHOULD A PMC REMOVE INACTIVE MEMBERS?
> > > > > > > > > > > > > <https://www.apache.org/dev/pmc.html#pmc-removal>
> > > > > > > > > > > > >
> > > > > > > > > > > > > Projects can establish their own policy on handling
> > > > > inactive
> > > > > > > > > members, as
> > > > > > > > > > > > > long as they apply it 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
> > > > > > > > > > > > > (without that member's request or consent), 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 an
> > email
> > > > > to
> > > > > > > the
> > > > > > > > > board@
> > > > > > > > > > > > > mailing list detailing the request for removal and
> > the
> > > > > > > > > justification the
> > > > > > > > > > > > > PMC has for that removal, and copy the project's
> > private@
> > > > > > > list.
> > > > > > > > > > > > >
> > > > > > > > > > > > > END QUOTE
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > = Summary
> > > > > > > > > > > > > I believe that Apache Pulsar has the responsibility
> > with
> > > > > > > respect
> > > > > > > > > to its
> > > > > > > > > > > > > users to reflect the real number of people actively
> > in
> > > > the
> > > > > > > > project
> > > > > > > > > - its
> > > > > > > > > > > > > PMC members.
> > > > > > > > > > > >
> > > > > > > > > > > > How would you do it consistently? How would you measure
> > > > > > > > > disengagement?
> > > > > > > > > > > >
> > > > > > > > > > > > The only fair way would be to go through the exercise
> > of
> > > > > > > measuring
> > > > > > > > > actual
> > > > > > > > > > > > engagement. Once you do I think that you will
> > understand
> > > > why
> > > > > it
> > > > > > > is
> > > > > > > > > not
> > > > > > > > > > > > really done.
> > > > > > > > > > > >
> > > > > > > > > > > > Best,
> > > > > > > > > > > > Dave
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >

Re: [DISCUSS] PMC/Committer Emiratus status

[Asaf Mesika <as...@gmail.com>]

Enrico, I was referring to this part of the quote:

do a PMC roll
> call on private@pulsar.a.o <ma...@pulsar.a.o> and ask whether
> current PMC members self describe as “active” or “inactive”. That status
> could then be reflected on the Community section of the pulsar website.

The idea P. Taylor Goetz offered would be a yearly "chore" done by the PMC
chair, helped by PMC members, to "poll" that status, verify it, and if all
is verified, voted upon, then the website updated.
In that suggestion, the website wouldn't rot, no?
PMC membership / committer membership don't expire in that suggestion.

On Tue, Mar 7, 2023 at 1:37 PM Enrico Olivelli <eo...@gmail.com> wrote:

> Il giorno lun 6 mar 2023 alle ore 23:12 Asaf Mesika
> <as...@gmail.com> ha scritto:
> >
> > Tison,
> >
> > The suggestion was stated a bit differently:
> >
> > Quote:
> >
> > Rather, I would recommend a project-level “active/inactive” flag that PMC
> > members can voluntarily apply to themselves. For example, do a PMC roll
> > call on private@pulsar.a.o <ma...@pulsar.a.o> and ask whether
> > current PMC members self describe as “active” or “inactive”. That status
> > could then be reflected on the Community section of the pulsar website.
>
> Websites tend to quickly become obsolete about this kind of thing,
> because really
> nobody takes care of its own "status" on a project, or that it is
> "visible" on the website.
> It is not for the benefit of anyone.
>
> Also when you become "inactive" you are for sure not interested in
> updating the website, because you slowly
> lose interest in the project :-)
>
> Everybody (should) participate as an individual, what's the benefit of
> having you listed on the website ?
>
> I really remember the first time I was invited as a committer in an
> ASF, I felt really proud of myself,
> and also seeing myself listed in the main pom.xml of the project or in
> the list of committers was cool.
> So this is great for new contributors or in order to praise the
> efforts of someone who spent so much
> time in the community in order to be asked to join the group of people
> responsible for the project.
>
> But after some time, when you participate in an OSS community, and you
> really care about the project,
> you don't care if you are listed here or there.
>
> Regarding the "themes" on which someone could be "more expert" or not.
> This is also a piece of information that becomes obsolete.
> The community is dynamic, people who "knew" well something in the past
> but maybe they are no more up-to-date now.
>
> What's the goal ? To say Foo Bar is the "Pulsar Schema Registry expert" ?
>
> Personally I won't feel good to say that I am "the" expert for X, Y,
> Z, even if there are a few places in which I have spent
> days of work and I made substantial contributions (or new features
> initially contributed by myself).
>
> If you want to reach out to someone expert on a piece of code you use
> the GH UI and see the latest commits (of "git log")
> or search into the mailing list archives or in the GH issues and you
> will find the same names around a given topic.
>
> For Pulsar this is the OFFICIAL page of the folks that are
> "responsible" for the project
> https://people.apache.org/phonebook.html?pmc=pulsar
>
> If you really want to see who are the all the ASF committers you can
> always go here
> https://people.apache.org/committer-index.html
>
> If we want to list the PMC members/committers I suggest building
> something automated that simply shows the list.
>
>
> Enrico
>
>
>
>
>
> No > reply from a PMC member? Mark them inactive until they request a
> change.
> >
> > End Quote
> >
> >
> > On Mon, Mar 6, 2023 at 6:13 PM tison <wa...@gmail.com> wrote:
> >
> > > I won't object if any PMC member or committer is willing to set their
> > > personal status; e.g., open to topics of a specific domain, "inactive"
> > > or "don't
> > > disturb"
> > >
> > > Best,
> > > tison.
> > >
> > >
> > > Asaf Mesika <as...@gmail.com> 于2023年3月7日周二 00:05写道：
> > >
> > > > Do other think it's a good thing to adopt P. Taylor Goetz idea of
> active
> > > > flag and the process suggested?
> > > >
> > > >
> > > > On Mon, Mar 6, 2023 at 2:03 PM tison <wa...@gmail.com> wrote:
> > > >
> > > > > Hi Yu,
> > > > >
> > > > > You can start by adding a page on the contribution guide or a
> table in
> > > > the
> > > > > README of the main repo/site repo to state that you're an expert
> in the
> > > > > document domain.
> > > > >
> > > > > I have an in-house landscape about Pulsar modules, the broader
> > > ecosystem,
> > > > > and their active contributors/maintainers. Since people may not
> want to
> > > > be
> > > > > referred to publicly by another person, I don't make it public.
> > > > >
> > > > > Finding experts can be a skill to collaborate in a community. You
> can
> > > > find
> > > > > them when browsing relative PRs, analyzing the commit history,
> meeting
> > > > them
> > > > > in the community, and having conversations. I don't have the
> motivation
> > > > to
> > > > > maintain such a table publicly.
> > > > >
> > > > > Scala has a table of domain experts that can help[1]. If you like
> it,
> > > you
> > > > > can list yourself and try to bring other experts to list
> themselves.
> > > The
> > > > > ASF shares a sense that "The Foundation belongs to *you*". You're
> > > > already a
> > > > > PMC member and able to drive such an effort.
> > > > >
> > > > > Best,
> > > > > tison.
> > > > >
> > > > > [1] https://github.com/scala/scala#get-in-touch
> > > > >
> > > > >
> > > > > Yu <li...@apache.org> 于2023年3月6日周一 19:48写道：
> > > > >
> > > > > > Hi Asaf,
> > > > > >
> > > > > > Thanks for bringing this up!
> > > > > >
> > > > > > If I may put my two pennies' worth:
> > > > > >
> > > > > > To be honest, this idea flashed across my mind previously. I
> talked
> > > > about
> > > > > > this to my colleague, and he was surprised that I was willing to
> be
> > > > > > deprived of benefits (at that time, I was a PMC member already).
> > > > > >
> > > > > > PMC members are vital promotors and driving forces of a
> community.
> > > > > Ideally,
> > > > > > they should be direction leaders and make great contributions
> > > > > > *continuously*. No one should enjoy the benefits of honor but not
> > > > > > contribute much *all the time*. Setting retirement bars for PMC
> > > members
> > > > > > reminds us to contribute and provide value. Maybe I'm a little
> > > > aggressive
> > > > > > :-)
> > > > > >
> > > > > > ~~~~~~
> > > > > >
> > > > > > +1 but a long list of PMC members with many inactive members
> does not
> > > > > > create a good feeling since "false prosperity" is no better than
> > > "real
> > > > > > contributions".
> > > > > >
> > > > > > > 3. Merit doesn’t expire.
> > > > > >
> > > > > > ~~~~~~
> > > > > >
> > > > > > Compared to my previous thought, Goetz has proposed a better idea
> > > > since:
> > > > > >
> > > > > > 1. It's mild and can be accepted by many PMC members. A kind of
> life
> > > > > wisdom
> > > > > > :-)
> > > > > >
> > > > > > 2. People who need help (e.g., PIP approvals / PR comments / ...)
> > > from
> > > > > PMC
> > > > > > members can check the flags to know who is available to help.
> > > > > >
> > > > > > Except for flags, I suggest adding "area of expertise" for PMC
> > > members
> > > > > and
> > > > > > committers, so people will know who are the most suitable
> experts to
> > > > ask
> > > > > > for help or collaborate.
> > > > > >
> > > > > > > 1. You can maintain active/inactive status at the project level
> > > with
> > > > a
> > > > > > simple flag on a community page, without removing people from the
> > > PMC.
> > > > > > > 2. By making it an informal, self-reported flag, you avoid the
> > > > overhead
> > > > > > of board resolutions, etc. and just manage it at the community
> level.
> > > > If
> > > > > > someone wants to change their status, they can just say so or
> submit
> > > a
> > > > > pull
> > > > > > request to change their status on the pulsar website.
> > > > > >
> > > > > > ~~~~~~
> > > > > >
> > > > > > Yu
> > > > > >
> > > > > > On Sun, Mar 5, 2023 at 10:31 PM Asaf Mesika <
> asaf.mesika@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Thanks to everyone who took the time to carefully answer with
> > > > detailed
> > > > > > > explanations.
> > > > > > > I personally learned a lot about Apache projects this way
> (made me
> > > > read
> > > > > > > about it some more).
> > > > > > >
> > > > > > > So my personal recap is:
> > > > > > >
> > > > > > >    - The goal of knowing the health of the Apache Pulsar
> community
> > > > can
> > > > > be
> > > > > > >    achieved by taking a look at monthly active contributors
> over
> > > time
> > > > > > >    displayed on the community page.
> > > > > > >       - It could be nice getting those numbers on the mailing
> list
> > > > > itself
> > > > > > >       as well.
> > > > > > >    - Calculating the engagement is not an easy task.
> > > > > > >    - Kicking people off is not something you'd like to do in
> > > general
> > > > > and
> > > > > > >    specifically for volunteers.
> > > > > > >    - People's credit for work, which is also expressed in PMC
> > > > > membership
> > > > > > >    never expires due to Merit never expires - your work credit
> and
> > > > > earned
> > > > > > >    right should not expire.
> > > > > > >
> > > > > > >
> > > > > > > I personally see PMC members answering someone not a PMC member
> > > nor a
> > > > > > > comitter on this topic as a very healthy community indicator :)
> > > > > > >
> > > > > > > Thanks !
> > > > > > >
> > > > > > > Asaf
> > > > > > >
> > > > > > > On Fri, Mar 3, 2023 at 10:22 AM Enrico Olivelli <
> > > eolivelli@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > This is an interesting discussion.
> > > > > > > > Good to see this kind of a discussion on the dev@ mailing
> list,
> > > > this
> > > > > > > > way more people are aware of the fact that we are a project
> in
> > > the
> > > > > ASF
> > > > > > > > and there is a Project Management Committee.
> > > > > > > >
> > > > > > > > I have been following a few Apache projects for a while, and
> I
> > > > > believe
> > > > > > > > that this kind of discussions should be run on the private@
> > > > mailing
> > > > > > > > list.
> > > > > > > > It is the PMC that usually deals with this stuff.
> > > > > > > >
> > > > > > > > As Tison said, the common practice is that you never remove
> > > anyone
> > > > > > > > from a PMC or from the Committers list.
> > > > > > > >
> > > > > > > > This happens only in rare cases where an individual behaves
> in
> > > > such a
> > > > > > > > way that the Project or the Foundation could be damaged,
> > > > > > > > for instance if you speak on behalf of the project and you
> offend
> > > > > > > > someone publicly.
> > > > > > > >
> > > > > > > > Inactive contributors/committers/PMC members do not do any
> harm
> > > to
> > > > a
> > > > > > > > project.
> > > > > > > >
> > > > > > > > Some projects have some rules that you cannot participate in
> > > > official
> > > > > > > > VOTEs if you are not "active".
> > > > > > > >
> > > > > > > > If anyone has some problems with someone in the community,
> then
> > > > they
> > > > > > > > can reach out to private@pulsar.apache.org and the PMC will
> > > listen
> > > > > to
> > > > > > > > the problem and take actions.
> > > > > > > >
> > > > > > > > my 2 cents
> > > > > > > >
> > > > > > > > Enrico
> > > > > > > >
> > > > > > > > Il giorno ven 3 mar 2023 alle ore 04:39 Yunze Xu
> > > > > > > > <yz...@streamnative.io.invalid> ha scritto:
> > > > > > > > >
> > > > > > > > > As a PMC member, I don't like playing a game of
> determining who
> > > > > > should
> > > > > > > > > be removed from PMC as well.
> > > > > > > > >
> > > > > > > > > I hear a viewpoint that someone is only participating in
> the
> > > > > > community
> > > > > > > > > only to join a PMC so that he can benefit from it. After
> > > > becoming a
> > > > > > > > > PMC member, he is never active in the community. It might
> be
> > > true
> > > > > but
> > > > > > > > > I think it's acceptable. Making such a rule won't prevent
> such
> > > > > cases.
> > > > > > > > > If he wants, he can make use of the rule and keep himself
> > > > "active"
> > > > > to
> > > > > > > > > avoid being kicked out of the PMC. Though the active state
> is
> > > > fake.
> > > > > > > > >
> > > > > > > > > I'm not against the way to remove (or something else that
> > > sounds
> > > > > > good)
> > > > > > > > > a PMC member because none of these ways is perfect.
> However,
> > > I'm
> > > > > > > > > STRONGLY AGAINST changing a rule that has been applied for
> some
> > > > > time
> > > > > > > > > unless it can be proved the rule is very harmful to the
> > > > community.
> > > > > > > > > You mentioned
> https://www.apache.org/dev/pmc.html#pmc-removal.
> > > > But
> > > > > > > > > please don't ignore the first sentence:
> > > > > > > > >
> > > > > > > > > > Projects can establish their own policy on handling
> inactive
> > > > > > members,
> > > > > > > > as long as they apply it CONSISTENTLY.
> > > > > > > > >
> > > > > > > > > In addition, Dave and Tison both mentioned we have some
> boards
> > > or
> > > > > > > > > webpages to see how many people are active. We don't need
> to
> > > > remove
> > > > > > > > > some PMC members just for knowing who were still active
> > > recently.
> > > > > > > > >
> > > > > > > > > BTW, I'm also curious about the motivation of this
> proposal.
> > > I'm
> > > > > > > > > wondering how do the inactive PMC members harm the
> community?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Yunze
> > > > > > > > >
> > > > > > > > > On Fri, Mar 3, 2023 at 10:14 AM tison <
> wander4096@gmail.com>
> > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > In the proposal, it's unclear if you'd like to _mark_ the
> > > > > inactive
> > > > > > > > members
> > > > > > > > > > in emeritus status or _remove_ them from the LDAP group.
> > > > > > > > > >
> > > > > > > > > > I saw a similar discussion in the Flink community,
> resulting
> > > in
> > > > > > > > "active"
> > > > > > > > > > sentences in its Bylaws[1]. Here is some consensus there:
> > > > > > > > > >
> > > > > > > > > > 1. Merits never expire. There's no reason to _remove_ a
> > > > committer
> > > > > > or
> > > > > > > > PMC
> > > > > > > > > > member from the LDAP group because of inactive following
> the
> > > > > Apache
> > > > > > > > way. I
> > > > > > > > > > remember numbered cases a member got removed because they
> > > > _keep_
> > > > > > > > harming
> > > > > > > > > > the community.
> > > > > > > > > > 2. Emeritus status is set for unblocking consensus. The
> Flink
> > > > > > > community
> > > > > > > > > > experienced some votes that could not get the required
> > > > approvals
> > > > > in
> > > > > > > > time
> > > > > > > > > > and thus tried to unblock consensus by setting some
> members
> > > > with
> > > > > > > > binding
> > > > > > > > > > votes in emeritus status. Do we spot concrete issues
> that the
> > > > > > Pulsar
> > > > > > > > > > community cannot work well with current PMC members and
> > > > > committers
> > > > > > > > group?
> > > > > > > > > > 3. Emeritus status is voluntary. I know that in other
> > > > > foundations,
> > > > > > it
> > > > > > > > can
> > > > > > > > > > be judged or eagerly applied, but in ASF, we share a
> > > "Community
> > > > > of
> > > > > > > > Peers"
> > > > > > > > > > sense that everyone is a volunteer. They won't be "fired"
> > > > because
> > > > > > of
> > > > > > > > "low
> > > > > > > > > > productivity".
> > > > > > > > > >
> > > > > > > > > > > Gain real visibility into the health of the project in
> > > terms
> > > > of
> > > > > > > real
> > > > > > > > > > active PMC / Committers members.
> > > > > > > > > >
> > > > > > > > > > On the community page, we already have a monthly active
> > > > > contributor
> > > > > > > > graph.
> > > > > > > > > > It's an insight concept; I don't think we should _remove_
> > > > members
> > > > > > for
> > > > > > > > such
> > > > > > > > > > a reason.
> > > > > > > > > >
> > > > > > > > > > > Have the alert threshold set correctly as to when it's
> time
> > > > to
> > > > > > > start
> > > > > > > > > > working on recruiting new PMC / Committers members
> > > > > > > > > >
> > > > > > > > > > Ditto. When working in the community, you will know what
> > > > modules
> > > > > or
> > > > > > > > repos
> > > > > > > > > > lack participants. For example, I remember someone
> proposing
> > > to
> > > > > > > promote
> > > > > > > > > > more committers working on Pulsar multilingual clients.
> It's
> > > > not
> > > > > a
> > > > > > > > reason
> > > > > > > > > > for emeritus or removal.
> > > > > > > > > >
> > > > > > > > > > ---
> > > > > > > > > >
> > > > > > > > > > Generally, committers and PMC members have "Earned
> Authority"
> > > > to
> > > > > be
> > > > > > > in
> > > > > > > > the
> > > > > > > > > > group. They share a high trust level, and I have numerous
> > > > > examples
> > > > > > > that
> > > > > > > > > > returned members do outstanding work. If we don't have
> some
> > > > > > critical
> > > > > > > > issues
> > > > > > > > > > to introduce an emeritus status, and such members do no
> harm,
> > > > why
> > > > > > do
> > > > > > > > we set
> > > > > > > > > > a bar if they return?
> > > > > > > > > >
> > > > > > > > > > Best,
> > > > > > > > > > tison.
> > > > > > > > > >
> > > > > > > > > > [1]
> > > > > https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Dave Fisher <wa...@apache.org> 于2023年3月3日周五 09:37写道：
> > > > > > > > > >
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > > On Mar 2, 2023, at 11:58 AM, Asaf Mesika <
> > > > > > asaf.mesika@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi,
> > > > > > > > > > > >
> > > > > > > > > > > > Following the discussion I've started in Pulsar
> bi-weekly
> > > > > > > meetings.
> > > > > > > > > > >
> > > > > > > > > > > As I said when you brought this up, I don’t think it
> is a
> > > > good
> > > > > > > idea,
> > > > > > > > not a
> > > > > > > > > > > good idea at all.
> > > > > > > > > > >
> > > > > > > > > > > > Projects can establish their own policy on handling
> > > > inactive
> > > > > > > > members, as
> > > > > > > > > > > > long as they apply it consistently.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > As a PMC member I have no desire to play a game of
> > > > consistently
> > > > > > > > tossing
> > > > > > > > > > > PMC members who somehow haven’t met an engagement
> criteria.
> > > > > That
> > > > > > is
> > > > > > > > an
> > > > > > > > > > > anti-pattern to building a community. It would be
> > > disruptive
> > > > > and
> > > > > > > time
> > > > > > > > > > > consuming.
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > = The idea
> > > > > > > > > > > > PMC and Committers members will transition into
> Emeritus
> > > > > status
> > > > > > > > after X
> > > > > > > > > > > > months of inactivity, or voluntarily.
> > > > > > > > > > >
> > > > > > > > > > > PMC members have the opportunity with or without this
> > > > proposal
> > > > > to
> > > > > > > > > > > voluntarily resign as PMC members with or without
> giving up
> > > > > their
> > > > > > > > commit
> > > > > > > > > > > bit.
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > = Why?
> > > > > > > > > > > > - Gain real visibility into the health of the
> project in
> > > > > terms
> > > > > > of
> > > > > > > > real
> > > > > > > > > > > > active PMC / Committers members.
> > > > > > > > > > >
> > > > > > > > > > > Here is an exercise. Generate activity reports to show
> > > > > criteria.
> > > > > > We
> > > > > > > > can
> > > > > > > > > > > correlate between the rosters and all of our GitHub
> > > > > repositories.
> > > > > > > > Also
> > > > > > > > > > > Mailing lists and slack which only goes back 90 days. I
> > > would
> > > > > be
> > > > > > > > better
> > > > > > > > > > > persuaded if you did that to actually show and prove
> that
> > > > there
> > > > > > is
> > > > > > > a
> > > > > > > > > > > problem. I think you will find that it is a large
> amount of
> > > > > > effort
> > > > > > > > with
> > > > > > > > > > > little value in the end.
> > > > > > > > > > >
> > > > > > > > > > > > - Have the alert threshold set correctly as to when
> it's
> > > > time
> > > > > > to
> > > > > > > > start
> > > > > > > > > > > > working on recruiting new PMC / Committers members.
> > > > > > > > > > >
> > > > > > > > > > > Those two points are not coupled. We ARE ALWAYS be on
> the
> > > > alert
> > > > > > for
> > > > > > > > new
> > > > > > > > > > > committers and PMC Members. This PMC has been ACTIVE in
> > > > > > recognizing
> > > > > > > > many of
> > > > > > > > > > > those who are deserving.
> > > > > > > > > > >
> > > > > > > > > > > Here are the Pulsar Board reports:
> > > > > > > > > > > https://whimsy.apache.org/board/minutes/Pulsar
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > = Is there any precedence?
> > > > > > > > > > > > Yes. A lot.
> > > > > > > > > > > > Many CNCF projects do it.
> > > > > > > > > > > > Many Apache projects do it.
> > > > > > > > > > >
> > > > > > > > > > > I’ve been on many PMC’s and I cannot think of one that
> does
> > > > > this.
> > > > > > > > You’ve
> > > > > > > > > > > come up with a few examples below, but I won’t be
> > > persuaded.
> > > > > > > > > > >
> > > > > > > > > > > > Apache foundations rules allow it.
> > > > > > > > > > > >
> > > > > > > > > > > > Read below to see examples and links.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > = Examples
> > > > > > > > > > > >
> > > > > > > > > > > > === etcD project <
> > > > > > > > > > >
> https://github.com/etcd-io/etcd/blob/main/GOVERNANCE.md>
> > > > > > > > > > >
> > > > > > > > > > > I don’t care about how another Foundation does it.
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Quote
> > > > > > > > > > > >
> > > > > > > > > > > > Life priorities, interests, and passions can change.
> > > > > > Maintainers
> > > > > > > > can
> > > > > > > > > > > retire
> > > > > > > > > > > > and move to the emeritus status
> > > > > > > > > > > > <
> > > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/etcd-io/etcd/blob/main/README.md#etcd-emeritus-maintainers
> > > > > > > > > > > >.
> > > > > > > > > > > > If a maintainer needs to step down, they should
> inform
> > > > other
> > > > > > > > maintainers,
> > > > > > > > > > > > if possible, help find someone to pick up the related
> > > work.
> > > > > At
> > > > > > > the
> > > > > > > > very
> > > > > > > > > > > > least, ensure the related work can be continued.
> > > Afterward
> > > > > they
> > > > > > > can
> > > > > > > > > > > remove
> > > > > > > > > > > > themselves from list of existing maintainers.
> > > > > > > > > > > >
> > > > > > > > > > > > If a maintainer is not been performing their duties
> for
> > > > > period
> > > > > > of
> > > > > > > > 12
> > > > > > > > > > > > months, they can be removed by other maintainers. In
> that
> > > > > case
> > > > > > > > inactive
> > > > > > > > > > > > maintainer will be first notified via an email. If
> > > > situation
> > > > > > > > doesn't
> > > > > > > > > > > > improve, they will be removed. If an emeritus
> maintainer
> > > > > wants
> > > > > > to
> > > > > > > > regain
> > > > > > > > > > > an
> > > > > > > > > > > > active role, they can do so by renewing their
> > > > contributions.
> > > > > > > Active
> > > > > > > > > > > > maintainers should welcome such a move. Retiring of
> other
> > > > > > > > maintainers or
> > > > > > > > > > > > regaining the status should require approval of at
> least
> > > > two
> > > > > > > active
> > > > > > > > > > > > maintainers.
> > > > > > > > > > > >
> > > > > > > > > > > > === Apache Gump
> > > > > > > > > > > > According to this link <
> > > > https://gump.apache.org/bylaws.html
> > > > > >,
> > > > > > > > they have
> > > > > > > > > > > > emeritus status for maintainers and PMC members and
> > > policy
> > > > to
> > > > > > > > transition.
> > > > > > > > > > >
> > > > > > > > > > > Gump is a tiny project that does not release code. The
> two
> > > > PMC
> > > > > > > > members was
> > > > > > > > > > > added in 2014. The rest were in 2004 - 2006. The
> project
> > > is a
> > > > > > build
> > > > > > > > system
> > > > > > > > > > > that other projects used to use. I don’t even know if
> any
> > > > > project
> > > > > > > > still
> > > > > > > > > > > uses it. In fact that are just keeping it up for
> Tomcat.
> > > See
> > > > > > > > > > > https://whimsy.apache.org/board/minutes/Gump
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > QUOTE
> > > > > > > > > > > > Committer access is by invitation only and must be
> > > approved
> > > > > by
> > > > > > > lazy
> > > > > > > > > > > > consensus of the active PMC members. A Committer is
> > > > > considered
> > > > > > > > emeritus
> > > > > > > > > > > by
> > > > > > > > > > > > their own declaration or by not contributing in any
> form
> > > to
> > > > > the
> > > > > > > > project
> > > > > > > > > > > for
> > > > > > > > > > > > over six months. An emeritus committer may request
> > > > > > reinstatement
> > > > > > > of
> > > > > > > > > > > commit
> > > > > > > > > > > > access from the PMC. Such reinstatement is subject to
> > > lazy
> > > > > > > > consensus of
> > > > > > > > > > > > active PMC members.
> > > > > > > > > > >
> > > > > > > > > > > All of their committers except for on of 16 are ASF
> > > Members.
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Membership of the PMC is by invitation only and must
> be
> > > > > > approved
> > > > > > > > by a
> > > > > > > > > > > lazy
> > > > > > > > > > > > consensus of active PMC members. A PMC member is
> > > considered
> > > > > > > > "emeritus" by
> > > > > > > > > > > > their own declaration or by not contributing in any
> form
> > > to
> > > > > the
> > > > > > > > project
> > > > > > > > > > > for
> > > > > > > > > > > > over six months. An emeritus member may request
> > > > reinstatement
> > > > > > to
> > > > > > > > the PMC.
> > > > > > > > > > > > Such reinstatement is subject to lazy consensus of
> the
> > > > active
> > > > > > PMC
> > > > > > > > > > > members.
> > > > > > > > > > > > Membership of the PMC can be revoked by an unanimous
> vote
> > > > of
> > > > > > all
> > > > > > > > the
> > > > > > > > > > > active
> > > > > > > > > > > > PMC members other than the member in question.
> > > > > > > > > > > >
> > > > > > > > > > > > END QUOTE
> > > > > > > > > > > >
> > > > > > > > > > > > There are many more: Apache Hive
> > > > > > > > > > > > <
> > > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Committers
> > > > > > > > > > > >,
> > > > > > > > > > >
> > > > > > > > > > > Hive has 56 PMC Members and 106 Committers. I can tell
> from
> > > > > their
> > > > > > > > roster
> > > > > > > > > > > that many do not seem to be engaged any more.
> > > > > > > > > > >
> > > > > > > > > > > Board reports:
> > > https://whimsy.apache.org/board/minutes/Hive
> > > > > > > > > > >
> > > > > > > > > > > > Apache Orc <
> > > > > > > > > > >
> > > > https://github.com/apache/orc/blob/main/site/develop/bylaws.md
> > > > > >,
> > > > > > > > > > >
> > > > > > > > > > > They are actively working to regrow, but I doubt they
> are
> > > > > kicking
> > > > > > > > out many
> > > > > > > > > > > PMC members. You could read their board reports:
> > > > > > > > > > > https://whimsy.apache.org/board/minutes/ORC
> > > > > > > > > > >
> > > > > > > > > > > > ...
> > > > > > > > > > > >
> > > > > > > > > > > > = What does Apache thinks about this?
> > > > > > > > > > > >
> > > > > > > > > > > > According to this link <
> > > > > > > > https://www.apache.org/dev/pmc.html#pmc-removal
> > > > > > > > > > > >,
> > > > > > > > > > > > any project can have their policies for retire an
> > > inactive
> > > > > PMC
> > > > > > > > member.
> > > > > > > > > > > >
> > > > > > > > > > > > QUOTE
> > > > > > > > > > > > SHOULD A PMC REMOVE INACTIVE MEMBERS?
> > > > > > > > > > > > <https://www.apache.org/dev/pmc.html#pmc-removal>
> > > > > > > > > > > >
> > > > > > > > > > > > Projects can establish their own policy on handling
> > > > inactive
> > > > > > > > members, as
> > > > > > > > > > > > long as they apply it 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
> > > > > > > > > > > > (without that member's request or consent), 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 an
> email
> > > > to
> > > > > > the
> > > > > > > > board@
> > > > > > > > > > > > mailing list detailing the request for removal and
> the
> > > > > > > > justification the
> > > > > > > > > > > > PMC has for that removal, and copy the project's
> private@
> > > > > > list.
> > > > > > > > > > > >
> > > > > > > > > > > > END QUOTE
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > = Summary
> > > > > > > > > > > > I believe that Apache Pulsar has the responsibility
> with
> > > > > > respect
> > > > > > > > to its
> > > > > > > > > > > > users to reflect the real number of people actively
> in
> > > the
> > > > > > > project
> > > > > > > > - its
> > > > > > > > > > > > PMC members.
> > > > > > > > > > >
> > > > > > > > > > > How would you do it consistently? How would you measure
> > > > > > > > disengagement?
> > > > > > > > > > >
> > > > > > > > > > > The only fair way would be to go through the exercise
> of
> > > > > > measuring
> > > > > > > > actual
> > > > > > > > > > > engagement. Once you do I think that you will
> understand
> > > why
> > > > it
> > > > > > is
> > > > > > > > not
> > > > > > > > > > > really done.
> > > > > > > > > > >
> > > > > > > > > > > Best,
> > > > > > > > > > > Dave
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
>

Re: [DISCUSS] PMC/Committer Emiratus status

[Enrico Olivelli <eo...@gmail.com>]

Il giorno lun 6 mar 2023 alle ore 23:12 Asaf Mesika
<as...@gmail.com> ha scritto:
>
> Tison,
>
> The suggestion was stated a bit differently:
>
> Quote:
>
> Rather, I would recommend a project-level “active/inactive” flag that PMC
> members can voluntarily apply to themselves. For example, do a PMC roll
> call on private@pulsar.a.o <ma...@pulsar.a.o> and ask whether
> current PMC members self describe as “active” or “inactive”. That status
> could then be reflected on the Community section of the pulsar website.

Websites tend to quickly become obsolete about this kind of thing,
because really
nobody takes care of its own "status" on a project, or that it is
"visible" on the website.
It is not for the benefit of anyone.

Also when you become "inactive" you are for sure not interested in
updating the website, because you slowly
lose interest in the project :-)

Everybody (should) participate as an individual, what's the benefit of
having you listed on the website ?

I really remember the first time I was invited as a committer in an
ASF, I felt really proud of myself,
and also seeing myself listed in the main pom.xml of the project or in
the list of committers was cool.
So this is great for new contributors or in order to praise the
efforts of someone who spent so much
time in the community in order to be asked to join the group of people
responsible for the project.

But after some time, when you participate in an OSS community, and you
really care about the project,
you don't care if you are listed here or there.

Regarding the "themes" on which someone could be "more expert" or not.
This is also a piece of information that becomes obsolete.
The community is dynamic, people who "knew" well something in the past
but maybe they are no more up-to-date now.

What's the goal ? To say Foo Bar is the "Pulsar Schema Registry expert" ?

Personally I won't feel good to say that I am "the" expert for X, Y,
Z, even if there are a few places in which I have spent
days of work and I made substantial contributions (or new features
initially contributed by myself).

If you want to reach out to someone expert on a piece of code you use
the GH UI and see the latest commits (of "git log")
or search into the mailing list archives or in the GH issues and you
will find the same names around a given topic.

For Pulsar this is the OFFICIAL page of the folks that are
"responsible" for the project
https://people.apache.org/phonebook.html?pmc=pulsar

If you really want to see who are the all the ASF committers you can
always go here
https://people.apache.org/committer-index.html

If we want to list the PMC members/committers I suggest building
something automated that simply shows the list.


Enrico





No > reply from a PMC member? Mark them inactive until they request a change.
>
> End Quote
>
>
> On Mon, Mar 6, 2023 at 6:13 PM tison <wa...@gmail.com> wrote:
>
> > I won't object if any PMC member or committer is willing to set their
> > personal status; e.g., open to topics of a specific domain, "inactive"
> > or "don't
> > disturb"
> >
> > Best,
> > tison.
> >
> >
> > Asaf Mesika <as...@gmail.com> 于2023年3月7日周二 00:05写道：
> >
> > > Do other think it's a good thing to adopt P. Taylor Goetz idea of active
> > > flag and the process suggested?
> > >
> > >
> > > On Mon, Mar 6, 2023 at 2:03 PM tison <wa...@gmail.com> wrote:
> > >
> > > > Hi Yu,
> > > >
> > > > You can start by adding a page on the contribution guide or a table in
> > > the
> > > > README of the main repo/site repo to state that you're an expert in the
> > > > document domain.
> > > >
> > > > I have an in-house landscape about Pulsar modules, the broader
> > ecosystem,
> > > > and their active contributors/maintainers. Since people may not want to
> > > be
> > > > referred to publicly by another person, I don't make it public.
> > > >
> > > > Finding experts can be a skill to collaborate in a community. You can
> > > find
> > > > them when browsing relative PRs, analyzing the commit history, meeting
> > > them
> > > > in the community, and having conversations. I don't have the motivation
> > > to
> > > > maintain such a table publicly.
> > > >
> > > > Scala has a table of domain experts that can help[1]. If you like it,
> > you
> > > > can list yourself and try to bring other experts to list themselves.
> > The
> > > > ASF shares a sense that "The Foundation belongs to *you*". You're
> > > already a
> > > > PMC member and able to drive such an effort.
> > > >
> > > > Best,
> > > > tison.
> > > >
> > > > [1] https://github.com/scala/scala#get-in-touch
> > > >
> > > >
> > > > Yu <li...@apache.org> 于2023年3月6日周一 19:48写道：
> > > >
> > > > > Hi Asaf,
> > > > >
> > > > > Thanks for bringing this up!
> > > > >
> > > > > If I may put my two pennies' worth:
> > > > >
> > > > > To be honest, this idea flashed across my mind previously. I talked
> > > about
> > > > > this to my colleague, and he was surprised that I was willing to be
> > > > > deprived of benefits (at that time, I was a PMC member already).
> > > > >
> > > > > PMC members are vital promotors and driving forces of a community.
> > > > Ideally,
> > > > > they should be direction leaders and make great contributions
> > > > > *continuously*. No one should enjoy the benefits of honor but not
> > > > > contribute much *all the time*. Setting retirement bars for PMC
> > members
> > > > > reminds us to contribute and provide value. Maybe I'm a little
> > > aggressive
> > > > > :-)
> > > > >
> > > > > ~~~~~~
> > > > >
> > > > > +1 but a long list of PMC members with many inactive members does not
> > > > > create a good feeling since "false prosperity" is no better than
> > "real
> > > > > contributions".
> > > > >
> > > > > > 3. Merit doesn’t expire.
> > > > >
> > > > > ~~~~~~
> > > > >
> > > > > Compared to my previous thought, Goetz has proposed a better idea
> > > since:
> > > > >
> > > > > 1. It's mild and can be accepted by many PMC members. A kind of life
> > > > wisdom
> > > > > :-)
> > > > >
> > > > > 2. People who need help (e.g., PIP approvals / PR comments / ...)
> > from
> > > > PMC
> > > > > members can check the flags to know who is available to help.
> > > > >
> > > > > Except for flags, I suggest adding "area of expertise" for PMC
> > members
> > > > and
> > > > > committers, so people will know who are the most suitable experts to
> > > ask
> > > > > for help or collaborate.
> > > > >
> > > > > > 1. You can maintain active/inactive status at the project level
> > with
> > > a
> > > > > simple flag on a community page, without removing people from the
> > PMC.
> > > > > > 2. By making it an informal, self-reported flag, you avoid the
> > > overhead
> > > > > of board resolutions, etc. and just manage it at the community level.
> > > If
> > > > > someone wants to change their status, they can just say so or submit
> > a
> > > > pull
> > > > > request to change their status on the pulsar website.
> > > > >
> > > > > ~~~~~~
> > > > >
> > > > > Yu
> > > > >
> > > > > On Sun, Mar 5, 2023 at 10:31 PM Asaf Mesika <as...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > Thanks to everyone who took the time to carefully answer with
> > > detailed
> > > > > > explanations.
> > > > > > I personally learned a lot about Apache projects this way (made me
> > > read
> > > > > > about it some more).
> > > > > >
> > > > > > So my personal recap is:
> > > > > >
> > > > > >    - The goal of knowing the health of the Apache Pulsar community
> > > can
> > > > be
> > > > > >    achieved by taking a look at monthly active contributors over
> > time
> > > > > >    displayed on the community page.
> > > > > >       - It could be nice getting those numbers on the mailing list
> > > > itself
> > > > > >       as well.
> > > > > >    - Calculating the engagement is not an easy task.
> > > > > >    - Kicking people off is not something you'd like to do in
> > general
> > > > and
> > > > > >    specifically for volunteers.
> > > > > >    - People's credit for work, which is also expressed in PMC
> > > > membership
> > > > > >    never expires due to Merit never expires - your work credit and
> > > > earned
> > > > > >    right should not expire.
> > > > > >
> > > > > >
> > > > > > I personally see PMC members answering someone not a PMC member
> > nor a
> > > > > > comitter on this topic as a very healthy community indicator :)
> > > > > >
> > > > > > Thanks !
> > > > > >
> > > > > > Asaf
> > > > > >
> > > > > > On Fri, Mar 3, 2023 at 10:22 AM Enrico Olivelli <
> > eolivelli@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > This is an interesting discussion.
> > > > > > > Good to see this kind of a discussion on the dev@ mailing list,
> > > this
> > > > > > > way more people are aware of the fact that we are a project in
> > the
> > > > ASF
> > > > > > > and there is a Project Management Committee.
> > > > > > >
> > > > > > > I have been following a few Apache projects for a while, and I
> > > > believe
> > > > > > > that this kind of discussions should be run on the private@
> > > mailing
> > > > > > > list.
> > > > > > > It is the PMC that usually deals with this stuff.
> > > > > > >
> > > > > > > As Tison said, the common practice is that you never remove
> > anyone
> > > > > > > from a PMC or from the Committers list.
> > > > > > >
> > > > > > > This happens only in rare cases where an individual behaves in
> > > such a
> > > > > > > way that the Project or the Foundation could be damaged,
> > > > > > > for instance if you speak on behalf of the project and you offend
> > > > > > > someone publicly.
> > > > > > >
> > > > > > > Inactive contributors/committers/PMC members do not do any harm
> > to
> > > a
> > > > > > > project.
> > > > > > >
> > > > > > > Some projects have some rules that you cannot participate in
> > > official
> > > > > > > VOTEs if you are not "active".
> > > > > > >
> > > > > > > If anyone has some problems with someone in the community, then
> > > they
> > > > > > > can reach out to private@pulsar.apache.org and the PMC will
> > listen
> > > > to
> > > > > > > the problem and take actions.
> > > > > > >
> > > > > > > my 2 cents
> > > > > > >
> > > > > > > Enrico
> > > > > > >
> > > > > > > Il giorno ven 3 mar 2023 alle ore 04:39 Yunze Xu
> > > > > > > <yz...@streamnative.io.invalid> ha scritto:
> > > > > > > >
> > > > > > > > As a PMC member, I don't like playing a game of determining who
> > > > > should
> > > > > > > > be removed from PMC as well.
> > > > > > > >
> > > > > > > > I hear a viewpoint that someone is only participating in the
> > > > > community
> > > > > > > > only to join a PMC so that he can benefit from it. After
> > > becoming a
> > > > > > > > PMC member, he is never active in the community. It might be
> > true
> > > > but
> > > > > > > > I think it's acceptable. Making such a rule won't prevent such
> > > > cases.
> > > > > > > > If he wants, he can make use of the rule and keep himself
> > > "active"
> > > > to
> > > > > > > > avoid being kicked out of the PMC. Though the active state is
> > > fake.
> > > > > > > >
> > > > > > > > I'm not against the way to remove (or something else that
> > sounds
> > > > > good)
> > > > > > > > a PMC member because none of these ways is perfect. However,
> > I'm
> > > > > > > > STRONGLY AGAINST changing a rule that has been applied for some
> > > > time
> > > > > > > > unless it can be proved the rule is very harmful to the
> > > community.
> > > > > > > > You mentioned https://www.apache.org/dev/pmc.html#pmc-removal.
> > > But
> > > > > > > > please don't ignore the first sentence:
> > > > > > > >
> > > > > > > > > Projects can establish their own policy on handling inactive
> > > > > members,
> > > > > > > as long as they apply it CONSISTENTLY.
> > > > > > > >
> > > > > > > > In addition, Dave and Tison both mentioned we have some boards
> > or
> > > > > > > > webpages to see how many people are active. We don't need to
> > > remove
> > > > > > > > some PMC members just for knowing who were still active
> > recently.
> > > > > > > >
> > > > > > > > BTW, I'm also curious about the motivation of this proposal.
> > I'm
> > > > > > > > wondering how do the inactive PMC members harm the community?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Yunze
> > > > > > > >
> > > > > > > > On Fri, Mar 3, 2023 at 10:14 AM tison <wa...@gmail.com>
> > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > In the proposal, it's unclear if you'd like to _mark_ the
> > > > inactive
> > > > > > > members
> > > > > > > > > in emeritus status or _remove_ them from the LDAP group.
> > > > > > > > >
> > > > > > > > > I saw a similar discussion in the Flink community, resulting
> > in
> > > > > > > "active"
> > > > > > > > > sentences in its Bylaws[1]. Here is some consensus there:
> > > > > > > > >
> > > > > > > > > 1. Merits never expire. There's no reason to _remove_ a
> > > committer
> > > > > or
> > > > > > > PMC
> > > > > > > > > member from the LDAP group because of inactive following the
> > > > Apache
> > > > > > > way. I
> > > > > > > > > remember numbered cases a member got removed because they
> > > _keep_
> > > > > > > harming
> > > > > > > > > the community.
> > > > > > > > > 2. Emeritus status is set for unblocking consensus. The Flink
> > > > > > community
> > > > > > > > > experienced some votes that could not get the required
> > > approvals
> > > > in
> > > > > > > time
> > > > > > > > > and thus tried to unblock consensus by setting some members
> > > with
> > > > > > > binding
> > > > > > > > > votes in emeritus status. Do we spot concrete issues that the
> > > > > Pulsar
> > > > > > > > > community cannot work well with current PMC members and
> > > > committers
> > > > > > > group?
> > > > > > > > > 3. Emeritus status is voluntary. I know that in other
> > > > foundations,
> > > > > it
> > > > > > > can
> > > > > > > > > be judged or eagerly applied, but in ASF, we share a
> > "Community
> > > > of
> > > > > > > Peers"
> > > > > > > > > sense that everyone is a volunteer. They won't be "fired"
> > > because
> > > > > of
> > > > > > > "low
> > > > > > > > > productivity".
> > > > > > > > >
> > > > > > > > > > Gain real visibility into the health of the project in
> > terms
> > > of
> > > > > > real
> > > > > > > > > active PMC / Committers members.
> > > > > > > > >
> > > > > > > > > On the community page, we already have a monthly active
> > > > contributor
> > > > > > > graph.
> > > > > > > > > It's an insight concept; I don't think we should _remove_
> > > members
> > > > > for
> > > > > > > such
> > > > > > > > > a reason.
> > > > > > > > >
> > > > > > > > > > Have the alert threshold set correctly as to when it's time
> > > to
> > > > > > start
> > > > > > > > > working on recruiting new PMC / Committers members
> > > > > > > > >
> > > > > > > > > Ditto. When working in the community, you will know what
> > > modules
> > > > or
> > > > > > > repos
> > > > > > > > > lack participants. For example, I remember someone proposing
> > to
> > > > > > promote
> > > > > > > > > more committers working on Pulsar multilingual clients. It's
> > > not
> > > > a
> > > > > > > reason
> > > > > > > > > for emeritus or removal.
> > > > > > > > >
> > > > > > > > > ---
> > > > > > > > >
> > > > > > > > > Generally, committers and PMC members have "Earned Authority"
> > > to
> > > > be
> > > > > > in
> > > > > > > the
> > > > > > > > > group. They share a high trust level, and I have numerous
> > > > examples
> > > > > > that
> > > > > > > > > returned members do outstanding work. If we don't have some
> > > > > critical
> > > > > > > issues
> > > > > > > > > to introduce an emeritus status, and such members do no harm,
> > > why
> > > > > do
> > > > > > > we set
> > > > > > > > > a bar if they return?
> > > > > > > > >
> > > > > > > > > Best,
> > > > > > > > > tison.
> > > > > > > > >
> > > > > > > > > [1]
> > > > https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Dave Fisher <wa...@apache.org> 于2023年3月3日周五 09:37写道：
> > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > > On Mar 2, 2023, at 11:58 AM, Asaf Mesika <
> > > > > asaf.mesika@gmail.com>
> > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > Following the discussion I've started in Pulsar bi-weekly
> > > > > > meetings.
> > > > > > > > > >
> > > > > > > > > > As I said when you brought this up, I don’t think it is a
> > > good
> > > > > > idea,
> > > > > > > not a
> > > > > > > > > > good idea at all.
> > > > > > > > > >
> > > > > > > > > > > Projects can establish their own policy on handling
> > > inactive
> > > > > > > members, as
> > > > > > > > > > > long as they apply it consistently.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > As a PMC member I have no desire to play a game of
> > > consistently
> > > > > > > tossing
> > > > > > > > > > PMC members who somehow haven’t met an engagement criteria.
> > > > That
> > > > > is
> > > > > > > an
> > > > > > > > > > anti-pattern to building a community. It would be
> > disruptive
> > > > and
> > > > > > time
> > > > > > > > > > consuming.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > = The idea
> > > > > > > > > > > PMC and Committers members will transition into Emeritus
> > > > status
> > > > > > > after X
> > > > > > > > > > > months of inactivity, or voluntarily.
> > > > > > > > > >
> > > > > > > > > > PMC members have the opportunity with or without this
> > > proposal
> > > > to
> > > > > > > > > > voluntarily resign as PMC members with or without giving up
> > > > their
> > > > > > > commit
> > > > > > > > > > bit.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > = Why?
> > > > > > > > > > > - Gain real visibility into the health of the project in
> > > > terms
> > > > > of
> > > > > > > real
> > > > > > > > > > > active PMC / Committers members.
> > > > > > > > > >
> > > > > > > > > > Here is an exercise. Generate activity reports to show
> > > > criteria.
> > > > > We
> > > > > > > can
> > > > > > > > > > correlate between the rosters and all of our GitHub
> > > > repositories.
> > > > > > > Also
> > > > > > > > > > Mailing lists and slack which only goes back 90 days. I
> > would
> > > > be
> > > > > > > better
> > > > > > > > > > persuaded if you did that to actually show and prove that
> > > there
> > > > > is
> > > > > > a
> > > > > > > > > > problem. I think you will find that it is a large amount of
> > > > > effort
> > > > > > > with
> > > > > > > > > > little value in the end.
> > > > > > > > > >
> > > > > > > > > > > - Have the alert threshold set correctly as to when it's
> > > time
> > > > > to
> > > > > > > start
> > > > > > > > > > > working on recruiting new PMC / Committers members.
> > > > > > > > > >
> > > > > > > > > > Those two points are not coupled. We ARE ALWAYS be on the
> > > alert
> > > > > for
> > > > > > > new
> > > > > > > > > > committers and PMC Members. This PMC has been ACTIVE in
> > > > > recognizing
> > > > > > > many of
> > > > > > > > > > those who are deserving.
> > > > > > > > > >
> > > > > > > > > > Here are the Pulsar Board reports:
> > > > > > > > > > https://whimsy.apache.org/board/minutes/Pulsar
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > = Is there any precedence?
> > > > > > > > > > > Yes. A lot.
> > > > > > > > > > > Many CNCF projects do it.
> > > > > > > > > > > Many Apache projects do it.
> > > > > > > > > >
> > > > > > > > > > I’ve been on many PMC’s and I cannot think of one that does
> > > > this.
> > > > > > > You’ve
> > > > > > > > > > come up with a few examples below, but I won’t be
> > persuaded.
> > > > > > > > > >
> > > > > > > > > > > Apache foundations rules allow it.
> > > > > > > > > > >
> > > > > > > > > > > Read below to see examples and links.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > = Examples
> > > > > > > > > > >
> > > > > > > > > > > === etcD project <
> > > > > > > > > > https://github.com/etcd-io/etcd/blob/main/GOVERNANCE.md>
> > > > > > > > > >
> > > > > > > > > > I don’t care about how another Foundation does it.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Quote
> > > > > > > > > > >
> > > > > > > > > > > Life priorities, interests, and passions can change.
> > > > > Maintainers
> > > > > > > can
> > > > > > > > > > retire
> > > > > > > > > > > and move to the emeritus status
> > > > > > > > > > > <
> > > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/etcd-io/etcd/blob/main/README.md#etcd-emeritus-maintainers
> > > > > > > > > > >.
> > > > > > > > > > > If a maintainer needs to step down, they should inform
> > > other
> > > > > > > maintainers,
> > > > > > > > > > > if possible, help find someone to pick up the related
> > work.
> > > > At
> > > > > > the
> > > > > > > very
> > > > > > > > > > > least, ensure the related work can be continued.
> > Afterward
> > > > they
> > > > > > can
> > > > > > > > > > remove
> > > > > > > > > > > themselves from list of existing maintainers.
> > > > > > > > > > >
> > > > > > > > > > > If a maintainer is not been performing their duties for
> > > > period
> > > > > of
> > > > > > > 12
> > > > > > > > > > > months, they can be removed by other maintainers. In that
> > > > case
> > > > > > > inactive
> > > > > > > > > > > maintainer will be first notified via an email. If
> > > situation
> > > > > > > doesn't
> > > > > > > > > > > improve, they will be removed. If an emeritus maintainer
> > > > wants
> > > > > to
> > > > > > > regain
> > > > > > > > > > an
> > > > > > > > > > > active role, they can do so by renewing their
> > > contributions.
> > > > > > Active
> > > > > > > > > > > maintainers should welcome such a move. Retiring of other
> > > > > > > maintainers or
> > > > > > > > > > > regaining the status should require approval of at least
> > > two
> > > > > > active
> > > > > > > > > > > maintainers.
> > > > > > > > > > >
> > > > > > > > > > > === Apache Gump
> > > > > > > > > > > According to this link <
> > > https://gump.apache.org/bylaws.html
> > > > >,
> > > > > > > they have
> > > > > > > > > > > emeritus status for maintainers and PMC members and
> > policy
> > > to
> > > > > > > transition.
> > > > > > > > > >
> > > > > > > > > > Gump is a tiny project that does not release code. The two
> > > PMC
> > > > > > > members was
> > > > > > > > > > added in 2014. The rest were in 2004 - 2006. The project
> > is a
> > > > > build
> > > > > > > system
> > > > > > > > > > that other projects used to use. I don’t even know if any
> > > > project
> > > > > > > still
> > > > > > > > > > uses it. In fact that are just keeping it up for Tomcat.
> > See
> > > > > > > > > > https://whimsy.apache.org/board/minutes/Gump
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > QUOTE
> > > > > > > > > > > Committer access is by invitation only and must be
> > approved
> > > > by
> > > > > > lazy
> > > > > > > > > > > consensus of the active PMC members. A Committer is
> > > > considered
> > > > > > > emeritus
> > > > > > > > > > by
> > > > > > > > > > > their own declaration or by not contributing in any form
> > to
> > > > the
> > > > > > > project
> > > > > > > > > > for
> > > > > > > > > > > over six months. An emeritus committer may request
> > > > > reinstatement
> > > > > > of
> > > > > > > > > > commit
> > > > > > > > > > > access from the PMC. Such reinstatement is subject to
> > lazy
> > > > > > > consensus of
> > > > > > > > > > > active PMC members.
> > > > > > > > > >
> > > > > > > > > > All of their committers except for on of 16 are ASF
> > Members.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Membership of the PMC is by invitation only and must be
> > > > > approved
> > > > > > > by a
> > > > > > > > > > lazy
> > > > > > > > > > > consensus of active PMC members. A PMC member is
> > considered
> > > > > > > "emeritus" by
> > > > > > > > > > > their own declaration or by not contributing in any form
> > to
> > > > the
> > > > > > > project
> > > > > > > > > > for
> > > > > > > > > > > over six months. An emeritus member may request
> > > reinstatement
> > > > > to
> > > > > > > the PMC.
> > > > > > > > > > > Such reinstatement is subject to lazy consensus of the
> > > active
> > > > > PMC
> > > > > > > > > > members.
> > > > > > > > > > > Membership of the PMC can be revoked by an unanimous vote
> > > of
> > > > > all
> > > > > > > the
> > > > > > > > > > active
> > > > > > > > > > > PMC members other than the member in question.
> > > > > > > > > > >
> > > > > > > > > > > END QUOTE
> > > > > > > > > > >
> > > > > > > > > > > There are many more: Apache Hive
> > > > > > > > > > > <
> > > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Committers
> > > > > > > > > > >,
> > > > > > > > > >
> > > > > > > > > > Hive has 56 PMC Members and 106 Committers. I can tell from
> > > > their
> > > > > > > roster
> > > > > > > > > > that many do not seem to be engaged any more.
> > > > > > > > > >
> > > > > > > > > > Board reports:
> > https://whimsy.apache.org/board/minutes/Hive
> > > > > > > > > >
> > > > > > > > > > > Apache Orc <
> > > > > > > > > >
> > > https://github.com/apache/orc/blob/main/site/develop/bylaws.md
> > > > >,
> > > > > > > > > >
> > > > > > > > > > They are actively working to regrow, but I doubt they are
> > > > kicking
> > > > > > > out many
> > > > > > > > > > PMC members. You could read their board reports:
> > > > > > > > > > https://whimsy.apache.org/board/minutes/ORC
> > > > > > > > > >
> > > > > > > > > > > ...
> > > > > > > > > > >
> > > > > > > > > > > = What does Apache thinks about this?
> > > > > > > > > > >
> > > > > > > > > > > According to this link <
> > > > > > > https://www.apache.org/dev/pmc.html#pmc-removal
> > > > > > > > > > >,
> > > > > > > > > > > any project can have their policies for retire an
> > inactive
> > > > PMC
> > > > > > > member.
> > > > > > > > > > >
> > > > > > > > > > > QUOTE
> > > > > > > > > > > SHOULD A PMC REMOVE INACTIVE MEMBERS?
> > > > > > > > > > > <https://www.apache.org/dev/pmc.html#pmc-removal>
> > > > > > > > > > >
> > > > > > > > > > > Projects can establish their own policy on handling
> > > inactive
> > > > > > > members, as
> > > > > > > > > > > long as they apply it 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
> > > > > > > > > > > (without that member's request or consent), 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 an email
> > > to
> > > > > the
> > > > > > > board@
> > > > > > > > > > > mailing list detailing the request for removal and the
> > > > > > > justification the
> > > > > > > > > > > PMC has for that removal, and copy the project's private@
> > > > > list.
> > > > > > > > > > >
> > > > > > > > > > > END QUOTE
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > = Summary
> > > > > > > > > > > I believe that Apache Pulsar has the responsibility with
> > > > > respect
> > > > > > > to its
> > > > > > > > > > > users to reflect the real number of people actively in
> > the
> > > > > > project
> > > > > > > - its
> > > > > > > > > > > PMC members.
> > > > > > > > > >
> > > > > > > > > > How would you do it consistently? How would you measure
> > > > > > > disengagement?
> > > > > > > > > >
> > > > > > > > > > The only fair way would be to go through the exercise of
> > > > > measuring
> > > > > > > actual
> > > > > > > > > > engagement. Once you do I think that you will understand
> > why
> > > it
> > > > > is
> > > > > > > not
> > > > > > > > > > really done.
> > > > > > > > > >
> > > > > > > > > > Best,
> > > > > > > > > > Dave
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >

Re: [DISCUSS] PMC/Committer Emiratus status

[Asaf Mesika <as...@gmail.com>]

Tison,

The suggestion was stated a bit differently:

Quote:

Rather, I would recommend a project-level “active/inactive” flag that PMC
members can voluntarily apply to themselves. For example, do a PMC roll
call on private@pulsar.a.o <ma...@pulsar.a.o> and ask whether
current PMC members self describe as “active” or “inactive”. That status
could then be reflected on the Community section of the pulsar website. No
reply from a PMC member? Mark them inactive until they request a change.

End Quote


On Mon, Mar 6, 2023 at 6:13 PM tison <wa...@gmail.com> wrote:

> I won't object if any PMC member or committer is willing to set their
> personal status; e.g., open to topics of a specific domain, "inactive"
> or "don't
> disturb"
>
> Best,
> tison.
>
>
> Asaf Mesika <as...@gmail.com> 于2023年3月7日周二 00:05写道：
>
> > Do other think it's a good thing to adopt P. Taylor Goetz idea of active
> > flag and the process suggested?
> >
> >
> > On Mon, Mar 6, 2023 at 2:03 PM tison <wa...@gmail.com> wrote:
> >
> > > Hi Yu,
> > >
> > > You can start by adding a page on the contribution guide or a table in
> > the
> > > README of the main repo/site repo to state that you're an expert in the
> > > document domain.
> > >
> > > I have an in-house landscape about Pulsar modules, the broader
> ecosystem,
> > > and their active contributors/maintainers. Since people may not want to
> > be
> > > referred to publicly by another person, I don't make it public.
> > >
> > > Finding experts can be a skill to collaborate in a community. You can
> > find
> > > them when browsing relative PRs, analyzing the commit history, meeting
> > them
> > > in the community, and having conversations. I don't have the motivation
> > to
> > > maintain such a table publicly.
> > >
> > > Scala has a table of domain experts that can help[1]. If you like it,
> you
> > > can list yourself and try to bring other experts to list themselves.
> The
> > > ASF shares a sense that "The Foundation belongs to *you*". You're
> > already a
> > > PMC member and able to drive such an effort.
> > >
> > > Best,
> > > tison.
> > >
> > > [1] https://github.com/scala/scala#get-in-touch
> > >
> > >
> > > Yu <li...@apache.org> 于2023年3月6日周一 19:48写道：
> > >
> > > > Hi Asaf,
> > > >
> > > > Thanks for bringing this up!
> > > >
> > > > If I may put my two pennies' worth:
> > > >
> > > > To be honest, this idea flashed across my mind previously. I talked
> > about
> > > > this to my colleague, and he was surprised that I was willing to be
> > > > deprived of benefits (at that time, I was a PMC member already).
> > > >
> > > > PMC members are vital promotors and driving forces of a community.
> > > Ideally,
> > > > they should be direction leaders and make great contributions
> > > > *continuously*. No one should enjoy the benefits of honor but not
> > > > contribute much *all the time*. Setting retirement bars for PMC
> members
> > > > reminds us to contribute and provide value. Maybe I'm a little
> > aggressive
> > > > :-)
> > > >
> > > > ~~~~~~
> > > >
> > > > +1 but a long list of PMC members with many inactive members does not
> > > > create a good feeling since "false prosperity" is no better than
> "real
> > > > contributions".
> > > >
> > > > > 3. Merit doesn’t expire.
> > > >
> > > > ~~~~~~
> > > >
> > > > Compared to my previous thought, Goetz has proposed a better idea
> > since:
> > > >
> > > > 1. It's mild and can be accepted by many PMC members. A kind of life
> > > wisdom
> > > > :-)
> > > >
> > > > 2. People who need help (e.g., PIP approvals / PR comments / ...)
> from
> > > PMC
> > > > members can check the flags to know who is available to help.
> > > >
> > > > Except for flags, I suggest adding "area of expertise" for PMC
> members
> > > and
> > > > committers, so people will know who are the most suitable experts to
> > ask
> > > > for help or collaborate.
> > > >
> > > > > 1. You can maintain active/inactive status at the project level
> with
> > a
> > > > simple flag on a community page, without removing people from the
> PMC.
> > > > > 2. By making it an informal, self-reported flag, you avoid the
> > overhead
> > > > of board resolutions, etc. and just manage it at the community level.
> > If
> > > > someone wants to change their status, they can just say so or submit
> a
> > > pull
> > > > request to change their status on the pulsar website.
> > > >
> > > > ~~~~~~
> > > >
> > > > Yu
> > > >
> > > > On Sun, Mar 5, 2023 at 10:31 PM Asaf Mesika <as...@gmail.com>
> > > wrote:
> > > >
> > > > > Thanks to everyone who took the time to carefully answer with
> > detailed
> > > > > explanations.
> > > > > I personally learned a lot about Apache projects this way (made me
> > read
> > > > > about it some more).
> > > > >
> > > > > So my personal recap is:
> > > > >
> > > > >    - The goal of knowing the health of the Apache Pulsar community
> > can
> > > be
> > > > >    achieved by taking a look at monthly active contributors over
> time
> > > > >    displayed on the community page.
> > > > >       - It could be nice getting those numbers on the mailing list
> > > itself
> > > > >       as well.
> > > > >    - Calculating the engagement is not an easy task.
> > > > >    - Kicking people off is not something you'd like to do in
> general
> > > and
> > > > >    specifically for volunteers.
> > > > >    - People's credit for work, which is also expressed in PMC
> > > membership
> > > > >    never expires due to Merit never expires - your work credit and
> > > earned
> > > > >    right should not expire.
> > > > >
> > > > >
> > > > > I personally see PMC members answering someone not a PMC member
> nor a
> > > > > comitter on this topic as a very healthy community indicator :)
> > > > >
> > > > > Thanks !
> > > > >
> > > > > Asaf
> > > > >
> > > > > On Fri, Mar 3, 2023 at 10:22 AM Enrico Olivelli <
> eolivelli@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > This is an interesting discussion.
> > > > > > Good to see this kind of a discussion on the dev@ mailing list,
> > this
> > > > > > way more people are aware of the fact that we are a project in
> the
> > > ASF
> > > > > > and there is a Project Management Committee.
> > > > > >
> > > > > > I have been following a few Apache projects for a while, and I
> > > believe
> > > > > > that this kind of discussions should be run on the private@
> > mailing
> > > > > > list.
> > > > > > It is the PMC that usually deals with this stuff.
> > > > > >
> > > > > > As Tison said, the common practice is that you never remove
> anyone
> > > > > > from a PMC or from the Committers list.
> > > > > >
> > > > > > This happens only in rare cases where an individual behaves in
> > such a
> > > > > > way that the Project or the Foundation could be damaged,
> > > > > > for instance if you speak on behalf of the project and you offend
> > > > > > someone publicly.
> > > > > >
> > > > > > Inactive contributors/committers/PMC members do not do any harm
> to
> > a
> > > > > > project.
> > > > > >
> > > > > > Some projects have some rules that you cannot participate in
> > official
> > > > > > VOTEs if you are not "active".
> > > > > >
> > > > > > If anyone has some problems with someone in the community, then
> > they
> > > > > > can reach out to private@pulsar.apache.org and the PMC will
> listen
> > > to
> > > > > > the problem and take actions.
> > > > > >
> > > > > > my 2 cents
> > > > > >
> > > > > > Enrico
> > > > > >
> > > > > > Il giorno ven 3 mar 2023 alle ore 04:39 Yunze Xu
> > > > > > <yz...@streamnative.io.invalid> ha scritto:
> > > > > > >
> > > > > > > As a PMC member, I don't like playing a game of determining who
> > > > should
> > > > > > > be removed from PMC as well.
> > > > > > >
> > > > > > > I hear a viewpoint that someone is only participating in the
> > > > community
> > > > > > > only to join a PMC so that he can benefit from it. After
> > becoming a
> > > > > > > PMC member, he is never active in the community. It might be
> true
> > > but
> > > > > > > I think it's acceptable. Making such a rule won't prevent such
> > > cases.
> > > > > > > If he wants, he can make use of the rule and keep himself
> > "active"
> > > to
> > > > > > > avoid being kicked out of the PMC. Though the active state is
> > fake.
> > > > > > >
> > > > > > > I'm not against the way to remove (or something else that
> sounds
> > > > good)
> > > > > > > a PMC member because none of these ways is perfect. However,
> I'm
> > > > > > > STRONGLY AGAINST changing a rule that has been applied for some
> > > time
> > > > > > > unless it can be proved the rule is very harmful to the
> > community.
> > > > > > > You mentioned https://www.apache.org/dev/pmc.html#pmc-removal.
> > But
> > > > > > > please don't ignore the first sentence:
> > > > > > >
> > > > > > > > Projects can establish their own policy on handling inactive
> > > > members,
> > > > > > as long as they apply it CONSISTENTLY.
> > > > > > >
> > > > > > > In addition, Dave and Tison both mentioned we have some boards
> or
> > > > > > > webpages to see how many people are active. We don't need to
> > remove
> > > > > > > some PMC members just for knowing who were still active
> recently.
> > > > > > >
> > > > > > > BTW, I'm also curious about the motivation of this proposal.
> I'm
> > > > > > > wondering how do the inactive PMC members harm the community?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Yunze
> > > > > > >
> > > > > > > On Fri, Mar 3, 2023 at 10:14 AM tison <wa...@gmail.com>
> > > wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > In the proposal, it's unclear if you'd like to _mark_ the
> > > inactive
> > > > > > members
> > > > > > > > in emeritus status or _remove_ them from the LDAP group.
> > > > > > > >
> > > > > > > > I saw a similar discussion in the Flink community, resulting
> in
> > > > > > "active"
> > > > > > > > sentences in its Bylaws[1]. Here is some consensus there:
> > > > > > > >
> > > > > > > > 1. Merits never expire. There's no reason to _remove_ a
> > committer
> > > > or
> > > > > > PMC
> > > > > > > > member from the LDAP group because of inactive following the
> > > Apache
> > > > > > way. I
> > > > > > > > remember numbered cases a member got removed because they
> > _keep_
> > > > > > harming
> > > > > > > > the community.
> > > > > > > > 2. Emeritus status is set for unblocking consensus. The Flink
> > > > > community
> > > > > > > > experienced some votes that could not get the required
> > approvals
> > > in
> > > > > > time
> > > > > > > > and thus tried to unblock consensus by setting some members
> > with
> > > > > > binding
> > > > > > > > votes in emeritus status. Do we spot concrete issues that the
> > > > Pulsar
> > > > > > > > community cannot work well with current PMC members and
> > > committers
> > > > > > group?
> > > > > > > > 3. Emeritus status is voluntary. I know that in other
> > > foundations,
> > > > it
> > > > > > can
> > > > > > > > be judged or eagerly applied, but in ASF, we share a
> "Community
> > > of
> > > > > > Peers"
> > > > > > > > sense that everyone is a volunteer. They won't be "fired"
> > because
> > > > of
> > > > > > "low
> > > > > > > > productivity".
> > > > > > > >
> > > > > > > > > Gain real visibility into the health of the project in
> terms
> > of
> > > > > real
> > > > > > > > active PMC / Committers members.
> > > > > > > >
> > > > > > > > On the community page, we already have a monthly active
> > > contributor
> > > > > > graph.
> > > > > > > > It's an insight concept; I don't think we should _remove_
> > members
> > > > for
> > > > > > such
> > > > > > > > a reason.
> > > > > > > >
> > > > > > > > > Have the alert threshold set correctly as to when it's time
> > to
> > > > > start
> > > > > > > > working on recruiting new PMC / Committers members
> > > > > > > >
> > > > > > > > Ditto. When working in the community, you will know what
> > modules
> > > or
> > > > > > repos
> > > > > > > > lack participants. For example, I remember someone proposing
> to
> > > > > promote
> > > > > > > > more committers working on Pulsar multilingual clients. It's
> > not
> > > a
> > > > > > reason
> > > > > > > > for emeritus or removal.
> > > > > > > >
> > > > > > > > ---
> > > > > > > >
> > > > > > > > Generally, committers and PMC members have "Earned Authority"
> > to
> > > be
> > > > > in
> > > > > > the
> > > > > > > > group. They share a high trust level, and I have numerous
> > > examples
> > > > > that
> > > > > > > > returned members do outstanding work. If we don't have some
> > > > critical
> > > > > > issues
> > > > > > > > to introduce an emeritus status, and such members do no harm,
> > why
> > > > do
> > > > > > we set
> > > > > > > > a bar if they return?
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > tison.
> > > > > > > >
> > > > > > > > [1]
> > > https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws
> > > > > > > >
> > > > > > > >
> > > > > > > > Dave Fisher <wa...@apache.org> 于2023年3月3日周五 09:37写道：
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > > On Mar 2, 2023, at 11:58 AM, Asaf Mesika <
> > > > asaf.mesika@gmail.com>
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > Following the discussion I've started in Pulsar bi-weekly
> > > > > meetings.
> > > > > > > > >
> > > > > > > > > As I said when you brought this up, I don’t think it is a
> > good
> > > > > idea,
> > > > > > not a
> > > > > > > > > good idea at all.
> > > > > > > > >
> > > > > > > > > > Projects can establish their own policy on handling
> > inactive
> > > > > > members, as
> > > > > > > > > > long as they apply it consistently.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > As a PMC member I have no desire to play a game of
> > consistently
> > > > > > tossing
> > > > > > > > > PMC members who somehow haven’t met an engagement criteria.
> > > That
> > > > is
> > > > > > an
> > > > > > > > > anti-pattern to building a community. It would be
> disruptive
> > > and
> > > > > time
> > > > > > > > > consuming.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > = The idea
> > > > > > > > > > PMC and Committers members will transition into Emeritus
> > > status
> > > > > > after X
> > > > > > > > > > months of inactivity, or voluntarily.
> > > > > > > > >
> > > > > > > > > PMC members have the opportunity with or without this
> > proposal
> > > to
> > > > > > > > > voluntarily resign as PMC members with or without giving up
> > > their
> > > > > > commit
> > > > > > > > > bit.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > = Why?
> > > > > > > > > > - Gain real visibility into the health of the project in
> > > terms
> > > > of
> > > > > > real
> > > > > > > > > > active PMC / Committers members.
> > > > > > > > >
> > > > > > > > > Here is an exercise. Generate activity reports to show
> > > criteria.
> > > > We
> > > > > > can
> > > > > > > > > correlate between the rosters and all of our GitHub
> > > repositories.
> > > > > > Also
> > > > > > > > > Mailing lists and slack which only goes back 90 days. I
> would
> > > be
> > > > > > better
> > > > > > > > > persuaded if you did that to actually show and prove that
> > there
> > > > is
> > > > > a
> > > > > > > > > problem. I think you will find that it is a large amount of
> > > > effort
> > > > > > with
> > > > > > > > > little value in the end.
> > > > > > > > >
> > > > > > > > > > - Have the alert threshold set correctly as to when it's
> > time
> > > > to
> > > > > > start
> > > > > > > > > > working on recruiting new PMC / Committers members.
> > > > > > > > >
> > > > > > > > > Those two points are not coupled. We ARE ALWAYS be on the
> > alert
> > > > for
> > > > > > new
> > > > > > > > > committers and PMC Members. This PMC has been ACTIVE in
> > > > recognizing
> > > > > > many of
> > > > > > > > > those who are deserving.
> > > > > > > > >
> > > > > > > > > Here are the Pulsar Board reports:
> > > > > > > > > https://whimsy.apache.org/board/minutes/Pulsar
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > = Is there any precedence?
> > > > > > > > > > Yes. A lot.
> > > > > > > > > > Many CNCF projects do it.
> > > > > > > > > > Many Apache projects do it.
> > > > > > > > >
> > > > > > > > > I’ve been on many PMC’s and I cannot think of one that does
> > > this.
> > > > > > You’ve
> > > > > > > > > come up with a few examples below, but I won’t be
> persuaded.
> > > > > > > > >
> > > > > > > > > > Apache foundations rules allow it.
> > > > > > > > > >
> > > > > > > > > > Read below to see examples and links.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > = Examples
> > > > > > > > > >
> > > > > > > > > > === etcD project <
> > > > > > > > > https://github.com/etcd-io/etcd/blob/main/GOVERNANCE.md>
> > > > > > > > >
> > > > > > > > > I don’t care about how another Foundation does it.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Quote
> > > > > > > > > >
> > > > > > > > > > Life priorities, interests, and passions can change.
> > > > Maintainers
> > > > > > can
> > > > > > > > > retire
> > > > > > > > > > and move to the emeritus status
> > > > > > > > > > <
> > > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/etcd-io/etcd/blob/main/README.md#etcd-emeritus-maintainers
> > > > > > > > > >.
> > > > > > > > > > If a maintainer needs to step down, they should inform
> > other
> > > > > > maintainers,
> > > > > > > > > > if possible, help find someone to pick up the related
> work.
> > > At
> > > > > the
> > > > > > very
> > > > > > > > > > least, ensure the related work can be continued.
> Afterward
> > > they
> > > > > can
> > > > > > > > > remove
> > > > > > > > > > themselves from list of existing maintainers.
> > > > > > > > > >
> > > > > > > > > > If a maintainer is not been performing their duties for
> > > period
> > > > of
> > > > > > 12
> > > > > > > > > > months, they can be removed by other maintainers. In that
> > > case
> > > > > > inactive
> > > > > > > > > > maintainer will be first notified via an email. If
> > situation
> > > > > > doesn't
> > > > > > > > > > improve, they will be removed. If an emeritus maintainer
> > > wants
> > > > to
> > > > > > regain
> > > > > > > > > an
> > > > > > > > > > active role, they can do so by renewing their
> > contributions.
> > > > > Active
> > > > > > > > > > maintainers should welcome such a move. Retiring of other
> > > > > > maintainers or
> > > > > > > > > > regaining the status should require approval of at least
> > two
> > > > > active
> > > > > > > > > > maintainers.
> > > > > > > > > >
> > > > > > > > > > === Apache Gump
> > > > > > > > > > According to this link <
> > https://gump.apache.org/bylaws.html
> > > >,
> > > > > > they have
> > > > > > > > > > emeritus status for maintainers and PMC members and
> policy
> > to
> > > > > > transition.
> > > > > > > > >
> > > > > > > > > Gump is a tiny project that does not release code. The two
> > PMC
> > > > > > members was
> > > > > > > > > added in 2014. The rest were in 2004 - 2006. The project
> is a
> > > > build
> > > > > > system
> > > > > > > > > that other projects used to use. I don’t even know if any
> > > project
> > > > > > still
> > > > > > > > > uses it. In fact that are just keeping it up for Tomcat.
> See
> > > > > > > > > https://whimsy.apache.org/board/minutes/Gump
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > QUOTE
> > > > > > > > > > Committer access is by invitation only and must be
> approved
> > > by
> > > > > lazy
> > > > > > > > > > consensus of the active PMC members. A Committer is
> > > considered
> > > > > > emeritus
> > > > > > > > > by
> > > > > > > > > > their own declaration or by not contributing in any form
> to
> > > the
> > > > > > project
> > > > > > > > > for
> > > > > > > > > > over six months. An emeritus committer may request
> > > > reinstatement
> > > > > of
> > > > > > > > > commit
> > > > > > > > > > access from the PMC. Such reinstatement is subject to
> lazy
> > > > > > consensus of
> > > > > > > > > > active PMC members.
> > > > > > > > >
> > > > > > > > > All of their committers except for on of 16 are ASF
> Members.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Membership of the PMC is by invitation only and must be
> > > > approved
> > > > > > by a
> > > > > > > > > lazy
> > > > > > > > > > consensus of active PMC members. A PMC member is
> considered
> > > > > > "emeritus" by
> > > > > > > > > > their own declaration or by not contributing in any form
> to
> > > the
> > > > > > project
> > > > > > > > > for
> > > > > > > > > > over six months. An emeritus member may request
> > reinstatement
> > > > to
> > > > > > the PMC.
> > > > > > > > > > Such reinstatement is subject to lazy consensus of the
> > active
> > > > PMC
> > > > > > > > > members.
> > > > > > > > > > Membership of the PMC can be revoked by an unanimous vote
> > of
> > > > all
> > > > > > the
> > > > > > > > > active
> > > > > > > > > > PMC members other than the member in question.
> > > > > > > > > >
> > > > > > > > > > END QUOTE
> > > > > > > > > >
> > > > > > > > > > There are many more: Apache Hive
> > > > > > > > > > <
> > > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Committers
> > > > > > > > > >,
> > > > > > > > >
> > > > > > > > > Hive has 56 PMC Members and 106 Committers. I can tell from
> > > their
> > > > > > roster
> > > > > > > > > that many do not seem to be engaged any more.
> > > > > > > > >
> > > > > > > > > Board reports:
> https://whimsy.apache.org/board/minutes/Hive
> > > > > > > > >
> > > > > > > > > > Apache Orc <
> > > > > > > > >
> > https://github.com/apache/orc/blob/main/site/develop/bylaws.md
> > > >,
> > > > > > > > >
> > > > > > > > > They are actively working to regrow, but I doubt they are
> > > kicking
> > > > > > out many
> > > > > > > > > PMC members. You could read their board reports:
> > > > > > > > > https://whimsy.apache.org/board/minutes/ORC
> > > > > > > > >
> > > > > > > > > > ...
> > > > > > > > > >
> > > > > > > > > > = What does Apache thinks about this?
> > > > > > > > > >
> > > > > > > > > > According to this link <
> > > > > > https://www.apache.org/dev/pmc.html#pmc-removal
> > > > > > > > > >,
> > > > > > > > > > any project can have their policies for retire an
> inactive
> > > PMC
> > > > > > member.
> > > > > > > > > >
> > > > > > > > > > QUOTE
> > > > > > > > > > SHOULD A PMC REMOVE INACTIVE MEMBERS?
> > > > > > > > > > <https://www.apache.org/dev/pmc.html#pmc-removal>
> > > > > > > > > >
> > > > > > > > > > Projects can establish their own policy on handling
> > inactive
> > > > > > members, as
> > > > > > > > > > long as they apply it 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
> > > > > > > > > > (without that member's request or consent), 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 an email
> > to
> > > > the
> > > > > > board@
> > > > > > > > > > mailing list detailing the request for removal and the
> > > > > > justification the
> > > > > > > > > > PMC has for that removal, and copy the project's private@
> > > > list.
> > > > > > > > > >
> > > > > > > > > > END QUOTE
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > = Summary
> > > > > > > > > > I believe that Apache Pulsar has the responsibility with
> > > > respect
> > > > > > to its
> > > > > > > > > > users to reflect the real number of people actively in
> the
> > > > > project
> > > > > > - its
> > > > > > > > > > PMC members.
> > > > > > > > >
> > > > > > > > > How would you do it consistently? How would you measure
> > > > > > disengagement?
> > > > > > > > >
> > > > > > > > > The only fair way would be to go through the exercise of
> > > > measuring
> > > > > > actual
> > > > > > > > > engagement. Once you do I think that you will understand
> why
> > it
> > > > is
> > > > > > not
> > > > > > > > > really done.
> > > > > > > > >
> > > > > > > > > Best,
> > > > > > > > > Dave
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] PMC/Committer Emiratus status

[tison <wa...@gmail.com>]

I won't object if any PMC member or committer is willing to set their
personal status; e.g., open to topics of a specific domain, "inactive"
or "don't
disturb"

Best,
tison.


Asaf Mesika <as...@gmail.com> 于2023年3月7日周二 00:05写道：

> Do other think it's a good thing to adopt P. Taylor Goetz idea of active
> flag and the process suggested?
>
>
> On Mon, Mar 6, 2023 at 2:03 PM tison <wa...@gmail.com> wrote:
>
> > Hi Yu,
> >
> > You can start by adding a page on the contribution guide or a table in
> the
> > README of the main repo/site repo to state that you're an expert in the
> > document domain.
> >
> > I have an in-house landscape about Pulsar modules, the broader ecosystem,
> > and their active contributors/maintainers. Since people may not want to
> be
> > referred to publicly by another person, I don't make it public.
> >
> > Finding experts can be a skill to collaborate in a community. You can
> find
> > them when browsing relative PRs, analyzing the commit history, meeting
> them
> > in the community, and having conversations. I don't have the motivation
> to
> > maintain such a table publicly.
> >
> > Scala has a table of domain experts that can help[1]. If you like it, you
> > can list yourself and try to bring other experts to list themselves. The
> > ASF shares a sense that "The Foundation belongs to *you*". You're
> already a
> > PMC member and able to drive such an effort.
> >
> > Best,
> > tison.
> >
> > [1] https://github.com/scala/scala#get-in-touch
> >
> >
> > Yu <li...@apache.org> 于2023年3月6日周一 19:48写道：
> >
> > > Hi Asaf,
> > >
> > > Thanks for bringing this up!
> > >
> > > If I may put my two pennies' worth:
> > >
> > > To be honest, this idea flashed across my mind previously. I talked
> about
> > > this to my colleague, and he was surprised that I was willing to be
> > > deprived of benefits (at that time, I was a PMC member already).
> > >
> > > PMC members are vital promotors and driving forces of a community.
> > Ideally,
> > > they should be direction leaders and make great contributions
> > > *continuously*. No one should enjoy the benefits of honor but not
> > > contribute much *all the time*. Setting retirement bars for PMC members
> > > reminds us to contribute and provide value. Maybe I'm a little
> aggressive
> > > :-)
> > >
> > > ~~~~~~
> > >
> > > +1 but a long list of PMC members with many inactive members does not
> > > create a good feeling since "false prosperity" is no better than "real
> > > contributions".
> > >
> > > > 3. Merit doesn’t expire.
> > >
> > > ~~~~~~
> > >
> > > Compared to my previous thought, Goetz has proposed a better idea
> since:
> > >
> > > 1. It's mild and can be accepted by many PMC members. A kind of life
> > wisdom
> > > :-)
> > >
> > > 2. People who need help (e.g., PIP approvals / PR comments / ...) from
> > PMC
> > > members can check the flags to know who is available to help.
> > >
> > > Except for flags, I suggest adding "area of expertise" for PMC members
> > and
> > > committers, so people will know who are the most suitable experts to
> ask
> > > for help or collaborate.
> > >
> > > > 1. You can maintain active/inactive status at the project level with
> a
> > > simple flag on a community page, without removing people from the PMC.
> > > > 2. By making it an informal, self-reported flag, you avoid the
> overhead
> > > of board resolutions, etc. and just manage it at the community level.
> If
> > > someone wants to change their status, they can just say so or submit a
> > pull
> > > request to change their status on the pulsar website.
> > >
> > > ~~~~~~
> > >
> > > Yu
> > >
> > > On Sun, Mar 5, 2023 at 10:31 PM Asaf Mesika <as...@gmail.com>
> > wrote:
> > >
> > > > Thanks to everyone who took the time to carefully answer with
> detailed
> > > > explanations.
> > > > I personally learned a lot about Apache projects this way (made me
> read
> > > > about it some more).
> > > >
> > > > So my personal recap is:
> > > >
> > > >    - The goal of knowing the health of the Apache Pulsar community
> can
> > be
> > > >    achieved by taking a look at monthly active contributors over time
> > > >    displayed on the community page.
> > > >       - It could be nice getting those numbers on the mailing list
> > itself
> > > >       as well.
> > > >    - Calculating the engagement is not an easy task.
> > > >    - Kicking people off is not something you'd like to do in general
> > and
> > > >    specifically for volunteers.
> > > >    - People's credit for work, which is also expressed in PMC
> > membership
> > > >    never expires due to Merit never expires - your work credit and
> > earned
> > > >    right should not expire.
> > > >
> > > >
> > > > I personally see PMC members answering someone not a PMC member nor a
> > > > comitter on this topic as a very healthy community indicator :)
> > > >
> > > > Thanks !
> > > >
> > > > Asaf
> > > >
> > > > On Fri, Mar 3, 2023 at 10:22 AM Enrico Olivelli <eolivelli@gmail.com
> >
> > > > wrote:
> > > >
> > > > > This is an interesting discussion.
> > > > > Good to see this kind of a discussion on the dev@ mailing list,
> this
> > > > > way more people are aware of the fact that we are a project in the
> > ASF
> > > > > and there is a Project Management Committee.
> > > > >
> > > > > I have been following a few Apache projects for a while, and I
> > believe
> > > > > that this kind of discussions should be run on the private@
> mailing
> > > > > list.
> > > > > It is the PMC that usually deals with this stuff.
> > > > >
> > > > > As Tison said, the common practice is that you never remove anyone
> > > > > from a PMC or from the Committers list.
> > > > >
> > > > > This happens only in rare cases where an individual behaves in
> such a
> > > > > way that the Project or the Foundation could be damaged,
> > > > > for instance if you speak on behalf of the project and you offend
> > > > > someone publicly.
> > > > >
> > > > > Inactive contributors/committers/PMC members do not do any harm to
> a
> > > > > project.
> > > > >
> > > > > Some projects have some rules that you cannot participate in
> official
> > > > > VOTEs if you are not "active".
> > > > >
> > > > > If anyone has some problems with someone in the community, then
> they
> > > > > can reach out to private@pulsar.apache.org and the PMC will listen
> > to
> > > > > the problem and take actions.
> > > > >
> > > > > my 2 cents
> > > > >
> > > > > Enrico
> > > > >
> > > > > Il giorno ven 3 mar 2023 alle ore 04:39 Yunze Xu
> > > > > <yz...@streamnative.io.invalid> ha scritto:
> > > > > >
> > > > > > As a PMC member, I don't like playing a game of determining who
> > > should
> > > > > > be removed from PMC as well.
> > > > > >
> > > > > > I hear a viewpoint that someone is only participating in the
> > > community
> > > > > > only to join a PMC so that he can benefit from it. After
> becoming a
> > > > > > PMC member, he is never active in the community. It might be true
> > but
> > > > > > I think it's acceptable. Making such a rule won't prevent such
> > cases.
> > > > > > If he wants, he can make use of the rule and keep himself
> "active"
> > to
> > > > > > avoid being kicked out of the PMC. Though the active state is
> fake.
> > > > > >
> > > > > > I'm not against the way to remove (or something else that sounds
> > > good)
> > > > > > a PMC member because none of these ways is perfect. However, I'm
> > > > > > STRONGLY AGAINST changing a rule that has been applied for some
> > time
> > > > > > unless it can be proved the rule is very harmful to the
> community.
> > > > > > You mentioned https://www.apache.org/dev/pmc.html#pmc-removal.
> But
> > > > > > please don't ignore the first sentence:
> > > > > >
> > > > > > > Projects can establish their own policy on handling inactive
> > > members,
> > > > > as long as they apply it CONSISTENTLY.
> > > > > >
> > > > > > In addition, Dave and Tison both mentioned we have some boards or
> > > > > > webpages to see how many people are active. We don't need to
> remove
> > > > > > some PMC members just for knowing who were still active recently.
> > > > > >
> > > > > > BTW, I'm also curious about the motivation of this proposal. I'm
> > > > > > wondering how do the inactive PMC members harm the community?
> > > > > >
> > > > > > Thanks,
> > > > > > Yunze
> > > > > >
> > > > > > On Fri, Mar 3, 2023 at 10:14 AM tison <wa...@gmail.com>
> > wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > In the proposal, it's unclear if you'd like to _mark_ the
> > inactive
> > > > > members
> > > > > > > in emeritus status or _remove_ them from the LDAP group.
> > > > > > >
> > > > > > > I saw a similar discussion in the Flink community, resulting in
> > > > > "active"
> > > > > > > sentences in its Bylaws[1]. Here is some consensus there:
> > > > > > >
> > > > > > > 1. Merits never expire. There's no reason to _remove_ a
> committer
> > > or
> > > > > PMC
> > > > > > > member from the LDAP group because of inactive following the
> > Apache
> > > > > way. I
> > > > > > > remember numbered cases a member got removed because they
> _keep_
> > > > > harming
> > > > > > > the community.
> > > > > > > 2. Emeritus status is set for unblocking consensus. The Flink
> > > > community
> > > > > > > experienced some votes that could not get the required
> approvals
> > in
> > > > > time
> > > > > > > and thus tried to unblock consensus by setting some members
> with
> > > > > binding
> > > > > > > votes in emeritus status. Do we spot concrete issues that the
> > > Pulsar
> > > > > > > community cannot work well with current PMC members and
> > committers
> > > > > group?
> > > > > > > 3. Emeritus status is voluntary. I know that in other
> > foundations,
> > > it
> > > > > can
> > > > > > > be judged or eagerly applied, but in ASF, we share a "Community
> > of
> > > > > Peers"
> > > > > > > sense that everyone is a volunteer. They won't be "fired"
> because
> > > of
> > > > > "low
> > > > > > > productivity".
> > > > > > >
> > > > > > > > Gain real visibility into the health of the project in terms
> of
> > > > real
> > > > > > > active PMC / Committers members.
> > > > > > >
> > > > > > > On the community page, we already have a monthly active
> > contributor
> > > > > graph.
> > > > > > > It's an insight concept; I don't think we should _remove_
> members
> > > for
> > > > > such
> > > > > > > a reason.
> > > > > > >
> > > > > > > > Have the alert threshold set correctly as to when it's time
> to
> > > > start
> > > > > > > working on recruiting new PMC / Committers members
> > > > > > >
> > > > > > > Ditto. When working in the community, you will know what
> modules
> > or
> > > > > repos
> > > > > > > lack participants. For example, I remember someone proposing to
> > > > promote
> > > > > > > more committers working on Pulsar multilingual clients. It's
> not
> > a
> > > > > reason
> > > > > > > for emeritus or removal.
> > > > > > >
> > > > > > > ---
> > > > > > >
> > > > > > > Generally, committers and PMC members have "Earned Authority"
> to
> > be
> > > > in
> > > > > the
> > > > > > > group. They share a high trust level, and I have numerous
> > examples
> > > > that
> > > > > > > returned members do outstanding work. If we don't have some
> > > critical
> > > > > issues
> > > > > > > to introduce an emeritus status, and such members do no harm,
> why
> > > do
> > > > > we set
> > > > > > > a bar if they return?
> > > > > > >
> > > > > > > Best,
> > > > > > > tison.
> > > > > > >
> > > > > > > [1]
> > https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws
> > > > > > >
> > > > > > >
> > > > > > > Dave Fisher <wa...@apache.org> 于2023年3月3日周五 09:37写道：
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > > On Mar 2, 2023, at 11:58 AM, Asaf Mesika <
> > > asaf.mesika@gmail.com>
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > Following the discussion I've started in Pulsar bi-weekly
> > > > meetings.
> > > > > > > >
> > > > > > > > As I said when you brought this up, I don’t think it is a
> good
> > > > idea,
> > > > > not a
> > > > > > > > good idea at all.
> > > > > > > >
> > > > > > > > > Projects can establish their own policy on handling
> inactive
> > > > > members, as
> > > > > > > > > long as they apply it consistently.
> > > > > > > >
> > > > > > > >
> > > > > > > > As a PMC member I have no desire to play a game of
> consistently
> > > > > tossing
> > > > > > > > PMC members who somehow haven’t met an engagement criteria.
> > That
> > > is
> > > > > an
> > > > > > > > anti-pattern to building a community. It would be disruptive
> > and
> > > > time
> > > > > > > > consuming.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > = The idea
> > > > > > > > > PMC and Committers members will transition into Emeritus
> > status
> > > > > after X
> > > > > > > > > months of inactivity, or voluntarily.
> > > > > > > >
> > > > > > > > PMC members have the opportunity with or without this
> proposal
> > to
> > > > > > > > voluntarily resign as PMC members with or without giving up
> > their
> > > > > commit
> > > > > > > > bit.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > = Why?
> > > > > > > > > - Gain real visibility into the health of the project in
> > terms
> > > of
> > > > > real
> > > > > > > > > active PMC / Committers members.
> > > > > > > >
> > > > > > > > Here is an exercise. Generate activity reports to show
> > criteria.
> > > We
> > > > > can
> > > > > > > > correlate between the rosters and all of our GitHub
> > repositories.
> > > > > Also
> > > > > > > > Mailing lists and slack which only goes back 90 days. I would
> > be
> > > > > better
> > > > > > > > persuaded if you did that to actually show and prove that
> there
> > > is
> > > > a
> > > > > > > > problem. I think you will find that it is a large amount of
> > > effort
> > > > > with
> > > > > > > > little value in the end.
> > > > > > > >
> > > > > > > > > - Have the alert threshold set correctly as to when it's
> time
> > > to
> > > > > start
> > > > > > > > > working on recruiting new PMC / Committers members.
> > > > > > > >
> > > > > > > > Those two points are not coupled. We ARE ALWAYS be on the
> alert
> > > for
> > > > > new
> > > > > > > > committers and PMC Members. This PMC has been ACTIVE in
> > > recognizing
> > > > > many of
> > > > > > > > those who are deserving.
> > > > > > > >
> > > > > > > > Here are the Pulsar Board reports:
> > > > > > > > https://whimsy.apache.org/board/minutes/Pulsar
> > > > > > > >
> > > > > > > > >
> > > > > > > > > = Is there any precedence?
> > > > > > > > > Yes. A lot.
> > > > > > > > > Many CNCF projects do it.
> > > > > > > > > Many Apache projects do it.
> > > > > > > >
> > > > > > > > I’ve been on many PMC’s and I cannot think of one that does
> > this.
> > > > > You’ve
> > > > > > > > come up with a few examples below, but I won’t be persuaded.
> > > > > > > >
> > > > > > > > > Apache foundations rules allow it.
> > > > > > > > >
> > > > > > > > > Read below to see examples and links.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > = Examples
> > > > > > > > >
> > > > > > > > > === etcD project <
> > > > > > > > https://github.com/etcd-io/etcd/blob/main/GOVERNANCE.md>
> > > > > > > >
> > > > > > > > I don’t care about how another Foundation does it.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Quote
> > > > > > > > >
> > > > > > > > > Life priorities, interests, and passions can change.
> > > Maintainers
> > > > > can
> > > > > > > > retire
> > > > > > > > > and move to the emeritus status
> > > > > > > > > <
> > > > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/etcd-io/etcd/blob/main/README.md#etcd-emeritus-maintainers
> > > > > > > > >.
> > > > > > > > > If a maintainer needs to step down, they should inform
> other
> > > > > maintainers,
> > > > > > > > > if possible, help find someone to pick up the related work.
> > At
> > > > the
> > > > > very
> > > > > > > > > least, ensure the related work can be continued. Afterward
> > they
> > > > can
> > > > > > > > remove
> > > > > > > > > themselves from list of existing maintainers.
> > > > > > > > >
> > > > > > > > > If a maintainer is not been performing their duties for
> > period
> > > of
> > > > > 12
> > > > > > > > > months, they can be removed by other maintainers. In that
> > case
> > > > > inactive
> > > > > > > > > maintainer will be first notified via an email. If
> situation
> > > > > doesn't
> > > > > > > > > improve, they will be removed. If an emeritus maintainer
> > wants
> > > to
> > > > > regain
> > > > > > > > an
> > > > > > > > > active role, they can do so by renewing their
> contributions.
> > > > Active
> > > > > > > > > maintainers should welcome such a move. Retiring of other
> > > > > maintainers or
> > > > > > > > > regaining the status should require approval of at least
> two
> > > > active
> > > > > > > > > maintainers.
> > > > > > > > >
> > > > > > > > > === Apache Gump
> > > > > > > > > According to this link <
> https://gump.apache.org/bylaws.html
> > >,
> > > > > they have
> > > > > > > > > emeritus status for maintainers and PMC members and policy
> to
> > > > > transition.
> > > > > > > >
> > > > > > > > Gump is a tiny project that does not release code. The two
> PMC
> > > > > members was
> > > > > > > > added in 2014. The rest were in 2004 - 2006. The project is a
> > > build
> > > > > system
> > > > > > > > that other projects used to use. I don’t even know if any
> > project
> > > > > still
> > > > > > > > uses it. In fact that are just keeping it up for Tomcat. See
> > > > > > > > https://whimsy.apache.org/board/minutes/Gump
> > > > > > > >
> > > > > > > > >
> > > > > > > > > QUOTE
> > > > > > > > > Committer access is by invitation only and must be approved
> > by
> > > > lazy
> > > > > > > > > consensus of the active PMC members. A Committer is
> > considered
> > > > > emeritus
> > > > > > > > by
> > > > > > > > > their own declaration or by not contributing in any form to
> > the
> > > > > project
> > > > > > > > for
> > > > > > > > > over six months. An emeritus committer may request
> > > reinstatement
> > > > of
> > > > > > > > commit
> > > > > > > > > access from the PMC. Such reinstatement is subject to lazy
> > > > > consensus of
> > > > > > > > > active PMC members.
> > > > > > > >
> > > > > > > > All of their committers except for on of 16 are ASF Members.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Membership of the PMC is by invitation only and must be
> > > approved
> > > > > by a
> > > > > > > > lazy
> > > > > > > > > consensus of active PMC members. A PMC member is considered
> > > > > "emeritus" by
> > > > > > > > > their own declaration or by not contributing in any form to
> > the
> > > > > project
> > > > > > > > for
> > > > > > > > > over six months. An emeritus member may request
> reinstatement
> > > to
> > > > > the PMC.
> > > > > > > > > Such reinstatement is subject to lazy consensus of the
> active
> > > PMC
> > > > > > > > members.
> > > > > > > > > Membership of the PMC can be revoked by an unanimous vote
> of
> > > all
> > > > > the
> > > > > > > > active
> > > > > > > > > PMC members other than the member in question.
> > > > > > > > >
> > > > > > > > > END QUOTE
> > > > > > > > >
> > > > > > > > > There are many more: Apache Hive
> > > > > > > > > <
> > > > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Committers
> > > > > > > > >,
> > > > > > > >
> > > > > > > > Hive has 56 PMC Members and 106 Committers. I can tell from
> > their
> > > > > roster
> > > > > > > > that many do not seem to be engaged any more.
> > > > > > > >
> > > > > > > > Board reports: https://whimsy.apache.org/board/minutes/Hive
> > > > > > > >
> > > > > > > > > Apache Orc <
> > > > > > > >
> https://github.com/apache/orc/blob/main/site/develop/bylaws.md
> > >,
> > > > > > > >
> > > > > > > > They are actively working to regrow, but I doubt they are
> > kicking
> > > > > out many
> > > > > > > > PMC members. You could read their board reports:
> > > > > > > > https://whimsy.apache.org/board/minutes/ORC
> > > > > > > >
> > > > > > > > > ...
> > > > > > > > >
> > > > > > > > > = What does Apache thinks about this?
> > > > > > > > >
> > > > > > > > > According to this link <
> > > > > https://www.apache.org/dev/pmc.html#pmc-removal
> > > > > > > > >,
> > > > > > > > > any project can have their policies for retire an inactive
> > PMC
> > > > > member.
> > > > > > > > >
> > > > > > > > > QUOTE
> > > > > > > > > SHOULD A PMC REMOVE INACTIVE MEMBERS?
> > > > > > > > > <https://www.apache.org/dev/pmc.html#pmc-removal>
> > > > > > > > >
> > > > > > > > > Projects can establish their own policy on handling
> inactive
> > > > > members, as
> > > > > > > > > long as they apply it 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
> > > > > > > > > (without that member's request or consent), 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 an email
> to
> > > the
> > > > > board@
> > > > > > > > > mailing list detailing the request for removal and the
> > > > > justification the
> > > > > > > > > PMC has for that removal, and copy the project's private@
> > > list.
> > > > > > > > >
> > > > > > > > > END QUOTE
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > = Summary
> > > > > > > > > I believe that Apache Pulsar has the responsibility with
> > > respect
> > > > > to its
> > > > > > > > > users to reflect the real number of people actively in the
> > > > project
> > > > > - its
> > > > > > > > > PMC members.
> > > > > > > >
> > > > > > > > How would you do it consistently? How would you measure
> > > > > disengagement?
> > > > > > > >
> > > > > > > > The only fair way would be to go through the exercise of
> > > measuring
> > > > > actual
> > > > > > > > engagement. Once you do I think that you will understand why
> it
> > > is
> > > > > not
> > > > > > > > really done.
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > Dave
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] PMC/Committer Emiratus status

[Asaf Mesika <as...@gmail.com>]

Do other think it's a good thing to adopt P. Taylor Goetz idea of active
flag and the process suggested?


On Mon, Mar 6, 2023 at 2:03 PM tison <wa...@gmail.com> wrote:

> Hi Yu,
>
> You can start by adding a page on the contribution guide or a table in the
> README of the main repo/site repo to state that you're an expert in the
> document domain.
>
> I have an in-house landscape about Pulsar modules, the broader ecosystem,
> and their active contributors/maintainers. Since people may not want to be
> referred to publicly by another person, I don't make it public.
>
> Finding experts can be a skill to collaborate in a community. You can find
> them when browsing relative PRs, analyzing the commit history, meeting them
> in the community, and having conversations. I don't have the motivation to
> maintain such a table publicly.
>
> Scala has a table of domain experts that can help[1]. If you like it, you
> can list yourself and try to bring other experts to list themselves. The
> ASF shares a sense that "The Foundation belongs to *you*". You're already a
> PMC member and able to drive such an effort.
>
> Best,
> tison.
>
> [1] https://github.com/scala/scala#get-in-touch
>
>
> Yu <li...@apache.org> 于2023年3月6日周一 19:48写道：
>
> > Hi Asaf,
> >
> > Thanks for bringing this up!
> >
> > If I may put my two pennies' worth:
> >
> > To be honest, this idea flashed across my mind previously. I talked about
> > this to my colleague, and he was surprised that I was willing to be
> > deprived of benefits (at that time, I was a PMC member already).
> >
> > PMC members are vital promotors and driving forces of a community.
> Ideally,
> > they should be direction leaders and make great contributions
> > *continuously*. No one should enjoy the benefits of honor but not
> > contribute much *all the time*. Setting retirement bars for PMC members
> > reminds us to contribute and provide value. Maybe I'm a little aggressive
> > :-)
> >
> > ~~~~~~
> >
> > +1 but a long list of PMC members with many inactive members does not
> > create a good feeling since "false prosperity" is no better than "real
> > contributions".
> >
> > > 3. Merit doesn’t expire.
> >
> > ~~~~~~
> >
> > Compared to my previous thought, Goetz has proposed a better idea since:
> >
> > 1. It's mild and can be accepted by many PMC members. A kind of life
> wisdom
> > :-)
> >
> > 2. People who need help (e.g., PIP approvals / PR comments / ...) from
> PMC
> > members can check the flags to know who is available to help.
> >
> > Except for flags, I suggest adding "area of expertise" for PMC members
> and
> > committers, so people will know who are the most suitable experts to ask
> > for help or collaborate.
> >
> > > 1. You can maintain active/inactive status at the project level with a
> > simple flag on a community page, without removing people from the PMC.
> > > 2. By making it an informal, self-reported flag, you avoid the overhead
> > of board resolutions, etc. and just manage it at the community level. If
> > someone wants to change their status, they can just say so or submit a
> pull
> > request to change their status on the pulsar website.
> >
> > ~~~~~~
> >
> > Yu
> >
> > On Sun, Mar 5, 2023 at 10:31 PM Asaf Mesika <as...@gmail.com>
> wrote:
> >
> > > Thanks to everyone who took the time to carefully answer with detailed
> > > explanations.
> > > I personally learned a lot about Apache projects this way (made me read
> > > about it some more).
> > >
> > > So my personal recap is:
> > >
> > >    - The goal of knowing the health of the Apache Pulsar community can
> be
> > >    achieved by taking a look at monthly active contributors over time
> > >    displayed on the community page.
> > >       - It could be nice getting those numbers on the mailing list
> itself
> > >       as well.
> > >    - Calculating the engagement is not an easy task.
> > >    - Kicking people off is not something you'd like to do in general
> and
> > >    specifically for volunteers.
> > >    - People's credit for work, which is also expressed in PMC
> membership
> > >    never expires due to Merit never expires - your work credit and
> earned
> > >    right should not expire.
> > >
> > >
> > > I personally see PMC members answering someone not a PMC member nor a
> > > comitter on this topic as a very healthy community indicator :)
> > >
> > > Thanks !
> > >
> > > Asaf
> > >
> > > On Fri, Mar 3, 2023 at 10:22 AM Enrico Olivelli <eo...@gmail.com>
> > > wrote:
> > >
> > > > This is an interesting discussion.
> > > > Good to see this kind of a discussion on the dev@ mailing list, this
> > > > way more people are aware of the fact that we are a project in the
> ASF
> > > > and there is a Project Management Committee.
> > > >
> > > > I have been following a few Apache projects for a while, and I
> believe
> > > > that this kind of discussions should be run on the private@ mailing
> > > > list.
> > > > It is the PMC that usually deals with this stuff.
> > > >
> > > > As Tison said, the common practice is that you never remove anyone
> > > > from a PMC or from the Committers list.
> > > >
> > > > This happens only in rare cases where an individual behaves in such a
> > > > way that the Project or the Foundation could be damaged,
> > > > for instance if you speak on behalf of the project and you offend
> > > > someone publicly.
> > > >
> > > > Inactive contributors/committers/PMC members do not do any harm to a
> > > > project.
> > > >
> > > > Some projects have some rules that you cannot participate in official
> > > > VOTEs if you are not "active".
> > > >
> > > > If anyone has some problems with someone in the community, then they
> > > > can reach out to private@pulsar.apache.org and the PMC will listen
> to
> > > > the problem and take actions.
> > > >
> > > > my 2 cents
> > > >
> > > > Enrico
> > > >
> > > > Il giorno ven 3 mar 2023 alle ore 04:39 Yunze Xu
> > > > <yz...@streamnative.io.invalid> ha scritto:
> > > > >
> > > > > As a PMC member, I don't like playing a game of determining who
> > should
> > > > > be removed from PMC as well.
> > > > >
> > > > > I hear a viewpoint that someone is only participating in the
> > community
> > > > > only to join a PMC so that he can benefit from it. After becoming a
> > > > > PMC member, he is never active in the community. It might be true
> but
> > > > > I think it's acceptable. Making such a rule won't prevent such
> cases.
> > > > > If he wants, he can make use of the rule and keep himself "active"
> to
> > > > > avoid being kicked out of the PMC. Though the active state is fake.
> > > > >
> > > > > I'm not against the way to remove (or something else that sounds
> > good)
> > > > > a PMC member because none of these ways is perfect. However, I'm
> > > > > STRONGLY AGAINST changing a rule that has been applied for some
> time
> > > > > unless it can be proved the rule is very harmful to the community.
> > > > > You mentioned https://www.apache.org/dev/pmc.html#pmc-removal. But
> > > > > please don't ignore the first sentence:
> > > > >
> > > > > > Projects can establish their own policy on handling inactive
> > members,
> > > > as long as they apply it CONSISTENTLY.
> > > > >
> > > > > In addition, Dave and Tison both mentioned we have some boards or
> > > > > webpages to see how many people are active. We don't need to remove
> > > > > some PMC members just for knowing who were still active recently.
> > > > >
> > > > > BTW, I'm also curious about the motivation of this proposal. I'm
> > > > > wondering how do the inactive PMC members harm the community?
> > > > >
> > > > > Thanks,
> > > > > Yunze
> > > > >
> > > > > On Fri, Mar 3, 2023 at 10:14 AM tison <wa...@gmail.com>
> wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > In the proposal, it's unclear if you'd like to _mark_ the
> inactive
> > > > members
> > > > > > in emeritus status or _remove_ them from the LDAP group.
> > > > > >
> > > > > > I saw a similar discussion in the Flink community, resulting in
> > > > "active"
> > > > > > sentences in its Bylaws[1]. Here is some consensus there:
> > > > > >
> > > > > > 1. Merits never expire. There's no reason to _remove_ a committer
> > or
> > > > PMC
> > > > > > member from the LDAP group because of inactive following the
> Apache
> > > > way. I
> > > > > > remember numbered cases a member got removed because they _keep_
> > > > harming
> > > > > > the community.
> > > > > > 2. Emeritus status is set for unblocking consensus. The Flink
> > > community
> > > > > > experienced some votes that could not get the required approvals
> in
> > > > time
> > > > > > and thus tried to unblock consensus by setting some members with
> > > > binding
> > > > > > votes in emeritus status. Do we spot concrete issues that the
> > Pulsar
> > > > > > community cannot work well with current PMC members and
> committers
> > > > group?
> > > > > > 3. Emeritus status is voluntary. I know that in other
> foundations,
> > it
> > > > can
> > > > > > be judged or eagerly applied, but in ASF, we share a "Community
> of
> > > > Peers"
> > > > > > sense that everyone is a volunteer. They won't be "fired" because
> > of
> > > > "low
> > > > > > productivity".
> > > > > >
> > > > > > > Gain real visibility into the health of the project in terms of
> > > real
> > > > > > active PMC / Committers members.
> > > > > >
> > > > > > On the community page, we already have a monthly active
> contributor
> > > > graph.
> > > > > > It's an insight concept; I don't think we should _remove_ members
> > for
> > > > such
> > > > > > a reason.
> > > > > >
> > > > > > > Have the alert threshold set correctly as to when it's time to
> > > start
> > > > > > working on recruiting new PMC / Committers members
> > > > > >
> > > > > > Ditto. When working in the community, you will know what modules
> or
> > > > repos
> > > > > > lack participants. For example, I remember someone proposing to
> > > promote
> > > > > > more committers working on Pulsar multilingual clients. It's not
> a
> > > > reason
> > > > > > for emeritus or removal.
> > > > > >
> > > > > > ---
> > > > > >
> > > > > > Generally, committers and PMC members have "Earned Authority" to
> be
> > > in
> > > > the
> > > > > > group. They share a high trust level, and I have numerous
> examples
> > > that
> > > > > > returned members do outstanding work. If we don't have some
> > critical
> > > > issues
> > > > > > to introduce an emeritus status, and such members do no harm, why
> > do
> > > > we set
> > > > > > a bar if they return?
> > > > > >
> > > > > > Best,
> > > > > > tison.
> > > > > >
> > > > > > [1]
> https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws
> > > > > >
> > > > > >
> > > > > > Dave Fisher <wa...@apache.org> 于2023年3月3日周五 09:37写道：
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > > On Mar 2, 2023, at 11:58 AM, Asaf Mesika <
> > asaf.mesika@gmail.com>
> > > > wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Following the discussion I've started in Pulsar bi-weekly
> > > meetings.
> > > > > > >
> > > > > > > As I said when you brought this up, I don’t think it is a good
> > > idea,
> > > > not a
> > > > > > > good idea at all.
> > > > > > >
> > > > > > > > Projects can establish their own policy on handling inactive
> > > > members, as
> > > > > > > > long as they apply it consistently.
> > > > > > >
> > > > > > >
> > > > > > > As a PMC member I have no desire to play a game of consistently
> > > > tossing
> > > > > > > PMC members who somehow haven’t met an engagement criteria.
> That
> > is
> > > > an
> > > > > > > anti-pattern to building a community. It would be disruptive
> and
> > > time
> > > > > > > consuming.
> > > > > > >
> > > > > > > >
> > > > > > > > = The idea
> > > > > > > > PMC and Committers members will transition into Emeritus
> status
> > > > after X
> > > > > > > > months of inactivity, or voluntarily.
> > > > > > >
> > > > > > > PMC members have the opportunity with or without this proposal
> to
> > > > > > > voluntarily resign as PMC members with or without giving up
> their
> > > > commit
> > > > > > > bit.
> > > > > > >
> > > > > > > >
> > > > > > > > = Why?
> > > > > > > > - Gain real visibility into the health of the project in
> terms
> > of
> > > > real
> > > > > > > > active PMC / Committers members.
> > > > > > >
> > > > > > > Here is an exercise. Generate activity reports to show
> criteria.
> > We
> > > > can
> > > > > > > correlate between the rosters and all of our GitHub
> repositories.
> > > > Also
> > > > > > > Mailing lists and slack which only goes back 90 days. I would
> be
> > > > better
> > > > > > > persuaded if you did that to actually show and prove that there
> > is
> > > a
> > > > > > > problem. I think you will find that it is a large amount of
> > effort
> > > > with
> > > > > > > little value in the end.
> > > > > > >
> > > > > > > > - Have the alert threshold set correctly as to when it's time
> > to
> > > > start
> > > > > > > > working on recruiting new PMC / Committers members.
> > > > > > >
> > > > > > > Those two points are not coupled. We ARE ALWAYS be on the alert
> > for
> > > > new
> > > > > > > committers and PMC Members. This PMC has been ACTIVE in
> > recognizing
> > > > many of
> > > > > > > those who are deserving.
> > > > > > >
> > > > > > > Here are the Pulsar Board reports:
> > > > > > > https://whimsy.apache.org/board/minutes/Pulsar
> > > > > > >
> > > > > > > >
> > > > > > > > = Is there any precedence?
> > > > > > > > Yes. A lot.
> > > > > > > > Many CNCF projects do it.
> > > > > > > > Many Apache projects do it.
> > > > > > >
> > > > > > > I’ve been on many PMC’s and I cannot think of one that does
> this.
> > > > You’ve
> > > > > > > come up with a few examples below, but I won’t be persuaded.
> > > > > > >
> > > > > > > > Apache foundations rules allow it.
> > > > > > > >
> > > > > > > > Read below to see examples and links.
> > > > > > > >
> > > > > > > >
> > > > > > > > = Examples
> > > > > > > >
> > > > > > > > === etcD project <
> > > > > > > https://github.com/etcd-io/etcd/blob/main/GOVERNANCE.md>
> > > > > > >
> > > > > > > I don’t care about how another Foundation does it.
> > > > > > >
> > > > > > > >
> > > > > > > > Quote
> > > > > > > >
> > > > > > > > Life priorities, interests, and passions can change.
> > Maintainers
> > > > can
> > > > > > > retire
> > > > > > > > and move to the emeritus status
> > > > > > > > <
> > > > > > >
> > > >
> > >
> >
> https://github.com/etcd-io/etcd/blob/main/README.md#etcd-emeritus-maintainers
> > > > > > > >.
> > > > > > > > If a maintainer needs to step down, they should inform other
> > > > maintainers,
> > > > > > > > if possible, help find someone to pick up the related work.
> At
> > > the
> > > > very
> > > > > > > > least, ensure the related work can be continued. Afterward
> they
> > > can
> > > > > > > remove
> > > > > > > > themselves from list of existing maintainers.
> > > > > > > >
> > > > > > > > If a maintainer is not been performing their duties for
> period
> > of
> > > > 12
> > > > > > > > months, they can be removed by other maintainers. In that
> case
> > > > inactive
> > > > > > > > maintainer will be first notified via an email. If situation
> > > > doesn't
> > > > > > > > improve, they will be removed. If an emeritus maintainer
> wants
> > to
> > > > regain
> > > > > > > an
> > > > > > > > active role, they can do so by renewing their contributions.
> > > Active
> > > > > > > > maintainers should welcome such a move. Retiring of other
> > > > maintainers or
> > > > > > > > regaining the status should require approval of at least two
> > > active
> > > > > > > > maintainers.
> > > > > > > >
> > > > > > > > === Apache Gump
> > > > > > > > According to this link <https://gump.apache.org/bylaws.html
> >,
> > > > they have
> > > > > > > > emeritus status for maintainers and PMC members and policy to
> > > > transition.
> > > > > > >
> > > > > > > Gump is a tiny project that does not release code. The two PMC
> > > > members was
> > > > > > > added in 2014. The rest were in 2004 - 2006. The project is a
> > build
> > > > system
> > > > > > > that other projects used to use. I don’t even know if any
> project
> > > > still
> > > > > > > uses it. In fact that are just keeping it up for Tomcat. See
> > > > > > > https://whimsy.apache.org/board/minutes/Gump
> > > > > > >
> > > > > > > >
> > > > > > > > QUOTE
> > > > > > > > Committer access is by invitation only and must be approved
> by
> > > lazy
> > > > > > > > consensus of the active PMC members. A Committer is
> considered
> > > > emeritus
> > > > > > > by
> > > > > > > > their own declaration or by not contributing in any form to
> the
> > > > project
> > > > > > > for
> > > > > > > > over six months. An emeritus committer may request
> > reinstatement
> > > of
> > > > > > > commit
> > > > > > > > access from the PMC. Such reinstatement is subject to lazy
> > > > consensus of
> > > > > > > > active PMC members.
> > > > > > >
> > > > > > > All of their committers except for on of 16 are ASF Members.
> > > > > > >
> > > > > > > >
> > > > > > > > Membership of the PMC is by invitation only and must be
> > approved
> > > > by a
> > > > > > > lazy
> > > > > > > > consensus of active PMC members. A PMC member is considered
> > > > "emeritus" by
> > > > > > > > their own declaration or by not contributing in any form to
> the
> > > > project
> > > > > > > for
> > > > > > > > over six months. An emeritus member may request reinstatement
> > to
> > > > the PMC.
> > > > > > > > Such reinstatement is subject to lazy consensus of the active
> > PMC
> > > > > > > members.
> > > > > > > > Membership of the PMC can be revoked by an unanimous vote of
> > all
> > > > the
> > > > > > > active
> > > > > > > > PMC members other than the member in question.
> > > > > > > >
> > > > > > > > END QUOTE
> > > > > > > >
> > > > > > > > There are many more: Apache Hive
> > > > > > > > <
> > > > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Committers
> > > > > > > >,
> > > > > > >
> > > > > > > Hive has 56 PMC Members and 106 Committers. I can tell from
> their
> > > > roster
> > > > > > > that many do not seem to be engaged any more.
> > > > > > >
> > > > > > > Board reports: https://whimsy.apache.org/board/minutes/Hive
> > > > > > >
> > > > > > > > Apache Orc <
> > > > > > > https://github.com/apache/orc/blob/main/site/develop/bylaws.md
> >,
> > > > > > >
> > > > > > > They are actively working to regrow, but I doubt they are
> kicking
> > > > out many
> > > > > > > PMC members. You could read their board reports:
> > > > > > > https://whimsy.apache.org/board/minutes/ORC
> > > > > > >
> > > > > > > > ...
> > > > > > > >
> > > > > > > > = What does Apache thinks about this?
> > > > > > > >
> > > > > > > > According to this link <
> > > > https://www.apache.org/dev/pmc.html#pmc-removal
> > > > > > > >,
> > > > > > > > any project can have their policies for retire an inactive
> PMC
> > > > member.
> > > > > > > >
> > > > > > > > QUOTE
> > > > > > > > SHOULD A PMC REMOVE INACTIVE MEMBERS?
> > > > > > > > <https://www.apache.org/dev/pmc.html#pmc-removal>
> > > > > > > >
> > > > > > > > Projects can establish their own policy on handling inactive
> > > > members, as
> > > > > > > > long as they apply it 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
> > > > > > > > (without that member's request or consent), 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 an email to
> > the
> > > > board@
> > > > > > > > mailing list detailing the request for removal and the
> > > > justification the
> > > > > > > > PMC has for that removal, and copy the project's private@
> > list.
> > > > > > > >
> > > > > > > > END QUOTE
> > > > > > > >
> > > > > > > >
> > > > > > > > = Summary
> > > > > > > > I believe that Apache Pulsar has the responsibility with
> > respect
> > > > to its
> > > > > > > > users to reflect the real number of people actively in the
> > > project
> > > > - its
> > > > > > > > PMC members.
> > > > > > >
> > > > > > > How would you do it consistently? How would you measure
> > > > disengagement?
> > > > > > >
> > > > > > > The only fair way would be to go through the exercise of
> > measuring
> > > > actual
> > > > > > > engagement. Once you do I think that you will understand why it
> > is
> > > > not
> > > > > > > really done.
> > > > > > >
> > > > > > > Best,
> > > > > > > Dave
> > > > > > >
> > > > > > >
> > > > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] PMC/Committer Emiratus status

[tison <wa...@gmail.com>]

Hi Yu,

You can start by adding a page on the contribution guide or a table in the
README of the main repo/site repo to state that you're an expert in the
document domain.

I have an in-house landscape about Pulsar modules, the broader ecosystem,
and their active contributors/maintainers. Since people may not want to be
referred to publicly by another person, I don't make it public.

Finding experts can be a skill to collaborate in a community. You can find
them when browsing relative PRs, analyzing the commit history, meeting them
in the community, and having conversations. I don't have the motivation to
maintain such a table publicly.

Scala has a table of domain experts that can help[1]. If you like it, you
can list yourself and try to bring other experts to list themselves. The
ASF shares a sense that "The Foundation belongs to *you*". You're already a
PMC member and able to drive such an effort.

Best,
tison.

[1] https://github.com/scala/scala#get-in-touch


Yu <li...@apache.org> 于2023年3月6日周一 19:48写道：

> Hi Asaf,
>
> Thanks for bringing this up!
>
> If I may put my two pennies' worth:
>
> To be honest, this idea flashed across my mind previously. I talked about
> this to my colleague, and he was surprised that I was willing to be
> deprived of benefits (at that time, I was a PMC member already).
>
> PMC members are vital promotors and driving forces of a community. Ideally,
> they should be direction leaders and make great contributions
> *continuously*. No one should enjoy the benefits of honor but not
> contribute much *all the time*. Setting retirement bars for PMC members
> reminds us to contribute and provide value. Maybe I'm a little aggressive
> :-)
>
> ~~~~~~
>
> +1 but a long list of PMC members with many inactive members does not
> create a good feeling since "false prosperity" is no better than "real
> contributions".
>
> > 3. Merit doesn’t expire.
>
> ~~~~~~
>
> Compared to my previous thought, Goetz has proposed a better idea since:
>
> 1. It's mild and can be accepted by many PMC members. A kind of life wisdom
> :-)
>
> 2. People who need help (e.g., PIP approvals / PR comments / ...) from PMC
> members can check the flags to know who is available to help.
>
> Except for flags, I suggest adding "area of expertise" for PMC members and
> committers, so people will know who are the most suitable experts to ask
> for help or collaborate.
>
> > 1. You can maintain active/inactive status at the project level with a
> simple flag on a community page, without removing people from the PMC.
> > 2. By making it an informal, self-reported flag, you avoid the overhead
> of board resolutions, etc. and just manage it at the community level. If
> someone wants to change their status, they can just say so or submit a pull
> request to change their status on the pulsar website.
>
> ~~~~~~
>
> Yu
>
> On Sun, Mar 5, 2023 at 10:31 PM Asaf Mesika <as...@gmail.com> wrote:
>
> > Thanks to everyone who took the time to carefully answer with detailed
> > explanations.
> > I personally learned a lot about Apache projects this way (made me read
> > about it some more).
> >
> > So my personal recap is:
> >
> >    - The goal of knowing the health of the Apache Pulsar community can be
> >    achieved by taking a look at monthly active contributors over time
> >    displayed on the community page.
> >       - It could be nice getting those numbers on the mailing list itself
> >       as well.
> >    - Calculating the engagement is not an easy task.
> >    - Kicking people off is not something you'd like to do in general and
> >    specifically for volunteers.
> >    - People's credit for work, which is also expressed in PMC membership
> >    never expires due to Merit never expires - your work credit and earned
> >    right should not expire.
> >
> >
> > I personally see PMC members answering someone not a PMC member nor a
> > comitter on this topic as a very healthy community indicator :)
> >
> > Thanks !
> >
> > Asaf
> >
> > On Fri, Mar 3, 2023 at 10:22 AM Enrico Olivelli <eo...@gmail.com>
> > wrote:
> >
> > > This is an interesting discussion.
> > > Good to see this kind of a discussion on the dev@ mailing list, this
> > > way more people are aware of the fact that we are a project in the ASF
> > > and there is a Project Management Committee.
> > >
> > > I have been following a few Apache projects for a while, and I believe
> > > that this kind of discussions should be run on the private@ mailing
> > > list.
> > > It is the PMC that usually deals with this stuff.
> > >
> > > As Tison said, the common practice is that you never remove anyone
> > > from a PMC or from the Committers list.
> > >
> > > This happens only in rare cases where an individual behaves in such a
> > > way that the Project or the Foundation could be damaged,
> > > for instance if you speak on behalf of the project and you offend
> > > someone publicly.
> > >
> > > Inactive contributors/committers/PMC members do not do any harm to a
> > > project.
> > >
> > > Some projects have some rules that you cannot participate in official
> > > VOTEs if you are not "active".
> > >
> > > If anyone has some problems with someone in the community, then they
> > > can reach out to private@pulsar.apache.org and the PMC will listen to
> > > the problem and take actions.
> > >
> > > my 2 cents
> > >
> > > Enrico
> > >
> > > Il giorno ven 3 mar 2023 alle ore 04:39 Yunze Xu
> > > <yz...@streamnative.io.invalid> ha scritto:
> > > >
> > > > As a PMC member, I don't like playing a game of determining who
> should
> > > > be removed from PMC as well.
> > > >
> > > > I hear a viewpoint that someone is only participating in the
> community
> > > > only to join a PMC so that he can benefit from it. After becoming a
> > > > PMC member, he is never active in the community. It might be true but
> > > > I think it's acceptable. Making such a rule won't prevent such cases.
> > > > If he wants, he can make use of the rule and keep himself "active" to
> > > > avoid being kicked out of the PMC. Though the active state is fake.
> > > >
> > > > I'm not against the way to remove (or something else that sounds
> good)
> > > > a PMC member because none of these ways is perfect. However, I'm
> > > > STRONGLY AGAINST changing a rule that has been applied for some time
> > > > unless it can be proved the rule is very harmful to the community.
> > > > You mentioned https://www.apache.org/dev/pmc.html#pmc-removal. But
> > > > please don't ignore the first sentence:
> > > >
> > > > > Projects can establish their own policy on handling inactive
> members,
> > > as long as they apply it CONSISTENTLY.
> > > >
> > > > In addition, Dave and Tison both mentioned we have some boards or
> > > > webpages to see how many people are active. We don't need to remove
> > > > some PMC members just for knowing who were still active recently.
> > > >
> > > > BTW, I'm also curious about the motivation of this proposal. I'm
> > > > wondering how do the inactive PMC members harm the community?
> > > >
> > > > Thanks,
> > > > Yunze
> > > >
> > > > On Fri, Mar 3, 2023 at 10:14 AM tison <wa...@gmail.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > In the proposal, it's unclear if you'd like to _mark_ the inactive
> > > members
> > > > > in emeritus status or _remove_ them from the LDAP group.
> > > > >
> > > > > I saw a similar discussion in the Flink community, resulting in
> > > "active"
> > > > > sentences in its Bylaws[1]. Here is some consensus there:
> > > > >
> > > > > 1. Merits never expire. There's no reason to _remove_ a committer
> or
> > > PMC
> > > > > member from the LDAP group because of inactive following the Apache
> > > way. I
> > > > > remember numbered cases a member got removed because they _keep_
> > > harming
> > > > > the community.
> > > > > 2. Emeritus status is set for unblocking consensus. The Flink
> > community
> > > > > experienced some votes that could not get the required approvals in
> > > time
> > > > > and thus tried to unblock consensus by setting some members with
> > > binding
> > > > > votes in emeritus status. Do we spot concrete issues that the
> Pulsar
> > > > > community cannot work well with current PMC members and committers
> > > group?
> > > > > 3. Emeritus status is voluntary. I know that in other foundations,
> it
> > > can
> > > > > be judged or eagerly applied, but in ASF, we share a "Community of
> > > Peers"
> > > > > sense that everyone is a volunteer. They won't be "fired" because
> of
> > > "low
> > > > > productivity".
> > > > >
> > > > > > Gain real visibility into the health of the project in terms of
> > real
> > > > > active PMC / Committers members.
> > > > >
> > > > > On the community page, we already have a monthly active contributor
> > > graph.
> > > > > It's an insight concept; I don't think we should _remove_ members
> for
> > > such
> > > > > a reason.
> > > > >
> > > > > > Have the alert threshold set correctly as to when it's time to
> > start
> > > > > working on recruiting new PMC / Committers members
> > > > >
> > > > > Ditto. When working in the community, you will know what modules or
> > > repos
> > > > > lack participants. For example, I remember someone proposing to
> > promote
> > > > > more committers working on Pulsar multilingual clients. It's not a
> > > reason
> > > > > for emeritus or removal.
> > > > >
> > > > > ---
> > > > >
> > > > > Generally, committers and PMC members have "Earned Authority" to be
> > in
> > > the
> > > > > group. They share a high trust level, and I have numerous examples
> > that
> > > > > returned members do outstanding work. If we don't have some
> critical
> > > issues
> > > > > to introduce an emeritus status, and such members do no harm, why
> do
> > > we set
> > > > > a bar if they return?
> > > > >
> > > > > Best,
> > > > > tison.
> > > > >
> > > > > [1] https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws
> > > > >
> > > > >
> > > > > Dave Fisher <wa...@apache.org> 于2023年3月3日周五 09:37写道：
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > > On Mar 2, 2023, at 11:58 AM, Asaf Mesika <
> asaf.mesika@gmail.com>
> > > wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Following the discussion I've started in Pulsar bi-weekly
> > meetings.
> > > > > >
> > > > > > As I said when you brought this up, I don’t think it is a good
> > idea,
> > > not a
> > > > > > good idea at all.
> > > > > >
> > > > > > > Projects can establish their own policy on handling inactive
> > > members, as
> > > > > > > long as they apply it consistently.
> > > > > >
> > > > > >
> > > > > > As a PMC member I have no desire to play a game of consistently
> > > tossing
> > > > > > PMC members who somehow haven’t met an engagement criteria. That
> is
> > > an
> > > > > > anti-pattern to building a community. It would be disruptive and
> > time
> > > > > > consuming.
> > > > > >
> > > > > > >
> > > > > > > = The idea
> > > > > > > PMC and Committers members will transition into Emeritus status
> > > after X
> > > > > > > months of inactivity, or voluntarily.
> > > > > >
> > > > > > PMC members have the opportunity with or without this proposal to
> > > > > > voluntarily resign as PMC members with or without giving up their
> > > commit
> > > > > > bit.
> > > > > >
> > > > > > >
> > > > > > > = Why?
> > > > > > > - Gain real visibility into the health of the project in terms
> of
> > > real
> > > > > > > active PMC / Committers members.
> > > > > >
> > > > > > Here is an exercise. Generate activity reports to show criteria.
> We
> > > can
> > > > > > correlate between the rosters and all of our GitHub repositories.
> > > Also
> > > > > > Mailing lists and slack which only goes back 90 days. I would be
> > > better
> > > > > > persuaded if you did that to actually show and prove that there
> is
> > a
> > > > > > problem. I think you will find that it is a large amount of
> effort
> > > with
> > > > > > little value in the end.
> > > > > >
> > > > > > > - Have the alert threshold set correctly as to when it's time
> to
> > > start
> > > > > > > working on recruiting new PMC / Committers members.
> > > > > >
> > > > > > Those two points are not coupled. We ARE ALWAYS be on the alert
> for
> > > new
> > > > > > committers and PMC Members. This PMC has been ACTIVE in
> recognizing
> > > many of
> > > > > > those who are deserving.
> > > > > >
> > > > > > Here are the Pulsar Board reports:
> > > > > > https://whimsy.apache.org/board/minutes/Pulsar
> > > > > >
> > > > > > >
> > > > > > > = Is there any precedence?
> > > > > > > Yes. A lot.
> > > > > > > Many CNCF projects do it.
> > > > > > > Many Apache projects do it.
> > > > > >
> > > > > > I’ve been on many PMC’s and I cannot think of one that does this.
> > > You’ve
> > > > > > come up with a few examples below, but I won’t be persuaded.
> > > > > >
> > > > > > > Apache foundations rules allow it.
> > > > > > >
> > > > > > > Read below to see examples and links.
> > > > > > >
> > > > > > >
> > > > > > > = Examples
> > > > > > >
> > > > > > > === etcD project <
> > > > > > https://github.com/etcd-io/etcd/blob/main/GOVERNANCE.md>
> > > > > >
> > > > > > I don’t care about how another Foundation does it.
> > > > > >
> > > > > > >
> > > > > > > Quote
> > > > > > >
> > > > > > > Life priorities, interests, and passions can change.
> Maintainers
> > > can
> > > > > > retire
> > > > > > > and move to the emeritus status
> > > > > > > <
> > > > > >
> > >
> >
> https://github.com/etcd-io/etcd/blob/main/README.md#etcd-emeritus-maintainers
> > > > > > >.
> > > > > > > If a maintainer needs to step down, they should inform other
> > > maintainers,
> > > > > > > if possible, help find someone to pick up the related work. At
> > the
> > > very
> > > > > > > least, ensure the related work can be continued. Afterward they
> > can
> > > > > > remove
> > > > > > > themselves from list of existing maintainers.
> > > > > > >
> > > > > > > If a maintainer is not been performing their duties for period
> of
> > > 12
> > > > > > > months, they can be removed by other maintainers. In that case
> > > inactive
> > > > > > > maintainer will be first notified via an email. If situation
> > > doesn't
> > > > > > > improve, they will be removed. If an emeritus maintainer wants
> to
> > > regain
> > > > > > an
> > > > > > > active role, they can do so by renewing their contributions.
> > Active
> > > > > > > maintainers should welcome such a move. Retiring of other
> > > maintainers or
> > > > > > > regaining the status should require approval of at least two
> > active
> > > > > > > maintainers.
> > > > > > >
> > > > > > > === Apache Gump
> > > > > > > According to this link <https://gump.apache.org/bylaws.html>,
> > > they have
> > > > > > > emeritus status for maintainers and PMC members and policy to
> > > transition.
> > > > > >
> > > > > > Gump is a tiny project that does not release code. The two PMC
> > > members was
> > > > > > added in 2014. The rest were in 2004 - 2006. The project is a
> build
> > > system
> > > > > > that other projects used to use. I don’t even know if any project
> > > still
> > > > > > uses it. In fact that are just keeping it up for Tomcat. See
> > > > > > https://whimsy.apache.org/board/minutes/Gump
> > > > > >
> > > > > > >
> > > > > > > QUOTE
> > > > > > > Committer access is by invitation only and must be approved by
> > lazy
> > > > > > > consensus of the active PMC members. A Committer is considered
> > > emeritus
> > > > > > by
> > > > > > > their own declaration or by not contributing in any form to the
> > > project
> > > > > > for
> > > > > > > over six months. An emeritus committer may request
> reinstatement
> > of
> > > > > > commit
> > > > > > > access from the PMC. Such reinstatement is subject to lazy
> > > consensus of
> > > > > > > active PMC members.
> > > > > >
> > > > > > All of their committers except for on of 16 are ASF Members.
> > > > > >
> > > > > > >
> > > > > > > Membership of the PMC is by invitation only and must be
> approved
> > > by a
> > > > > > lazy
> > > > > > > consensus of active PMC members. A PMC member is considered
> > > "emeritus" by
> > > > > > > their own declaration or by not contributing in any form to the
> > > project
> > > > > > for
> > > > > > > over six months. An emeritus member may request reinstatement
> to
> > > the PMC.
> > > > > > > Such reinstatement is subject to lazy consensus of the active
> PMC
> > > > > > members.
> > > > > > > Membership of the PMC can be revoked by an unanimous vote of
> all
> > > the
> > > > > > active
> > > > > > > PMC members other than the member in question.
> > > > > > >
> > > > > > > END QUOTE
> > > > > > >
> > > > > > > There are many more: Apache Hive
> > > > > > > <
> > > > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Committers
> > > > > > >,
> > > > > >
> > > > > > Hive has 56 PMC Members and 106 Committers. I can tell from their
> > > roster
> > > > > > that many do not seem to be engaged any more.
> > > > > >
> > > > > > Board reports: https://whimsy.apache.org/board/minutes/Hive
> > > > > >
> > > > > > > Apache Orc <
> > > > > > https://github.com/apache/orc/blob/main/site/develop/bylaws.md>,
> > > > > >
> > > > > > They are actively working to regrow, but I doubt they are kicking
> > > out many
> > > > > > PMC members. You could read their board reports:
> > > > > > https://whimsy.apache.org/board/minutes/ORC
> > > > > >
> > > > > > > ...
> > > > > > >
> > > > > > > = What does Apache thinks about this?
> > > > > > >
> > > > > > > According to this link <
> > > https://www.apache.org/dev/pmc.html#pmc-removal
> > > > > > >,
> > > > > > > any project can have their policies for retire an inactive PMC
> > > member.
> > > > > > >
> > > > > > > QUOTE
> > > > > > > SHOULD A PMC REMOVE INACTIVE MEMBERS?
> > > > > > > <https://www.apache.org/dev/pmc.html#pmc-removal>
> > > > > > >
> > > > > > > Projects can establish their own policy on handling inactive
> > > members, as
> > > > > > > long as they apply it 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
> > > > > > > (without that member's request or consent), 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 an email to
> the
> > > board@
> > > > > > > mailing list detailing the request for removal and the
> > > justification the
> > > > > > > PMC has for that removal, and copy the project's private@
> list.
> > > > > > >
> > > > > > > END QUOTE
> > > > > > >
> > > > > > >
> > > > > > > = Summary
> > > > > > > I believe that Apache Pulsar has the responsibility with
> respect
> > > to its
> > > > > > > users to reflect the real number of people actively in the
> > project
> > > - its
> > > > > > > PMC members.
> > > > > >
> > > > > > How would you do it consistently? How would you measure
> > > disengagement?
> > > > > >
> > > > > > The only fair way would be to go through the exercise of
> measuring
> > > actual
> > > > > > engagement. Once you do I think that you will understand why it
> is
> > > not
> > > > > > really done.
> > > > > >
> > > > > > Best,
> > > > > > Dave
> > > > > >
> > > > > >
> > > > > >
> > >
> >
>

Re: [DISCUSS] PMC/Committer Emiratus status

[Yu <li...@apache.org>]

Hi Asaf,

Thanks for bringing this up!

If I may put my two pennies' worth:

To be honest, this idea flashed across my mind previously. I talked about
this to my colleague, and he was surprised that I was willing to be
deprived of benefits (at that time, I was a PMC member already).

PMC members are vital promotors and driving forces of a community. Ideally,
they should be direction leaders and make great contributions
*continuously*. No one should enjoy the benefits of honor but not
contribute much *all the time*. Setting retirement bars for PMC members
reminds us to contribute and provide value. Maybe I'm a little aggressive
:-)

~~~~~~

+1 but a long list of PMC members with many inactive members does not
create a good feeling since "false prosperity" is no better than "real
contributions".

> 3. Merit doesn’t expire.

~~~~~~

Compared to my previous thought, Goetz has proposed a better idea since:

1. It's mild and can be accepted by many PMC members. A kind of life wisdom
:-)

2. People who need help (e.g., PIP approvals / PR comments / ...) from PMC
members can check the flags to know who is available to help.

Except for flags, I suggest adding "area of expertise" for PMC members and
committers, so people will know who are the most suitable experts to ask
for help or collaborate.

> 1. You can maintain active/inactive status at the project level with a
simple flag on a community page, without removing people from the PMC.
> 2. By making it an informal, self-reported flag, you avoid the overhead
of board resolutions, etc. and just manage it at the community level. If
someone wants to change their status, they can just say so or submit a pull
request to change their status on the pulsar website.

~~~~~~

Yu

On Sun, Mar 5, 2023 at 10:31 PM Asaf Mesika <as...@gmail.com> wrote:

> Thanks to everyone who took the time to carefully answer with detailed
> explanations.
> I personally learned a lot about Apache projects this way (made me read
> about it some more).
>
> So my personal recap is:
>
>    - The goal of knowing the health of the Apache Pulsar community can be
>    achieved by taking a look at monthly active contributors over time
>    displayed on the community page.
>       - It could be nice getting those numbers on the mailing list itself
>       as well.
>    - Calculating the engagement is not an easy task.
>    - Kicking people off is not something you'd like to do in general and
>    specifically for volunteers.
>    - People's credit for work, which is also expressed in PMC membership
>    never expires due to Merit never expires - your work credit and earned
>    right should not expire.
>
>
> I personally see PMC members answering someone not a PMC member nor a
> comitter on this topic as a very healthy community indicator :)
>
> Thanks !
>
> Asaf
>
> On Fri, Mar 3, 2023 at 10:22 AM Enrico Olivelli <eo...@gmail.com>
> wrote:
>
> > This is an interesting discussion.
> > Good to see this kind of a discussion on the dev@ mailing list, this
> > way more people are aware of the fact that we are a project in the ASF
> > and there is a Project Management Committee.
> >
> > I have been following a few Apache projects for a while, and I believe
> > that this kind of discussions should be run on the private@ mailing
> > list.
> > It is the PMC that usually deals with this stuff.
> >
> > As Tison said, the common practice is that you never remove anyone
> > from a PMC or from the Committers list.
> >
> > This happens only in rare cases where an individual behaves in such a
> > way that the Project or the Foundation could be damaged,
> > for instance if you speak on behalf of the project and you offend
> > someone publicly.
> >
> > Inactive contributors/committers/PMC members do not do any harm to a
> > project.
> >
> > Some projects have some rules that you cannot participate in official
> > VOTEs if you are not "active".
> >
> > If anyone has some problems with someone in the community, then they
> > can reach out to private@pulsar.apache.org and the PMC will listen to
> > the problem and take actions.
> >
> > my 2 cents
> >
> > Enrico
> >
> > Il giorno ven 3 mar 2023 alle ore 04:39 Yunze Xu
> > <yz...@streamnative.io.invalid> ha scritto:
> > >
> > > As a PMC member, I don't like playing a game of determining who should
> > > be removed from PMC as well.
> > >
> > > I hear a viewpoint that someone is only participating in the community
> > > only to join a PMC so that he can benefit from it. After becoming a
> > > PMC member, he is never active in the community. It might be true but
> > > I think it's acceptable. Making such a rule won't prevent such cases.
> > > If he wants, he can make use of the rule and keep himself "active" to
> > > avoid being kicked out of the PMC. Though the active state is fake.
> > >
> > > I'm not against the way to remove (or something else that sounds good)
> > > a PMC member because none of these ways is perfect. However, I'm
> > > STRONGLY AGAINST changing a rule that has been applied for some time
> > > unless it can be proved the rule is very harmful to the community.
> > > You mentioned https://www.apache.org/dev/pmc.html#pmc-removal. But
> > > please don't ignore the first sentence:
> > >
> > > > Projects can establish their own policy on handling inactive members,
> > as long as they apply it CONSISTENTLY.
> > >
> > > In addition, Dave and Tison both mentioned we have some boards or
> > > webpages to see how many people are active. We don't need to remove
> > > some PMC members just for knowing who were still active recently.
> > >
> > > BTW, I'm also curious about the motivation of this proposal. I'm
> > > wondering how do the inactive PMC members harm the community?
> > >
> > > Thanks,
> > > Yunze
> > >
> > > On Fri, Mar 3, 2023 at 10:14 AM tison <wa...@gmail.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > In the proposal, it's unclear if you'd like to _mark_ the inactive
> > members
> > > > in emeritus status or _remove_ them from the LDAP group.
> > > >
> > > > I saw a similar discussion in the Flink community, resulting in
> > "active"
> > > > sentences in its Bylaws[1]. Here is some consensus there:
> > > >
> > > > 1. Merits never expire. There's no reason to _remove_ a committer or
> > PMC
> > > > member from the LDAP group because of inactive following the Apache
> > way. I
> > > > remember numbered cases a member got removed because they _keep_
> > harming
> > > > the community.
> > > > 2. Emeritus status is set for unblocking consensus. The Flink
> community
> > > > experienced some votes that could not get the required approvals in
> > time
> > > > and thus tried to unblock consensus by setting some members with
> > binding
> > > > votes in emeritus status. Do we spot concrete issues that the Pulsar
> > > > community cannot work well with current PMC members and committers
> > group?
> > > > 3. Emeritus status is voluntary. I know that in other foundations, it
> > can
> > > > be judged or eagerly applied, but in ASF, we share a "Community of
> > Peers"
> > > > sense that everyone is a volunteer. They won't be "fired" because of
> > "low
> > > > productivity".
> > > >
> > > > > Gain real visibility into the health of the project in terms of
> real
> > > > active PMC / Committers members.
> > > >
> > > > On the community page, we already have a monthly active contributor
> > graph.
> > > > It's an insight concept; I don't think we should _remove_ members for
> > such
> > > > a reason.
> > > >
> > > > > Have the alert threshold set correctly as to when it's time to
> start
> > > > working on recruiting new PMC / Committers members
> > > >
> > > > Ditto. When working in the community, you will know what modules or
> > repos
> > > > lack participants. For example, I remember someone proposing to
> promote
> > > > more committers working on Pulsar multilingual clients. It's not a
> > reason
> > > > for emeritus or removal.
> > > >
> > > > ---
> > > >
> > > > Generally, committers and PMC members have "Earned Authority" to be
> in
> > the
> > > > group. They share a high trust level, and I have numerous examples
> that
> > > > returned members do outstanding work. If we don't have some critical
> > issues
> > > > to introduce an emeritus status, and such members do no harm, why do
> > we set
> > > > a bar if they return?
> > > >
> > > > Best,
> > > > tison.
> > > >
> > > > [1] https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws
> > > >
> > > >
> > > > Dave Fisher <wa...@apache.org> 于2023年3月3日周五 09:37写道：
> > > >
> > > > > Hi,
> > > > >
> > > > > > On Mar 2, 2023, at 11:58 AM, Asaf Mesika <as...@gmail.com>
> > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Following the discussion I've started in Pulsar bi-weekly
> meetings.
> > > > >
> > > > > As I said when you brought this up, I don’t think it is a good
> idea,
> > not a
> > > > > good idea at all.
> > > > >
> > > > > > Projects can establish their own policy on handling inactive
> > members, as
> > > > > > long as they apply it consistently.
> > > > >
> > > > >
> > > > > As a PMC member I have no desire to play a game of consistently
> > tossing
> > > > > PMC members who somehow haven’t met an engagement criteria. That is
> > an
> > > > > anti-pattern to building a community. It would be disruptive and
> time
> > > > > consuming.
> > > > >
> > > > > >
> > > > > > = The idea
> > > > > > PMC and Committers members will transition into Emeritus status
> > after X
> > > > > > months of inactivity, or voluntarily.
> > > > >
> > > > > PMC members have the opportunity with or without this proposal to
> > > > > voluntarily resign as PMC members with or without giving up their
> > commit
> > > > > bit.
> > > > >
> > > > > >
> > > > > > = Why?
> > > > > > - Gain real visibility into the health of the project in terms of
> > real
> > > > > > active PMC / Committers members.
> > > > >
> > > > > Here is an exercise. Generate activity reports to show criteria. We
> > can
> > > > > correlate between the rosters and all of our GitHub repositories.
> > Also
> > > > > Mailing lists and slack which only goes back 90 days. I would be
> > better
> > > > > persuaded if you did that to actually show and prove that there is
> a
> > > > > problem. I think you will find that it is a large amount of effort
> > with
> > > > > little value in the end.
> > > > >
> > > > > > - Have the alert threshold set correctly as to when it's time to
> > start
> > > > > > working on recruiting new PMC / Committers members.
> > > > >
> > > > > Those two points are not coupled. We ARE ALWAYS be on the alert for
> > new
> > > > > committers and PMC Members. This PMC has been ACTIVE in recognizing
> > many of
> > > > > those who are deserving.
> > > > >
> > > > > Here are the Pulsar Board reports:
> > > > > https://whimsy.apache.org/board/minutes/Pulsar
> > > > >
> > > > > >
> > > > > > = Is there any precedence?
> > > > > > Yes. A lot.
> > > > > > Many CNCF projects do it.
> > > > > > Many Apache projects do it.
> > > > >
> > > > > I’ve been on many PMC’s and I cannot think of one that does this.
> > You’ve
> > > > > come up with a few examples below, but I won’t be persuaded.
> > > > >
> > > > > > Apache foundations rules allow it.
> > > > > >
> > > > > > Read below to see examples and links.
> > > > > >
> > > > > >
> > > > > > = Examples
> > > > > >
> > > > > > === etcD project <
> > > > > https://github.com/etcd-io/etcd/blob/main/GOVERNANCE.md>
> > > > >
> > > > > I don’t care about how another Foundation does it.
> > > > >
> > > > > >
> > > > > > Quote
> > > > > >
> > > > > > Life priorities, interests, and passions can change. Maintainers
> > can
> > > > > retire
> > > > > > and move to the emeritus status
> > > > > > <
> > > > >
> >
> https://github.com/etcd-io/etcd/blob/main/README.md#etcd-emeritus-maintainers
> > > > > >.
> > > > > > If a maintainer needs to step down, they should inform other
> > maintainers,
> > > > > > if possible, help find someone to pick up the related work. At
> the
> > very
> > > > > > least, ensure the related work can be continued. Afterward they
> can
> > > > > remove
> > > > > > themselves from list of existing maintainers.
> > > > > >
> > > > > > If a maintainer is not been performing their duties for period of
> > 12
> > > > > > months, they can be removed by other maintainers. In that case
> > inactive
> > > > > > maintainer will be first notified via an email. If situation
> > doesn't
> > > > > > improve, they will be removed. If an emeritus maintainer wants to
> > regain
> > > > > an
> > > > > > active role, they can do so by renewing their contributions.
> Active
> > > > > > maintainers should welcome such a move. Retiring of other
> > maintainers or
> > > > > > regaining the status should require approval of at least two
> active
> > > > > > maintainers.
> > > > > >
> > > > > > === Apache Gump
> > > > > > According to this link <https://gump.apache.org/bylaws.html>,
> > they have
> > > > > > emeritus status for maintainers and PMC members and policy to
> > transition.
> > > > >
> > > > > Gump is a tiny project that does not release code. The two PMC
> > members was
> > > > > added in 2014. The rest were in 2004 - 2006. The project is a build
> > system
> > > > > that other projects used to use. I don’t even know if any project
> > still
> > > > > uses it. In fact that are just keeping it up for Tomcat. See
> > > > > https://whimsy.apache.org/board/minutes/Gump
> > > > >
> > > > > >
> > > > > > QUOTE
> > > > > > Committer access is by invitation only and must be approved by
> lazy
> > > > > > consensus of the active PMC members. A Committer is considered
> > emeritus
> > > > > by
> > > > > > their own declaration or by not contributing in any form to the
> > project
> > > > > for
> > > > > > over six months. An emeritus committer may request reinstatement
> of
> > > > > commit
> > > > > > access from the PMC. Such reinstatement is subject to lazy
> > consensus of
> > > > > > active PMC members.
> > > > >
> > > > > All of their committers except for on of 16 are ASF Members.
> > > > >
> > > > > >
> > > > > > Membership of the PMC is by invitation only and must be approved
> > by a
> > > > > lazy
> > > > > > consensus of active PMC members. A PMC member is considered
> > "emeritus" by
> > > > > > their own declaration or by not contributing in any form to the
> > project
> > > > > for
> > > > > > over six months. An emeritus member may request reinstatement to
> > the PMC.
> > > > > > Such reinstatement is subject to lazy consensus of the active PMC
> > > > > members.
> > > > > > Membership of the PMC can be revoked by an unanimous vote of all
> > the
> > > > > active
> > > > > > PMC members other than the member in question.
> > > > > >
> > > > > > END QUOTE
> > > > > >
> > > > > > There are many more: Apache Hive
> > > > > > <
> > > > >
> >
> https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Committers
> > > > > >,
> > > > >
> > > > > Hive has 56 PMC Members and 106 Committers. I can tell from their
> > roster
> > > > > that many do not seem to be engaged any more.
> > > > >
> > > > > Board reports: https://whimsy.apache.org/board/minutes/Hive
> > > > >
> > > > > > Apache Orc <
> > > > > https://github.com/apache/orc/blob/main/site/develop/bylaws.md>,
> > > > >
> > > > > They are actively working to regrow, but I doubt they are kicking
> > out many
> > > > > PMC members. You could read their board reports:
> > > > > https://whimsy.apache.org/board/minutes/ORC
> > > > >
> > > > > > ...
> > > > > >
> > > > > > = What does Apache thinks about this?
> > > > > >
> > > > > > According to this link <
> > https://www.apache.org/dev/pmc.html#pmc-removal
> > > > > >,
> > > > > > any project can have their policies for retire an inactive PMC
> > member.
> > > > > >
> > > > > > QUOTE
> > > > > > SHOULD A PMC REMOVE INACTIVE MEMBERS?
> > > > > > <https://www.apache.org/dev/pmc.html#pmc-removal>
> > > > > >
> > > > > > Projects can establish their own policy on handling inactive
> > members, as
> > > > > > long as they apply it 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
> > > > > > (without that member's request or consent), 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 an email to the
> > board@
> > > > > > mailing list detailing the request for removal and the
> > justification the
> > > > > > PMC has for that removal, and copy the project's private@ list.
> > > > > >
> > > > > > END QUOTE
> > > > > >
> > > > > >
> > > > > > = Summary
> > > > > > I believe that Apache Pulsar has the responsibility with respect
> > to its
> > > > > > users to reflect the real number of people actively in the
> project
> > - its
> > > > > > PMC members.
> > > > >
> > > > > How would you do it consistently? How would you measure
> > disengagement?
> > > > >
> > > > > The only fair way would be to go through the exercise of measuring
> > actual
> > > > > engagement. Once you do I think that you will understand why it is
> > not
> > > > > really done.
> > > > >
> > > > > Best,
> > > > > Dave
> > > > >
> > > > >
> > > > >
> >
>

Re: [DISCUSS] PMC/Committer Emiratus status

[Asaf Mesika <as...@gmail.com>]

Thanks to everyone who took the time to carefully answer with detailed
explanations.
I personally learned a lot about Apache projects this way (made me read
about it some more).

So my personal recap is:

   - The goal of knowing the health of the Apache Pulsar community can be
   achieved by taking a look at monthly active contributors over time
   displayed on the community page.
      - It could be nice getting those numbers on the mailing list itself
      as well.
   - Calculating the engagement is not an easy task.
   - Kicking people off is not something you'd like to do in general and
   specifically for volunteers.
   - People's credit for work, which is also expressed in PMC membership
   never expires due to Merit never expires - your work credit and earned
   right should not expire.


I personally see PMC members answering someone not a PMC member nor a
comitter on this topic as a very healthy community indicator :)

Thanks !

Asaf

On Fri, Mar 3, 2023 at 10:22 AM Enrico Olivelli <eo...@gmail.com> wrote:

> This is an interesting discussion.
> Good to see this kind of a discussion on the dev@ mailing list, this
> way more people are aware of the fact that we are a project in the ASF
> and there is a Project Management Committee.
>
> I have been following a few Apache projects for a while, and I believe
> that this kind of discussions should be run on the private@ mailing
> list.
> It is the PMC that usually deals with this stuff.
>
> As Tison said, the common practice is that you never remove anyone
> from a PMC or from the Committers list.
>
> This happens only in rare cases where an individual behaves in such a
> way that the Project or the Foundation could be damaged,
> for instance if you speak on behalf of the project and you offend
> someone publicly.
>
> Inactive contributors/committers/PMC members do not do any harm to a
> project.
>
> Some projects have some rules that you cannot participate in official
> VOTEs if you are not "active".
>
> If anyone has some problems with someone in the community, then they
> can reach out to private@pulsar.apache.org and the PMC will listen to
> the problem and take actions.
>
> my 2 cents
>
> Enrico
>
> Il giorno ven 3 mar 2023 alle ore 04:39 Yunze Xu
> <yz...@streamnative.io.invalid> ha scritto:
> >
> > As a PMC member, I don't like playing a game of determining who should
> > be removed from PMC as well.
> >
> > I hear a viewpoint that someone is only participating in the community
> > only to join a PMC so that he can benefit from it. After becoming a
> > PMC member, he is never active in the community. It might be true but
> > I think it's acceptable. Making such a rule won't prevent such cases.
> > If he wants, he can make use of the rule and keep himself "active" to
> > avoid being kicked out of the PMC. Though the active state is fake.
> >
> > I'm not against the way to remove (or something else that sounds good)
> > a PMC member because none of these ways is perfect. However, I'm
> > STRONGLY AGAINST changing a rule that has been applied for some time
> > unless it can be proved the rule is very harmful to the community.
> > You mentioned https://www.apache.org/dev/pmc.html#pmc-removal. But
> > please don't ignore the first sentence:
> >
> > > Projects can establish their own policy on handling inactive members,
> as long as they apply it CONSISTENTLY.
> >
> > In addition, Dave and Tison both mentioned we have some boards or
> > webpages to see how many people are active. We don't need to remove
> > some PMC members just for knowing who were still active recently.
> >
> > BTW, I'm also curious about the motivation of this proposal. I'm
> > wondering how do the inactive PMC members harm the community?
> >
> > Thanks,
> > Yunze
> >
> > On Fri, Mar 3, 2023 at 10:14 AM tison <wa...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > In the proposal, it's unclear if you'd like to _mark_ the inactive
> members
> > > in emeritus status or _remove_ them from the LDAP group.
> > >
> > > I saw a similar discussion in the Flink community, resulting in
> "active"
> > > sentences in its Bylaws[1]. Here is some consensus there:
> > >
> > > 1. Merits never expire. There's no reason to _remove_ a committer or
> PMC
> > > member from the LDAP group because of inactive following the Apache
> way. I
> > > remember numbered cases a member got removed because they _keep_
> harming
> > > the community.
> > > 2. Emeritus status is set for unblocking consensus. The Flink community
> > > experienced some votes that could not get the required approvals in
> time
> > > and thus tried to unblock consensus by setting some members with
> binding
> > > votes in emeritus status. Do we spot concrete issues that the Pulsar
> > > community cannot work well with current PMC members and committers
> group?
> > > 3. Emeritus status is voluntary. I know that in other foundations, it
> can
> > > be judged or eagerly applied, but in ASF, we share a "Community of
> Peers"
> > > sense that everyone is a volunteer. They won't be "fired" because of
> "low
> > > productivity".
> > >
> > > > Gain real visibility into the health of the project in terms of real
> > > active PMC / Committers members.
> > >
> > > On the community page, we already have a monthly active contributor
> graph.
> > > It's an insight concept; I don't think we should _remove_ members for
> such
> > > a reason.
> > >
> > > > Have the alert threshold set correctly as to when it's time to start
> > > working on recruiting new PMC / Committers members
> > >
> > > Ditto. When working in the community, you will know what modules or
> repos
> > > lack participants. For example, I remember someone proposing to promote
> > > more committers working on Pulsar multilingual clients. It's not a
> reason
> > > for emeritus or removal.
> > >
> > > ---
> > >
> > > Generally, committers and PMC members have "Earned Authority" to be in
> the
> > > group. They share a high trust level, and I have numerous examples that
> > > returned members do outstanding work. If we don't have some critical
> issues
> > > to introduce an emeritus status, and such members do no harm, why do
> we set
> > > a bar if they return?
> > >
> > > Best,
> > > tison.
> > >
> > > [1] https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws
> > >
> > >
> > > Dave Fisher <wa...@apache.org> 于2023年3月3日周五 09:37写道：
> > >
> > > > Hi,
> > > >
> > > > > On Mar 2, 2023, at 11:58 AM, Asaf Mesika <as...@gmail.com>
> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Following the discussion I've started in Pulsar bi-weekly meetings.
> > > >
> > > > As I said when you brought this up, I don’t think it is a good idea,
> not a
> > > > good idea at all.
> > > >
> > > > > Projects can establish their own policy on handling inactive
> members, as
> > > > > long as they apply it consistently.
> > > >
> > > >
> > > > As a PMC member I have no desire to play a game of consistently
> tossing
> > > > PMC members who somehow haven’t met an engagement criteria. That is
> an
> > > > anti-pattern to building a community. It would be disruptive and time
> > > > consuming.
> > > >
> > > > >
> > > > > = The idea
> > > > > PMC and Committers members will transition into Emeritus status
> after X
> > > > > months of inactivity, or voluntarily.
> > > >
> > > > PMC members have the opportunity with or without this proposal to
> > > > voluntarily resign as PMC members with or without giving up their
> commit
> > > > bit.
> > > >
> > > > >
> > > > > = Why?
> > > > > - Gain real visibility into the health of the project in terms of
> real
> > > > > active PMC / Committers members.
> > > >
> > > > Here is an exercise. Generate activity reports to show criteria. We
> can
> > > > correlate between the rosters and all of our GitHub repositories.
> Also
> > > > Mailing lists and slack which only goes back 90 days. I would be
> better
> > > > persuaded if you did that to actually show and prove that there is a
> > > > problem. I think you will find that it is a large amount of effort
> with
> > > > little value in the end.
> > > >
> > > > > - Have the alert threshold set correctly as to when it's time to
> start
> > > > > working on recruiting new PMC / Committers members.
> > > >
> > > > Those two points are not coupled. We ARE ALWAYS be on the alert for
> new
> > > > committers and PMC Members. This PMC has been ACTIVE in recognizing
> many of
> > > > those who are deserving.
> > > >
> > > > Here are the Pulsar Board reports:
> > > > https://whimsy.apache.org/board/minutes/Pulsar
> > > >
> > > > >
> > > > > = Is there any precedence?
> > > > > Yes. A lot.
> > > > > Many CNCF projects do it.
> > > > > Many Apache projects do it.
> > > >
> > > > I’ve been on many PMC’s and I cannot think of one that does this.
> You’ve
> > > > come up with a few examples below, but I won’t be persuaded.
> > > >
> > > > > Apache foundations rules allow it.
> > > > >
> > > > > Read below to see examples and links.
> > > > >
> > > > >
> > > > > = Examples
> > > > >
> > > > > === etcD project <
> > > > https://github.com/etcd-io/etcd/blob/main/GOVERNANCE.md>
> > > >
> > > > I don’t care about how another Foundation does it.
> > > >
> > > > >
> > > > > Quote
> > > > >
> > > > > Life priorities, interests, and passions can change. Maintainers
> can
> > > > retire
> > > > > and move to the emeritus status
> > > > > <
> > > >
> https://github.com/etcd-io/etcd/blob/main/README.md#etcd-emeritus-maintainers
> > > > >.
> > > > > If a maintainer needs to step down, they should inform other
> maintainers,
> > > > > if possible, help find someone to pick up the related work. At the
> very
> > > > > least, ensure the related work can be continued. Afterward they can
> > > > remove
> > > > > themselves from list of existing maintainers.
> > > > >
> > > > > If a maintainer is not been performing their duties for period of
> 12
> > > > > months, they can be removed by other maintainers. In that case
> inactive
> > > > > maintainer will be first notified via an email. If situation
> doesn't
> > > > > improve, they will be removed. If an emeritus maintainer wants to
> regain
> > > > an
> > > > > active role, they can do so by renewing their contributions. Active
> > > > > maintainers should welcome such a move. Retiring of other
> maintainers or
> > > > > regaining the status should require approval of at least two active
> > > > > maintainers.
> > > > >
> > > > > === Apache Gump
> > > > > According to this link <https://gump.apache.org/bylaws.html>,
> they have
> > > > > emeritus status for maintainers and PMC members and policy to
> transition.
> > > >
> > > > Gump is a tiny project that does not release code. The two PMC
> members was
> > > > added in 2014. The rest were in 2004 - 2006. The project is a build
> system
> > > > that other projects used to use. I don’t even know if any project
> still
> > > > uses it. In fact that are just keeping it up for Tomcat. See
> > > > https://whimsy.apache.org/board/minutes/Gump
> > > >
> > > > >
> > > > > QUOTE
> > > > > Committer access is by invitation only and must be approved by lazy
> > > > > consensus of the active PMC members. A Committer is considered
> emeritus
> > > > by
> > > > > their own declaration or by not contributing in any form to the
> project
> > > > for
> > > > > over six months. An emeritus committer may request reinstatement of
> > > > commit
> > > > > access from the PMC. Such reinstatement is subject to lazy
> consensus of
> > > > > active PMC members.
> > > >
> > > > All of their committers except for on of 16 are ASF Members.
> > > >
> > > > >
> > > > > Membership of the PMC is by invitation only and must be approved
> by a
> > > > lazy
> > > > > consensus of active PMC members. A PMC member is considered
> "emeritus" by
> > > > > their own declaration or by not contributing in any form to the
> project
> > > > for
> > > > > over six months. An emeritus member may request reinstatement to
> the PMC.
> > > > > Such reinstatement is subject to lazy consensus of the active PMC
> > > > members.
> > > > > Membership of the PMC can be revoked by an unanimous vote of all
> the
> > > > active
> > > > > PMC members other than the member in question.
> > > > >
> > > > > END QUOTE
> > > > >
> > > > > There are many more: Apache Hive
> > > > > <
> > > >
> https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Committers
> > > > >,
> > > >
> > > > Hive has 56 PMC Members and 106 Committers. I can tell from their
> roster
> > > > that many do not seem to be engaged any more.
> > > >
> > > > Board reports: https://whimsy.apache.org/board/minutes/Hive
> > > >
> > > > > Apache Orc <
> > > > https://github.com/apache/orc/blob/main/site/develop/bylaws.md>,
> > > >
> > > > They are actively working to regrow, but I doubt they are kicking
> out many
> > > > PMC members. You could read their board reports:
> > > > https://whimsy.apache.org/board/minutes/ORC
> > > >
> > > > > ...
> > > > >
> > > > > = What does Apache thinks about this?
> > > > >
> > > > > According to this link <
> https://www.apache.org/dev/pmc.html#pmc-removal
> > > > >,
> > > > > any project can have their policies for retire an inactive PMC
> member.
> > > > >
> > > > > QUOTE
> > > > > SHOULD A PMC REMOVE INACTIVE MEMBERS?
> > > > > <https://www.apache.org/dev/pmc.html#pmc-removal>
> > > > >
> > > > > Projects can establish their own policy on handling inactive
> members, as
> > > > > long as they apply it 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
> > > > > (without that member's request or consent), 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 an email to the
> board@
> > > > > mailing list detailing the request for removal and the
> justification the
> > > > > PMC has for that removal, and copy the project's private@ list.
> > > > >
> > > > > END QUOTE
> > > > >
> > > > >
> > > > > = Summary
> > > > > I believe that Apache Pulsar has the responsibility with respect
> to its
> > > > > users to reflect the real number of people actively in the project
> - its
> > > > > PMC members.
> > > >
> > > > How would you do it consistently? How would you measure
> disengagement?
> > > >
> > > > The only fair way would be to go through the exercise of measuring
> actual
> > > > engagement. Once you do I think that you will understand why it is
> not
> > > > really done.
> > > >
> > > > Best,
> > > > Dave
> > > >
> > > >
> > > >
>

Re: [DISCUSS] PMC/Committer Emiratus status

[Enrico Olivelli <eo...@gmail.com>]

This is an interesting discussion.
Good to see this kind of a discussion on the dev@ mailing list, this
way more people are aware of the fact that we are a project in the ASF
and there is a Project Management Committee.

I have been following a few Apache projects for a while, and I believe
that this kind of discussions should be run on the private@ mailing
list.
It is the PMC that usually deals with this stuff.

As Tison said, the common practice is that you never remove anyone
from a PMC or from the Committers list.

This happens only in rare cases where an individual behaves in such a
way that the Project or the Foundation could be damaged,
for instance if you speak on behalf of the project and you offend
someone publicly.

Inactive contributors/committers/PMC members do not do any harm to a project.

Some projects have some rules that you cannot participate in official
VOTEs if you are not "active".

If anyone has some problems with someone in the community, then they
can reach out to private@pulsar.apache.org and the PMC will listen to
the problem and take actions.

my 2 cents

Enrico

Il giorno ven 3 mar 2023 alle ore 04:39 Yunze Xu
<yz...@streamnative.io.invalid> ha scritto:
>
> As a PMC member, I don't like playing a game of determining who should
> be removed from PMC as well.
>
> I hear a viewpoint that someone is only participating in the community
> only to join a PMC so that he can benefit from it. After becoming a
> PMC member, he is never active in the community. It might be true but
> I think it's acceptable. Making such a rule won't prevent such cases.
> If he wants, he can make use of the rule and keep himself "active" to
> avoid being kicked out of the PMC. Though the active state is fake.
>
> I'm not against the way to remove (or something else that sounds good)
> a PMC member because none of these ways is perfect. However, I'm
> STRONGLY AGAINST changing a rule that has been applied for some time
> unless it can be proved the rule is very harmful to the community.
> You mentioned https://www.apache.org/dev/pmc.html#pmc-removal. But
> please don't ignore the first sentence:
>
> > Projects can establish their own policy on handling inactive members, as long as they apply it CONSISTENTLY.
>
> In addition, Dave and Tison both mentioned we have some boards or
> webpages to see how many people are active. We don't need to remove
> some PMC members just for knowing who were still active recently.
>
> BTW, I'm also curious about the motivation of this proposal. I'm
> wondering how do the inactive PMC members harm the community?
>
> Thanks,
> Yunze
>
> On Fri, Mar 3, 2023 at 10:14 AM tison <wa...@gmail.com> wrote:
> >
> > Hi,
> >
> > In the proposal, it's unclear if you'd like to _mark_ the inactive members
> > in emeritus status or _remove_ them from the LDAP group.
> >
> > I saw a similar discussion in the Flink community, resulting in "active"
> > sentences in its Bylaws[1]. Here is some consensus there:
> >
> > 1. Merits never expire. There's no reason to _remove_ a committer or PMC
> > member from the LDAP group because of inactive following the Apache way. I
> > remember numbered cases a member got removed because they _keep_ harming
> > the community.
> > 2. Emeritus status is set for unblocking consensus. The Flink community
> > experienced some votes that could not get the required approvals in time
> > and thus tried to unblock consensus by setting some members with binding
> > votes in emeritus status. Do we spot concrete issues that the Pulsar
> > community cannot work well with current PMC members and committers group?
> > 3. Emeritus status is voluntary. I know that in other foundations, it can
> > be judged or eagerly applied, but in ASF, we share a "Community of Peers"
> > sense that everyone is a volunteer. They won't be "fired" because of "low
> > productivity".
> >
> > > Gain real visibility into the health of the project in terms of real
> > active PMC / Committers members.
> >
> > On the community page, we already have a monthly active contributor graph.
> > It's an insight concept; I don't think we should _remove_ members for such
> > a reason.
> >
> > > Have the alert threshold set correctly as to when it's time to start
> > working on recruiting new PMC / Committers members
> >
> > Ditto. When working in the community, you will know what modules or repos
> > lack participants. For example, I remember someone proposing to promote
> > more committers working on Pulsar multilingual clients. It's not a reason
> > for emeritus or removal.
> >
> > ---
> >
> > Generally, committers and PMC members have "Earned Authority" to be in the
> > group. They share a high trust level, and I have numerous examples that
> > returned members do outstanding work. If we don't have some critical issues
> > to introduce an emeritus status, and such members do no harm, why do we set
> > a bar if they return?
> >
> > Best,
> > tison.
> >
> > [1] https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws
> >
> >
> > Dave Fisher <wa...@apache.org> 于2023年3月3日周五 09:37写道：
> >
> > > Hi,
> > >
> > > > On Mar 2, 2023, at 11:58 AM, Asaf Mesika <as...@gmail.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Following the discussion I've started in Pulsar bi-weekly meetings.
> > >
> > > As I said when you brought this up, I don’t think it is a good idea, not a
> > > good idea at all.
> > >
> > > > Projects can establish their own policy on handling inactive members, as
> > > > long as they apply it consistently.
> > >
> > >
> > > As a PMC member I have no desire to play a game of consistently tossing
> > > PMC members who somehow haven’t met an engagement criteria. That is an
> > > anti-pattern to building a community. It would be disruptive and time
> > > consuming.
> > >
> > > >
> > > > = The idea
> > > > PMC and Committers members will transition into Emeritus status after X
> > > > months of inactivity, or voluntarily.
> > >
> > > PMC members have the opportunity with or without this proposal to
> > > voluntarily resign as PMC members with or without giving up their commit
> > > bit.
> > >
> > > >
> > > > = Why?
> > > > - Gain real visibility into the health of the project in terms of real
> > > > active PMC / Committers members.
> > >
> > > Here is an exercise. Generate activity reports to show criteria. We can
> > > correlate between the rosters and all of our GitHub repositories. Also
> > > Mailing lists and slack which only goes back 90 days. I would be better
> > > persuaded if you did that to actually show and prove that there is a
> > > problem. I think you will find that it is a large amount of effort with
> > > little value in the end.
> > >
> > > > - Have the alert threshold set correctly as to when it's time to start
> > > > working on recruiting new PMC / Committers members.
> > >
> > > Those two points are not coupled. We ARE ALWAYS be on the alert for new
> > > committers and PMC Members. This PMC has been ACTIVE in recognizing many of
> > > those who are deserving.
> > >
> > > Here are the Pulsar Board reports:
> > > https://whimsy.apache.org/board/minutes/Pulsar
> > >
> > > >
> > > > = Is there any precedence?
> > > > Yes. A lot.
> > > > Many CNCF projects do it.
> > > > Many Apache projects do it.
> > >
> > > I’ve been on many PMC’s and I cannot think of one that does this. You’ve
> > > come up with a few examples below, but I won’t be persuaded.
> > >
> > > > Apache foundations rules allow it.
> > > >
> > > > Read below to see examples and links.
> > > >
> > > >
> > > > = Examples
> > > >
> > > > === etcD project <
> > > https://github.com/etcd-io/etcd/blob/main/GOVERNANCE.md>
> > >
> > > I don’t care about how another Foundation does it.
> > >
> > > >
> > > > Quote
> > > >
> > > > Life priorities, interests, and passions can change. Maintainers can
> > > retire
> > > > and move to the emeritus status
> > > > <
> > > https://github.com/etcd-io/etcd/blob/main/README.md#etcd-emeritus-maintainers
> > > >.
> > > > If a maintainer needs to step down, they should inform other maintainers,
> > > > if possible, help find someone to pick up the related work. At the very
> > > > least, ensure the related work can be continued. Afterward they can
> > > remove
> > > > themselves from list of existing maintainers.
> > > >
> > > > If a maintainer is not been performing their duties for period of 12
> > > > months, they can be removed by other maintainers. In that case inactive
> > > > maintainer will be first notified via an email. If situation doesn't
> > > > improve, they will be removed. If an emeritus maintainer wants to regain
> > > an
> > > > active role, they can do so by renewing their contributions. Active
> > > > maintainers should welcome such a move. Retiring of other maintainers or
> > > > regaining the status should require approval of at least two active
> > > > maintainers.
> > > >
> > > > === Apache Gump
> > > > According to this link <https://gump.apache.org/bylaws.html>, they have
> > > > emeritus status for maintainers and PMC members and policy to transition.
> > >
> > > Gump is a tiny project that does not release code. The two PMC members was
> > > added in 2014. The rest were in 2004 - 2006. The project is a build system
> > > that other projects used to use. I don’t even know if any project still
> > > uses it. In fact that are just keeping it up for Tomcat. See
> > > https://whimsy.apache.org/board/minutes/Gump
> > >
> > > >
> > > > QUOTE
> > > > Committer access is by invitation only and must be approved by lazy
> > > > consensus of the active PMC members. A Committer is considered emeritus
> > > by
> > > > their own declaration or by not contributing in any form to the project
> > > for
> > > > over six months. An emeritus committer may request reinstatement of
> > > commit
> > > > access from the PMC. Such reinstatement is subject to lazy consensus of
> > > > active PMC members.
> > >
> > > All of their committers except for on of 16 are ASF Members.
> > >
> > > >
> > > > Membership of the PMC is by invitation only and must be approved by a
> > > lazy
> > > > consensus of active PMC members. A PMC member is considered "emeritus" by
> > > > their own declaration or by not contributing in any form to the project
> > > for
> > > > over six months. An emeritus member may request reinstatement to the PMC.
> > > > Such reinstatement is subject to lazy consensus of the active PMC
> > > members.
> > > > Membership of the PMC can be revoked by an unanimous vote of all the
> > > active
> > > > PMC members other than the member in question.
> > > >
> > > > END QUOTE
> > > >
> > > > There are many more: Apache Hive
> > > > <
> > > https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Committers
> > > >,
> > >
> > > Hive has 56 PMC Members and 106 Committers. I can tell from their roster
> > > that many do not seem to be engaged any more.
> > >
> > > Board reports: https://whimsy.apache.org/board/minutes/Hive
> > >
> > > > Apache Orc <
> > > https://github.com/apache/orc/blob/main/site/develop/bylaws.md>,
> > >
> > > They are actively working to regrow, but I doubt they are kicking out many
> > > PMC members. You could read their board reports:
> > > https://whimsy.apache.org/board/minutes/ORC
> > >
> > > > ...
> > > >
> > > > = What does Apache thinks about this?
> > > >
> > > > According to this link <https://www.apache.org/dev/pmc.html#pmc-removal
> > > >,
> > > > any project can have their policies for retire an inactive PMC member.
> > > >
> > > > QUOTE
> > > > SHOULD A PMC REMOVE INACTIVE MEMBERS?
> > > > <https://www.apache.org/dev/pmc.html#pmc-removal>
> > > >
> > > > Projects can establish their own policy on handling inactive members, as
> > > > long as they apply it 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
> > > > (without that member's request or consent), 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 an email to the board@
> > > > mailing list detailing the request for removal and the justification the
> > > > PMC has for that removal, and copy the project's private@ list.
> > > >
> > > > END QUOTE
> > > >
> > > >
> > > > = Summary
> > > > I believe that Apache Pulsar has the responsibility with respect to its
> > > > users to reflect the real number of people actively in the project - its
> > > > PMC members.
> > >
> > > How would you do it consistently? How would you measure disengagement?
> > >
> > > The only fair way would be to go through the exercise of measuring actual
> > > engagement. Once you do I think that you will understand why it is not
> > > really done.
> > >
> > > Best,
> > > Dave
> > >
> > >
> > >

Re: [DISCUSS] PMC/Committer Emiratus status

[Yunze Xu <yz...@streamnative.io.INVALID>]

As a PMC member, I don't like playing a game of determining who should
be removed from PMC as well.

I hear a viewpoint that someone is only participating in the community
only to join a PMC so that he can benefit from it. After becoming a
PMC member, he is never active in the community. It might be true but
I think it's acceptable. Making such a rule won't prevent such cases.
If he wants, he can make use of the rule and keep himself "active" to
avoid being kicked out of the PMC. Though the active state is fake.

I'm not against the way to remove (or something else that sounds good)
a PMC member because none of these ways is perfect. However, I'm
STRONGLY AGAINST changing a rule that has been applied for some time
unless it can be proved the rule is very harmful to the community.
You mentioned https://www.apache.org/dev/pmc.html#pmc-removal. But
please don't ignore the first sentence:

> Projects can establish their own policy on handling inactive members, as long as they apply it CONSISTENTLY.

In addition, Dave and Tison both mentioned we have some boards or
webpages to see how many people are active. We don't need to remove
some PMC members just for knowing who were still active recently.

BTW, I'm also curious about the motivation of this proposal. I'm
wondering how do the inactive PMC members harm the community?

Thanks,
Yunze

On Fri, Mar 3, 2023 at 10:14 AM tison <wa...@gmail.com> wrote:
>
> Hi,
>
> In the proposal, it's unclear if you'd like to _mark_ the inactive members
> in emeritus status or _remove_ them from the LDAP group.
>
> I saw a similar discussion in the Flink community, resulting in "active"
> sentences in its Bylaws[1]. Here is some consensus there:
>
> 1. Merits never expire. There's no reason to _remove_ a committer or PMC
> member from the LDAP group because of inactive following the Apache way. I
> remember numbered cases a member got removed because they _keep_ harming
> the community.
> 2. Emeritus status is set for unblocking consensus. The Flink community
> experienced some votes that could not get the required approvals in time
> and thus tried to unblock consensus by setting some members with binding
> votes in emeritus status. Do we spot concrete issues that the Pulsar
> community cannot work well with current PMC members and committers group?
> 3. Emeritus status is voluntary. I know that in other foundations, it can
> be judged or eagerly applied, but in ASF, we share a "Community of Peers"
> sense that everyone is a volunteer. They won't be "fired" because of "low
> productivity".
>
> > Gain real visibility into the health of the project in terms of real
> active PMC / Committers members.
>
> On the community page, we already have a monthly active contributor graph.
> It's an insight concept; I don't think we should _remove_ members for such
> a reason.
>
> > Have the alert threshold set correctly as to when it's time to start
> working on recruiting new PMC / Committers members
>
> Ditto. When working in the community, you will know what modules or repos
> lack participants. For example, I remember someone proposing to promote
> more committers working on Pulsar multilingual clients. It's not a reason
> for emeritus or removal.
>
> ---
>
> Generally, committers and PMC members have "Earned Authority" to be in the
> group. They share a high trust level, and I have numerous examples that
> returned members do outstanding work. If we don't have some critical issues
> to introduce an emeritus status, and such members do no harm, why do we set
> a bar if they return?
>
> Best,
> tison.
>
> [1] https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws
>
>
> Dave Fisher <wa...@apache.org> 于2023年3月3日周五 09:37写道：
>
> > Hi,
> >
> > > On Mar 2, 2023, at 11:58 AM, Asaf Mesika <as...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > Following the discussion I've started in Pulsar bi-weekly meetings.
> >
> > As I said when you brought this up, I don’t think it is a good idea, not a
> > good idea at all.
> >
> > > Projects can establish their own policy on handling inactive members, as
> > > long as they apply it consistently.
> >
> >
> > As a PMC member I have no desire to play a game of consistently tossing
> > PMC members who somehow haven’t met an engagement criteria. That is an
> > anti-pattern to building a community. It would be disruptive and time
> > consuming.
> >
> > >
> > > = The idea
> > > PMC and Committers members will transition into Emeritus status after X
> > > months of inactivity, or voluntarily.
> >
> > PMC members have the opportunity with or without this proposal to
> > voluntarily resign as PMC members with or without giving up their commit
> > bit.
> >
> > >
> > > = Why?
> > > - Gain real visibility into the health of the project in terms of real
> > > active PMC / Committers members.
> >
> > Here is an exercise. Generate activity reports to show criteria. We can
> > correlate between the rosters and all of our GitHub repositories. Also
> > Mailing lists and slack which only goes back 90 days. I would be better
> > persuaded if you did that to actually show and prove that there is a
> > problem. I think you will find that it is a large amount of effort with
> > little value in the end.
> >
> > > - Have the alert threshold set correctly as to when it's time to start
> > > working on recruiting new PMC / Committers members.
> >
> > Those two points are not coupled. We ARE ALWAYS be on the alert for new
> > committers and PMC Members. This PMC has been ACTIVE in recognizing many of
> > those who are deserving.
> >
> > Here are the Pulsar Board reports:
> > https://whimsy.apache.org/board/minutes/Pulsar
> >
> > >
> > > = Is there any precedence?
> > > Yes. A lot.
> > > Many CNCF projects do it.
> > > Many Apache projects do it.
> >
> > I’ve been on many PMC’s and I cannot think of one that does this. You’ve
> > come up with a few examples below, but I won’t be persuaded.
> >
> > > Apache foundations rules allow it.
> > >
> > > Read below to see examples and links.
> > >
> > >
> > > = Examples
> > >
> > > === etcD project <
> > https://github.com/etcd-io/etcd/blob/main/GOVERNANCE.md>
> >
> > I don’t care about how another Foundation does it.
> >
> > >
> > > Quote
> > >
> > > Life priorities, interests, and passions can change. Maintainers can
> > retire
> > > and move to the emeritus status
> > > <
> > https://github.com/etcd-io/etcd/blob/main/README.md#etcd-emeritus-maintainers
> > >.
> > > If a maintainer needs to step down, they should inform other maintainers,
> > > if possible, help find someone to pick up the related work. At the very
> > > least, ensure the related work can be continued. Afterward they can
> > remove
> > > themselves from list of existing maintainers.
> > >
> > > If a maintainer is not been performing their duties for period of 12
> > > months, they can be removed by other maintainers. In that case inactive
> > > maintainer will be first notified via an email. If situation doesn't
> > > improve, they will be removed. If an emeritus maintainer wants to regain
> > an
> > > active role, they can do so by renewing their contributions. Active
> > > maintainers should welcome such a move. Retiring of other maintainers or
> > > regaining the status should require approval of at least two active
> > > maintainers.
> > >
> > > === Apache Gump
> > > According to this link <https://gump.apache.org/bylaws.html>, they have
> > > emeritus status for maintainers and PMC members and policy to transition.
> >
> > Gump is a tiny project that does not release code. The two PMC members was
> > added in 2014. The rest were in 2004 - 2006. The project is a build system
> > that other projects used to use. I don’t even know if any project still
> > uses it. In fact that are just keeping it up for Tomcat. See
> > https://whimsy.apache.org/board/minutes/Gump
> >
> > >
> > > QUOTE
> > > Committer access is by invitation only and must be approved by lazy
> > > consensus of the active PMC members. A Committer is considered emeritus
> > by
> > > their own declaration or by not contributing in any form to the project
> > for
> > > over six months. An emeritus committer may request reinstatement of
> > commit
> > > access from the PMC. Such reinstatement is subject to lazy consensus of
> > > active PMC members.
> >
> > All of their committers except for on of 16 are ASF Members.
> >
> > >
> > > Membership of the PMC is by invitation only and must be approved by a
> > lazy
> > > consensus of active PMC members. A PMC member is considered "emeritus" by
> > > their own declaration or by not contributing in any form to the project
> > for
> > > over six months. An emeritus member may request reinstatement to the PMC.
> > > Such reinstatement is subject to lazy consensus of the active PMC
> > members.
> > > Membership of the PMC can be revoked by an unanimous vote of all the
> > active
> > > PMC members other than the member in question.
> > >
> > > END QUOTE
> > >
> > > There are many more: Apache Hive
> > > <
> > https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Committers
> > >,
> >
> > Hive has 56 PMC Members and 106 Committers. I can tell from their roster
> > that many do not seem to be engaged any more.
> >
> > Board reports: https://whimsy.apache.org/board/minutes/Hive
> >
> > > Apache Orc <
> > https://github.com/apache/orc/blob/main/site/develop/bylaws.md>,
> >
> > They are actively working to regrow, but I doubt they are kicking out many
> > PMC members. You could read their board reports:
> > https://whimsy.apache.org/board/minutes/ORC
> >
> > > ...
> > >
> > > = What does Apache thinks about this?
> > >
> > > According to this link <https://www.apache.org/dev/pmc.html#pmc-removal
> > >,
> > > any project can have their policies for retire an inactive PMC member.
> > >
> > > QUOTE
> > > SHOULD A PMC REMOVE INACTIVE MEMBERS?
> > > <https://www.apache.org/dev/pmc.html#pmc-removal>
> > >
> > > Projects can establish their own policy on handling inactive members, as
> > > long as they apply it 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
> > > (without that member's request or consent), 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 an email to the board@
> > > mailing list detailing the request for removal and the justification the
> > > PMC has for that removal, and copy the project's private@ list.
> > >
> > > END QUOTE
> > >
> > >
> > > = Summary
> > > I believe that Apache Pulsar has the responsibility with respect to its
> > > users to reflect the real number of people actively in the project - its
> > > PMC members.
> >
> > How would you do it consistently? How would you measure disengagement?
> >
> > The only fair way would be to go through the exercise of measuring actual
> > engagement. Once you do I think that you will understand why it is not
> > really done.
> >
> > Best,
> > Dave
> >
> >
> >

Re: [DISCUSS] PMC/Committer Emiratus status

[tison <wa...@gmail.com>]

Hi,

In the proposal, it's unclear if you'd like to _mark_ the inactive members
in emeritus status or _remove_ them from the LDAP group.

I saw a similar discussion in the Flink community, resulting in "active"
sentences in its Bylaws[1]. Here is some consensus there:

1. Merits never expire. There's no reason to _remove_ a committer or PMC
member from the LDAP group because of inactive following the Apache way. I
remember numbered cases a member got removed because they _keep_ harming
the community.
2. Emeritus status is set for unblocking consensus. The Flink community
experienced some votes that could not get the required approvals in time
and thus tried to unblock consensus by setting some members with binding
votes in emeritus status. Do we spot concrete issues that the Pulsar
community cannot work well with current PMC members and committers group?
3. Emeritus status is voluntary. I know that in other foundations, it can
be judged or eagerly applied, but in ASF, we share a "Community of Peers"
sense that everyone is a volunteer. They won't be "fired" because of "low
productivity".

> Gain real visibility into the health of the project in terms of real
active PMC / Committers members.

On the community page, we already have a monthly active contributor graph.
It's an insight concept; I don't think we should _remove_ members for such
a reason.

> Have the alert threshold set correctly as to when it's time to start
working on recruiting new PMC / Committers members

Ditto. When working in the community, you will know what modules or repos
lack participants. For example, I remember someone proposing to promote
more committers working on Pulsar multilingual clients. It's not a reason
for emeritus or removal.

---

Generally, committers and PMC members have "Earned Authority" to be in the
group. They share a high trust level, and I have numerous examples that
returned members do outstanding work. If we don't have some critical issues
to introduce an emeritus status, and such members do no harm, why do we set
a bar if they return?

Best,
tison.

[1] https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws


Dave Fisher <wa...@apache.org> 于2023年3月3日周五 09:37写道：

> Hi,
>
> > On Mar 2, 2023, at 11:58 AM, Asaf Mesika <as...@gmail.com> wrote:
> >
> > Hi,
> >
> > Following the discussion I've started in Pulsar bi-weekly meetings.
>
> As I said when you brought this up, I don’t think it is a good idea, not a
> good idea at all.
>
> > Projects can establish their own policy on handling inactive members, as
> > long as they apply it consistently.
>
>
> As a PMC member I have no desire to play a game of consistently tossing
> PMC members who somehow haven’t met an engagement criteria. That is an
> anti-pattern to building a community. It would be disruptive and time
> consuming.
>
> >
> > = The idea
> > PMC and Committers members will transition into Emeritus status after X
> > months of inactivity, or voluntarily.
>
> PMC members have the opportunity with or without this proposal to
> voluntarily resign as PMC members with or without giving up their commit
> bit.
>
> >
> > = Why?
> > - Gain real visibility into the health of the project in terms of real
> > active PMC / Committers members.
>
> Here is an exercise. Generate activity reports to show criteria. We can
> correlate between the rosters and all of our GitHub repositories. Also
> Mailing lists and slack which only goes back 90 days. I would be better
> persuaded if you did that to actually show and prove that there is a
> problem. I think you will find that it is a large amount of effort with
> little value in the end.
>
> > - Have the alert threshold set correctly as to when it's time to start
> > working on recruiting new PMC / Committers members.
>
> Those two points are not coupled. We ARE ALWAYS be on the alert for new
> committers and PMC Members. This PMC has been ACTIVE in recognizing many of
> those who are deserving.
>
> Here are the Pulsar Board reports:
> https://whimsy.apache.org/board/minutes/Pulsar
>
> >
> > = Is there any precedence?
> > Yes. A lot.
> > Many CNCF projects do it.
> > Many Apache projects do it.
>
> I’ve been on many PMC’s and I cannot think of one that does this. You’ve
> come up with a few examples below, but I won’t be persuaded.
>
> > Apache foundations rules allow it.
> >
> > Read below to see examples and links.
> >
> >
> > = Examples
> >
> > === etcD project <
> https://github.com/etcd-io/etcd/blob/main/GOVERNANCE.md>
>
> I don’t care about how another Foundation does it.
>
> >
> > Quote
> >
> > Life priorities, interests, and passions can change. Maintainers can
> retire
> > and move to the emeritus status
> > <
> https://github.com/etcd-io/etcd/blob/main/README.md#etcd-emeritus-maintainers
> >.
> > If a maintainer needs to step down, they should inform other maintainers,
> > if possible, help find someone to pick up the related work. At the very
> > least, ensure the related work can be continued. Afterward they can
> remove
> > themselves from list of existing maintainers.
> >
> > If a maintainer is not been performing their duties for period of 12
> > months, they can be removed by other maintainers. In that case inactive
> > maintainer will be first notified via an email. If situation doesn't
> > improve, they will be removed. If an emeritus maintainer wants to regain
> an
> > active role, they can do so by renewing their contributions. Active
> > maintainers should welcome such a move. Retiring of other maintainers or
> > regaining the status should require approval of at least two active
> > maintainers.
> >
> > === Apache Gump
> > According to this link <https://gump.apache.org/bylaws.html>, they have
> > emeritus status for maintainers and PMC members and policy to transition.
>
> Gump is a tiny project that does not release code. The two PMC members was
> added in 2014. The rest were in 2004 - 2006. The project is a build system
> that other projects used to use. I don’t even know if any project still
> uses it. In fact that are just keeping it up for Tomcat. See
> https://whimsy.apache.org/board/minutes/Gump
>
> >
> > QUOTE
> > Committer access is by invitation only and must be approved by lazy
> > consensus of the active PMC members. A Committer is considered emeritus
> by
> > their own declaration or by not contributing in any form to the project
> for
> > over six months. An emeritus committer may request reinstatement of
> commit
> > access from the PMC. Such reinstatement is subject to lazy consensus of
> > active PMC members.
>
> All of their committers except for on of 16 are ASF Members.
>
> >
> > Membership of the PMC is by invitation only and must be approved by a
> lazy
> > consensus of active PMC members. A PMC member is considered "emeritus" by
> > their own declaration or by not contributing in any form to the project
> for
> > over six months. An emeritus member may request reinstatement to the PMC.
> > Such reinstatement is subject to lazy consensus of the active PMC
> members.
> > Membership of the PMC can be revoked by an unanimous vote of all the
> active
> > PMC members other than the member in question.
> >
> > END QUOTE
> >
> > There are many more: Apache Hive
> > <
> https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Committers
> >,
>
> Hive has 56 PMC Members and 106 Committers. I can tell from their roster
> that many do not seem to be engaged any more.
>
> Board reports: https://whimsy.apache.org/board/minutes/Hive
>
> > Apache Orc <
> https://github.com/apache/orc/blob/main/site/develop/bylaws.md>,
>
> They are actively working to regrow, but I doubt they are kicking out many
> PMC members. You could read their board reports:
> https://whimsy.apache.org/board/minutes/ORC
>
> > ...
> >
> > = What does Apache thinks about this?
> >
> > According to this link <https://www.apache.org/dev/pmc.html#pmc-removal
> >,
> > any project can have their policies for retire an inactive PMC member.
> >
> > QUOTE
> > SHOULD A PMC REMOVE INACTIVE MEMBERS?
> > <https://www.apache.org/dev/pmc.html#pmc-removal>
> >
> > Projects can establish their own policy on handling inactive members, as
> > long as they apply it 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
> > (without that member's request or consent), 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 an email to the board@
> > mailing list detailing the request for removal and the justification the
> > PMC has for that removal, and copy the project's private@ list.
> >
> > END QUOTE
> >
> >
> > = Summary
> > I believe that Apache Pulsar has the responsibility with respect to its
> > users to reflect the real number of people actively in the project - its
> > PMC members.
>
> How would you do it consistently? How would you measure disengagement?
>
> The only fair way would be to go through the exercise of measuring actual
> engagement. Once you do I think that you will understand why it is not
> really done.
>
> Best,
> Dave
>
>
>

Re: [DISCUSS] PMC/Committer Emiratus status

[Dave Fisher <wa...@apache.org>]

Hi,

> On Mar 2, 2023, at 11:58 AM, Asaf Mesika <as...@gmail.com> wrote:
> 
> Hi,
> 
> Following the discussion I've started in Pulsar bi-weekly meetings.

As I said when you brought this up, I don’t think it is a good idea, not a good idea at all.

> Projects can establish their own policy on handling inactive members, as
> long as they apply it consistently.


As a PMC member I have no desire to play a game of consistently tossing PMC members who somehow haven’t met an engagement criteria. That is an anti-pattern to building a community. It would be disruptive and time consuming.

> 
> = The idea
> PMC and Committers members will transition into Emeritus status after X
> months of inactivity, or voluntarily.

PMC members have the opportunity with or without this proposal to voluntarily resign as PMC members with or without giving up their commit bit.

> 
> = Why?
> - Gain real visibility into the health of the project in terms of real
> active PMC / Committers members.

Here is an exercise. Generate activity reports to show criteria. We can correlate between the rosters and all of our GitHub repositories. Also Mailing lists and slack which only goes back 90 days. I would be better persuaded if you did that to actually show and prove that there is a problem. I think you will find that it is a large amount of effort with little value in the end.

> - Have the alert threshold set correctly as to when it's time to start
> working on recruiting new PMC / Committers members.

Those two points are not coupled. We ARE ALWAYS be on the alert for new committers and PMC Members. This PMC has been ACTIVE in recognizing many of those who are deserving.

Here are the Pulsar Board reports: https://whimsy.apache.org/board/minutes/Pulsar

> 
> = Is there any precedence?
> Yes. A lot.
> Many CNCF projects do it.
> Many Apache projects do it.

I’ve been on many PMC’s and I cannot think of one that does this. You’ve come up with a few examples below, but I won’t be persuaded.

> Apache foundations rules allow it.
> 
> Read below to see examples and links.
> 
> 
> = Examples
> 
> === etcD project <https://github.com/etcd-io/etcd/blob/main/GOVERNANCE.md>

I don’t care about how another Foundation does it.

> 
> Quote
> 
> Life priorities, interests, and passions can change. Maintainers can retire
> and move to the emeritus status
> <https://github.com/etcd-io/etcd/blob/main/README.md#etcd-emeritus-maintainers>.
> If a maintainer needs to step down, they should inform other maintainers,
> if possible, help find someone to pick up the related work. At the very
> least, ensure the related work can be continued. Afterward they can remove
> themselves from list of existing maintainers.
> 
> If a maintainer is not been performing their duties for period of 12
> months, they can be removed by other maintainers. In that case inactive
> maintainer will be first notified via an email. If situation doesn't
> improve, they will be removed. If an emeritus maintainer wants to regain an
> active role, they can do so by renewing their contributions. Active
> maintainers should welcome such a move. Retiring of other maintainers or
> regaining the status should require approval of at least two active
> maintainers.
> 
> === Apache Gump
> According to this link <https://gump.apache.org/bylaws.html>, they have
> emeritus status for maintainers and PMC members and policy to transition.

Gump is a tiny project that does not release code. The two PMC members was added in 2014. The rest were in 2004 - 2006. The project is a build system that other projects used to use. I don’t even know if any project still uses it. In fact that are just keeping it up for Tomcat. See https://whimsy.apache.org/board/minutes/Gump

> 
> QUOTE
> Committer access is by invitation only and must be approved by lazy
> consensus of the active PMC members. A Committer is considered emeritus by
> their own declaration or by not contributing in any form to the project for
> over six months. An emeritus committer may request reinstatement of commit
> access from the PMC. Such reinstatement is subject to lazy consensus of
> active PMC members.

All of their committers except for on of 16 are ASF Members.

> 
> Membership of the PMC is by invitation only and must be approved by a lazy
> consensus of active PMC members. A PMC member is considered "emeritus" by
> their own declaration or by not contributing in any form to the project for
> over six months. An emeritus member may request reinstatement to the PMC.
> Such reinstatement is subject to lazy consensus of the active PMC members.
> Membership of the PMC can be revoked by an unanimous vote of all the active
> PMC members other than the member in question.
> 
> END QUOTE
> 
> There are many more: Apache Hive
> <https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Committers>,

Hive has 56 PMC Members and 106 Committers. I can tell from their roster that many do not seem to be engaged any more.

Board reports: https://whimsy.apache.org/board/minutes/Hive

> Apache Orc <https://github.com/apache/orc/blob/main/site/develop/bylaws.md>,

They are actively working to regrow, but I doubt they are kicking out many PMC members. You could read their board reports: https://whimsy.apache.org/board/minutes/ORC

> ...
> 
> = What does Apache thinks about this?
> 
> According to this link <https://www.apache.org/dev/pmc.html#pmc-removal>,
> any project can have their policies for retire an inactive PMC member.
> 
> QUOTE
> SHOULD A PMC REMOVE INACTIVE MEMBERS?
> <https://www.apache.org/dev/pmc.html#pmc-removal>
> 
> Projects can establish their own policy on handling inactive members, as
> long as they apply it 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
> (without that member's request or consent), 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 an email to the board@
> mailing list detailing the request for removal and the justification the
> PMC has for that removal, and copy the project's private@ list.
> 
> END QUOTE
> 
> 
> = Summary
> I believe that Apache Pulsar has the responsibility with respect to its
> users to reflect the real number of people actively in the project - its
> PMC members.

How would you do it consistently? How would you measure disengagement?

The only fair way would be to go through the exercise of measuring actual engagement. Once you do I think that you will understand why it is not really done.

Best,
Dave

Re: [DISCUSS] PMC/Committer Emiratus status

["P. Taylor Goetz" <pt...@gmail.com>]

I would proceed carefully with this, and would recommend against removing PMC members who are “inactive”. Rather, I would recommend a project-level “active/inactive” flag that PMC members can voluntarily apply to themselves. For example, do a PMC roll call on private@pulsar.a.o <ma...@pulsar.a.o> and ask whether current PMC members self describe as “active” or “inactive”. That status could then be reflected on the Community section of the pulsar website. No reply from a PMC member? Mark them inactive until they request a change.

Yes, some Apache projects do purge PMCs of “inactive” members, which in my opinion is a mistake. Another mantra offered by the Apache Way is that merit never expires. 

For example, in my case I’m not particularly active in terms of code contributions, etc., but as a former mentor to the project I keep an eye on the mailing lists to make sure any potential problems get addressed, etc. I would consider myself “active” even though I’m relatively quiet.

So to summarize:

1. You can maintain active/inactive status at the project level with a simple flag on a community page, without removing people from the PMC.
2. By making it an informal, self-reported flag, you avoid the overhead of board resolutions, etc. and just manage it at the community level. If someone wants to change their status, they can just say so or submit a pull request to change their status on the pulsar website.
3. Merit doesn’t expire.
4. Purging inactive PMC members unnecessarily adds work for the PMC, Chair,  and ASF board.

Finally, there’s nothing wrong with having a large PMC even if a significant number are “inactive”. I’ve recently witnessed on ASF project avoid the attic because several PMC members who had been quiet for years showed up and voted. Had that project purged those “inactive” PMC members it would have potentially died in the Attic as a result.

Just my $.02. Ultimately the decision is up to the broader Pulsar community to make a decision.

-Taylor



> On Mar 2, 2023, at 2:58 PM, Asaf Mesika <as...@gmail.com> wrote:
> 
> Hi,
> 
> Following the discussion I've started in Pulsar bi-weekly meetings.
> 
> = The idea
> PMC and Committers members will transition into Emeritus status after X
> months of inactivity, or voluntarily.
> 
> = Why?
> - Gain real visibility into the health of the project in terms of real
> active PMC / Committers members.
> - Have the alert threshold set correctly as to when it's time to start
> working on recruiting new PMC / Committers members.
> 
> = Is there any precedence?
> Yes. A lot.
> Many CNCF projects do it.
> Many Apache projects do it.
> Apache foundations rules allow it.
> 
> Read below to see examples and links.
> 
> 
> = Examples
> 
> === etcD project <https://github.com/etcd-io/etcd/blob/main/GOVERNANCE.md>
> 
> Quote
> 
> Life priorities, interests, and passions can change. Maintainers can retire
> and move to the emeritus status
> <https://github.com/etcd-io/etcd/blob/main/README.md#etcd-emeritus-maintainers>.
> If a maintainer needs to step down, they should inform other maintainers,
> if possible, help find someone to pick up the related work. At the very
> least, ensure the related work can be continued. Afterward they can remove
> themselves from list of existing maintainers.
> 
> If a maintainer is not been performing their duties for period of 12
> months, they can be removed by other maintainers. In that case inactive
> maintainer will be first notified via an email. If situation doesn't
> improve, they will be removed. If an emeritus maintainer wants to regain an
> active role, they can do so by renewing their contributions. Active
> maintainers should welcome such a move. Retiring of other maintainers or
> regaining the status should require approval of at least two active
> maintainers.
> 
> === Apache Gump
> According to this link <https://gump.apache.org/bylaws.html>, they have
> emeritus status for maintainers and PMC members and policy to transition.
> 
> QUOTE
> Committer access is by invitation only and must be approved by lazy
> consensus of the active PMC members. A Committer is considered emeritus by
> their own declaration or by not contributing in any form to the project for
> over six months. An emeritus committer may request reinstatement of commit
> access from the PMC. Such reinstatement is subject to lazy consensus of
> active PMC members.
> 
> Membership of the PMC is by invitation only and must be approved by a lazy
> consensus of active PMC members. A PMC member is considered "emeritus" by
> their own declaration or by not contributing in any form to the project for
> over six months. An emeritus member may request reinstatement to the PMC.
> Such reinstatement is subject to lazy consensus of the active PMC members.
> Membership of the PMC can be revoked by an unanimous vote of all the active
> PMC members other than the member in question.
> 
> END QUOTE
> 
> There are many more: Apache Hive
> <https://cwiki.apache.org/confluence/display/Hive/Bylaws#Bylaws-Committers>,
> Apache Orc <https://github.com/apache/orc/blob/main/site/develop/bylaws.md>,
> ...
> 
> = What does Apache thinks about this?
> 
> According to this link <https://www.apache.org/dev/pmc.html#pmc-removal>,
> any project can have their policies for retire an inactive PMC member.
> 
> QUOTE
> SHOULD A PMC REMOVE INACTIVE MEMBERS?
> <https://www.apache.org/dev/pmc.html#pmc-removal>
> 
> Projects can establish their own policy on handling inactive members, as
> long as they apply it 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
> (without that member's request or consent), 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 an email to the board@
> mailing list detailing the request for removal and the justification the
> PMC has for that removal, and copy the project's private@ list.
> 
> END QUOTE
> 
> 
> = Summary
> I believe that Apache Pulsar has the responsibility with respect to its
> users to reflect the real number of people actively in the project - its
> PMC members.