I have found this interesting reading about this topic https://www.apache.org/dev/pmc.html#pmc-removal
Quoting it here: "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." So basically if we ever wanted to remove someone we have to deal with the ASF board and explain the reasons for it. I have been around for a few years in the ASF and I have seen PMC members removed only for very strong cases and not due to "inactive" status Enrico Il giorno ven 10 mar 2023 alle ore 06:52 Michael Marshall <mmarsh...@apache.org> ha scritto: > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
