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 <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. End Quote On Mon, Mar 6, 2023 at 6:13 PM tison <wander4...@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 <asaf.mes...@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 <wander4...@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.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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
