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