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 <mailto:private@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 <asaf.mes...@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.
