Guidelines for promoting Superset Committers to the 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 six months
  • Active in discussions on the dev mailing list, Slack workspace, and/or GitHub within the last six months
  • Active in testing and voting on RCs within the past three release lifecycles
  • Actively involved in reviewing/merging pull requests or triaging/labeling/supporting GitHub Issues within the last six months

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 send an email to the PMC (via the private@ list) asking to remain on the PMC. Any such request will be considered a request for lazy consensus to remain on the PMC. If lazy consensus to remain can not be reached, a [VOTE] thread to remove the person shall be held. If no response contesting removal is received in the allotted 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.

Onboarding/Offboarding PMC members

When onboarding or offboarding a PMC member, they will gain or lose access to related platforms accordingly. Examples of such access may include:

• Apache [email protected] email list
• 1Password vaults
• Private Slack channels (prefixed with pmc-
• Security-related tooling (e.g. Trello)

---

History: Proposed as SIP-79 and voted in here

Credit: Partially adapted from Airflow PMC Guidelines available here.