Stepping back slightly, this thread started with a desire to: > Gain real visibility into the health of the project in terms of real > active PMC / Committers members.
What if instead we ask how we as a community can show prospective and new users that Apache Pulsar is a healthy project? For me, when I first came to the Pulsar project, I didn't know anything about The Apache Way, and I didn't know what a PMC was. Instead, I thought the project seemed healthy because the tech was exciting and when I opened GitHub issues, people who made many contributions to the project answered my questions and helped me start making my own contributions. Each person will judge project health differently. Our goal could be to identify key ways that Pulsar is healthy and showcase those. We could also identify ways that we have room to grow and discuss improving those on this list. Some potentially meaningful measures of project health: accuracy and helpfulness of documentation, release frequency, number of emails on the mailing list, number of new committers/PMC members, number of commits, time to first response on an opened GitHub issue/discussion/pr, time to remediate security vulnerabilities, successful upgrades with no surprises, and the list goes on. In my experience, the user touch points like documentation and responsiveness to questions matter most to users. If we find that user issues/discussions are not getting feedback quickly enough, perhaps it would be interesting to coordinate among contributors times where a specific person volunteers to triage GitHub issues and discussions. That could help lighten the load on some of the main contributors that handle these tasks all of the time, while also giving contributors a chance to gain experience in the project and build merit in the project. In response to the original proposal, I am not in favor of adding active/inactive flags to PMC members and committers. Ultimately, I think there are better ways to show our users that we have a healthy project. Thanks, Michael On Thu, Mar 9, 2023 at 3:22 AM Asaf Mesika <asaf.mes...@gmail.com> wrote: > > Enrico, I was referring to this part of the quote: > > 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. > > The idea P. Taylor Goetz offered would be a yearly "chore" done by the PMC > chair, helped by PMC members, to "poll" that status, verify it, and if all > is verified, voted upon, then the website updated. > In that suggestion, the website wouldn't rot, no? > PMC membership / committer membership don't expire in that suggestion. > > On Tue, Mar 7, 2023 at 1:37 PM Enrico Olivelli <eolive...@gmail.com> wrote: > > > Il giorno lun 6 mar 2023 alle ore 23:12 Asaf Mesika > > <asaf.mes...@gmail.com> ha scritto: > > > > > > 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. > > > > Websites tend to quickly become obsolete about this kind of thing, > > because really > > nobody takes care of its own "status" on a project, or that it is > > "visible" on the website. > > It is not for the benefit of anyone. > > > > Also when you become "inactive" you are for sure not interested in > > updating the website, because you slowly > > lose interest in the project :-) > > > > Everybody (should) participate as an individual, what's the benefit of > > having you listed on the website ? > > > > I really remember the first time I was invited as a committer in an > > ASF, I felt really proud of myself, > > and also seeing myself listed in the main pom.xml of the project or in > > the list of committers was cool. > > So this is great for new contributors or in order to praise the > > efforts of someone who spent so much > > time in the community in order to be asked to join the group of people > > responsible for the project. > > > > But after some time, when you participate in an OSS community, and you > > really care about the project, > > you don't care if you are listed here or there. > > > > Regarding the "themes" on which someone could be "more expert" or not. > > This is also a piece of information that becomes obsolete. > > The community is dynamic, people who "knew" well something in the past > > but maybe they are no more up-to-date now. > > > > What's the goal ? To say Foo Bar is the "Pulsar Schema Registry expert" ? > > > > Personally I won't feel good to say that I am "the" expert for X, Y, > > Z, even if there are a few places in which I have spent > > days of work and I made substantial contributions (or new features > > initially contributed by myself). > > > > If you want to reach out to someone expert on a piece of code you use > > the GH UI and see the latest commits (of "git log") > > or search into the mailing list archives or in the GH issues and you > > will find the same names around a given topic. > > > > For Pulsar this is the OFFICIAL page of the folks that are > > "responsible" for the project > > https://people.apache.org/phonebook.html?pmc=pulsar > > > > If you really want to see who are the all the ASF committers you can > > always go here > > https://people.apache.org/committer-index.html > > > > If we want to list the PMC members/committers I suggest building > > something automated that simply shows the list. > > > > > > Enrico > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
