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