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 <w...@apache.org> 于2023年3月3日周五 09:37写道： > 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 > > >
