SIP-160: Updated SIP Workflow

Simple Summary

SIP-130 introduced a number of new states in the SIP workflow, this SIP intends to clarify some of the exceptions to this workflow to ensure there is consensus in the community about SIP meta-governance. This SIP also introduces additional meta-data headers to ensure all critical information is tracked within each SIP.

Abstract

This SIP is a meta-governance SIP to addresses and clarifies the workflow for the SIPs repository specified in SIP-130, by introducing new meta-data and explicit process flows between SIP states.

Motivation

The introduction of new SIP states in SIP-130 has created some uncertainty within the SIP editors and council. This SIP will reduce that uncertainty and more clearly describe what the the various actors in the SIP process can do.

Specification

Overview

The following rules will be added to the SIPs process:

1. SIP editor roles can only be assigned by the Council, this is an update to what is stated in SIP-1 which will need to be updated if this SIP passes.
2. The SIP editors are the only ones who can merge to the SIPs repo, this is to ensure correct processes and procedures are adhered to for SIPs and SCCPs.
3. If a SIP author submits a PR to a SIP that is already in “Vote Pending” the SIP editor must notify the council of the change before merging the PR, and if requested move the SIP back into “Feasibility”.
4. If a SIP author submits a PR to a SIP that is already in “Approved” or “Implemented” then the SIP editor must request a review of the change by the Council and, if the change is deemed material by the council, must move the SIP back to “Feasibility”.
5. If a SIP is in “Approved” or “Implemented” and the CC assigned to the SIP no longer believes the SIP is feasible to implement they must notify the Council as soon as is practical that a vote should be held to decide whether to move the SIP to “Rejected”.
6. A vote to move a SIP from “Approved” or “Implemented” to “Rejected” must reference the previous vote and the SIP should be updated with a note to indicate that it was “Rejected” for infeasibility post Approval.
7. SIP editors must merge or close PRs to the SIPs repo within a reasonable time, ideally within two weeks of submission. The Council can request a SIP editor to extend this process if needed to allow governance to assess the SIP.
8. A Council member may at any time request that a SIP be moved from “Rejected” back to “Feasibility” if they believe that the underlying circumstances that caused the SIP to be rejected have changed.
9. SIP editors who fail to adhere to the consensus rules and procedures can be removed at the discretion of the council.
10. A new meta-data field will be added to each SIP, "Implementor" represents the CC or CCs assigned to implement the SIP.
11. A new meta-data field will be added to each SIP, "Release" represents the name of the release under which the SIP was deployed to mainnet.

Rationale

By explicitly describing which state transitions are allowed we constrain the power of the SIP editors to modify the SIPs repo ensuring they are merely maintaining the repo in line with community consensus and are not required to interpret what is the correct process for a SIP in a specific situation. Adding the new meta-data to the SIPs will ensure there is clarity in the community as to who is responsible for each SIP throughout the SIP workflow and into which release the SIP was deployed.

Technical Specification

N/A

Test Cases

N/A

Configurable Values (Via SCCP)

N/A

Copyright

Copyright and related rights waived via CC0.