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.mes...@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 <eolive...@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 priv...@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 > > <y...@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 <wander4...@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 <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 > > > > > > > > > > > > > > > > > >
