[SIP-100] Procedure for tracking status and implementation of Superset Improvement Proposals (SIPs)

[rusackas]

Please make sure you are familiar with the SIP process documented
(here)[https://github.com//issues/5602]. The SIP will be numbered by a committer upon acceptance.

[SIP-100] Procedure for tracking status and implementation of Superset Improvement Proposals (SIPs).

Motivation

SIP-0 covers the motivation and process for opening SIPs. This seeks to create a sustainable means of tracking the SIPs from initiation to completion, so we can have a more cohesive vision of the roadmap, and help usher through or abandon these proposals as warranted.

Proposed Change

We hereby propose a "standardized" process to tracking the workflow of SIPs.

• A SIP proposal should be an Issue rather than a GitHub discussion, since this allows placement in a GitHub Project and allows assignees.
• New SIPs, upon being numbered, and labeled with the sip label, shall be added to the GitHub Project kanban board
• The issue for any given SIP will remain open while it is in the voting process, and will be closed upon completion of a vote (whether successful or not)
• The columns of the project kanban board will track the flow of a SIP through the following states:
  • Pre-Discussion (these are new SIPs that have not been sent to the mailing list for a [DISCUSS] thread
  • [DISCUSS] Thread Opened (a discussion thread has been initiated)
  • [VOTE] Thread Opened (discussion complete, vote is open
  • [RESULT][VOTE] Approved (vote closed and approved)
  • Implemented/Done (the work/decision/task has been effectively completed)
  • Denied/Closed/Discarded (voting didn't pass, the author lost interest, the SIP "timed out," or the ticket became otherwise obsolete)
• Issues for SIPs will remain in an open state up to and through the voting process. Because the work to complete a SIP might take a long time (possibly years), the ticket will be closed at the completion of the vote. The ticket will continue to be tracked through implementation on the kanban board.
• Issues/SIPs will be discussed and reach consensus through official means (the Apache Superset dev mailing list), but there may also be discussion and tracking/updating of the project board in additional syncs (on Slack, or as part of the Operational Model working groups and/or Superset Town Hall, for example). All are encouraged to join these fora if they're interested.
• Timeouts: If the author of a SIP is unreachable, and/or doesn't help to move the SIP through the discuss/vote steps within 6 months, a PMC member may automatically discard the SIP. The SIP may still be brought back to an earlier step in the flow by either the author or a PMC member.

New or Changed Public Interfaces

SIP-0: Since this is an addendum, it should be linked and/or appended there if this passes a vote.

New dependencies

The GitHub project board becomes more of a sanctioned/supported artifact.

Migration Plan and Compatibility

All tickets are already in place and most are up to date. This just seeks to solidify things and encourage adoption of the pattern.

Rejected Alternatives

None.

[michael-s-molina]

Thank you for the proposal @rusackas!