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