SIP-79: Guidelines for Superset PMC Membership

[SIP-79] Guidelines for Superset PMC Membership

Motivation

Superset wants to promote the growth and sustainability of a vibrant PMC (Project Management Committee) for the Apache Superset project. To this end, we need to create a set of standards to help act as an onramp/guideline for nominating top participants from the project’s Committer roster into the PMC.

Similarly, we need to standardize how we gauge any given PMC member’s absence or inactivity on the project and consider the conditions under which they may be removed from the PMC (retaining their Committer access). As per Apache guidelines, it’s worth nothing that merit is for life, and while committership is essentially for life (certain restrictions may apply), PMC members should uphold reasonable expectations of ongoing involvement, and these expectations should be upheld consistently across all members.

Proposed Change

With the passage of this SIP, these standards will be published on the Superset Wiki, and referred to as necessary. If adjustments are to be made to these in the future, they should be proposed on the dev@ list for lazy consensus before making changes on the Wiki. If lazy consensus cannot be easily reached, a subsequent SIP may be proposed/voted.

New or Changed Public Interfaces

N/A

New dependencies

N/A

Migration Plan and Compatibility

Standing Committers may be audited and gauged against these standards, and new nominations may be proposed/voted on the private@ list. Existing PMC members may also be gauged according to these standards, and a VOTE may be held to remove them from the PMC.

Rejected Alternatives

Not having published or consistent standards.

---

Proposal:

Guidelines for promoting Committers to Superset PMC

To become a PMC member the committers should meet all general prerequisites. Apart from that the person should demonstrate distinct community involvement or code contributions. When putting someone up for a vote, these attributes (or any special exemptions thereof) should be noted in the nomination email.

General prerequisites (required):

• Has been a committer for at least 3 months
• Has remained an active community member, and has voiced or demonstrated an intent for ongoing engagement

Community involvement (preferred):

• Visibility in discussions on the dev mailing list, Slack workspace, and/or GitHub
• Spreading the word about “Superset” via:
  • Talks at meetups, conferences, etc
  • Creating content (videos, blogs etc)
• Growing and supporting the community:
  • Mentors new members/contributors
  • Answers users/contributors via Github discussions, dev list or Slack
  • Actively filing/supporting/triaging/resolving Github Issues

Code contribution (preferred):

• Consistent voting on RCs for at least past 3 releases lifecycles
• Engagement in Superset Improvement Proposals (SIPs) by either:
  • Actively voting on SIPs
  • Proposing and/or leading their implementation
• Actively involved in code contributions:
  • Code reviews
  • Merging pull requests
  • Fixing bugs and implementing improvements

Guidelines for removing Committers from the Superset PMC

As per Apache guidelines, a PMC may have a process of removing inactive members, as long as that standard is applied consistently. Using the above standards for becoming a PMC member as a baseline, the following standards and process are hereby proposed for removing inactive members from the Superset PMC.

• General requirements (meeting none of these will be considered grounds for removal)
  • Active contribution to the codebase within the last 6 months
  • Active in discussions on the dev mailing list, Slack workspace, and/or GitHub
  • Active in testing and voting on RCs within the past 3 release lifecycles
  • Actively involved in reviewing/merging pull requests or triaging/labeling/supporting Github Issues

If a PMC member is deemed fit for removal, the PMC shall make best efforts to contact them by email and other means (Slack, etc) and allow a minimum of 72 hours for them to make a case to the PMC (via the private@ list) to remain on the PMC. Any such request will be considered a request for lazy consensus to remain on the PMC. If such consensus can not be reached, a [VOTE] thread to remove the person shall be held. If no response contesting removal is received in the alloted 72 hour timeframe, they shall be removed, with the possibility of being reinstated at a later date by a new (re)nomination and [VOTE] thread.

PMC membership shall be audited annually, but may be audited up to once per quarter. This quarterly limit will allow people to have an adequate window to demonstrate engagement/participation in response to any pending removal actions. When an audit of the PMC has taken place, the auditor(s) shall notify the private@ list that the audit took place (excluding any names/status of those being audited) so that the timing/cadence is known by all.

---

Credit: Partially adapted from Airflow PMC Guidelines available here.

[villebro]

I really like this! I wonder if we should make the PMC cleanup an annually recurring task? If there’s no process in place for it, I assume it will probably never happen in practice. Also, maybe members members that are flagged for removal should be notified so that they can make a case for inclusion, despite inactivity (I’m thinking parental leave or other good reason for being temporarily inactive).

Finally, should we also make a similar guideline for committership, with a similar cleanup process? AFAIK there are already some informal guidelines for becoming a committer, but it would be good to formalize that process to make it clear what the requirements are for those who want to step up their role in the project.

[rusackas]

Earned Authority: all individuals are given the opportunity to participate, but their influence is based on publicly earned merit – what they contribute to the community. Merit lies with the individual, does not expire, is not influenced by employment status or employer, and is non-transferable (merit earned in one project cannot be applied to another).

Per Apache docs, “Projects can establish their own policy on handling inactive members, as long as they apply it consistently.”

So, while I understand the desire to keep the PMC and committer pool populated with active members, I really don’t see the harm in allowing people to take a hiatus and return when they so desire. There’s no limit to PMC members and as long as someone isn’t detracting from the project, I really don’t think this is necessary at all.

I don’t think this flies in the face of the Apache Way, but rather conforms to it by attempting to establish a consistent bar.

The proposal also outlines a process in which if a member is deemed inactive, we simply reach out to them… then if they reply that they’re still interested, it’s assumed (via lazy consensus) that they’ll retain their membership. Basically, they just have to respond “yes” to that email and it’s over.

So, -1 from me. (non-binding)

It’s still in the discussion phase, but we’ll be opening a vote soon on the dev@ list.

In the meantime, I’m curious if there are any changes that would mitigate your concern… perhaps:

• Changing the maximum cadence of the audit to be annual? Then people only have to reply to the email defending their status once a year.
• Adding an email template or other further elaboration on the removal?
• Creating an easier process for prior members to re-enter the PMC in the event of a lapse, since indeed, merit never expires?

Also, I think the idea of using this to onramp PMC members is perhaps more important than the (albeit more controversial/complex) inactivity auditing process.