[SIP-DRAFT] process and automation workflows around SIPs

Motivation

As AI proliferates, we're seeing more and more large features opened (and merged) quickly, without community input, or even awareness. While it's great that our project is moving quickly, we need to give people a chance to weigh in before the project accepts a new pattern or maintenance burden.

We hereby propose a few additional processes to make this process more transparent and smooth.

Proposed Change

Process Changes

  • Respect the hold!:sip label. During PR review, any Committer or PMC member can call out a single PR with this label, as a request for a SIP. This will block the PR from merging until sufficient consensus (lazy consensus or a SIP) can be reached on the mailing list.

Automation enhancements

  • Detect Feature Flag additions/changes - all of these require multiple major version releases to complete their lifecycle, and add combinatoric complexity to testing/maintaining feature flag combinations. While the debate ensues about whether or not development-lifecycle feature flags remains to be settled, we propose that ALL feature flag changes should require consensus. This can be automated by checking the committed files and adding the hold!:sip label to a PR, and even adding a comment that a SIP is required accordingly.

New or Changed Public Interfaces

Describe any new additions to the model, views or REST endpoints. Describe any changes to existing visualizations, dashboards and React components. Describe changes that affect the Superset CLI and how Superset is deployed.

New dependencies

None, just some bot/CI work

Migration Plan and Compatibility

None

Rejected Alternatives

Wild west