Hi, > On Mar 2, 2023, at 11:58 AM, Asaf Mesika <asaf.mes...@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
