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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
