{"componentChunkName":"component---src-pages-sips-sip-markdown-remark-frontmatter-sip-tsx","path":"/sips/sip-130/","result":{"data":{"markdownRemark":{"fileAbsolutePath":"/vercel/path0/content/sips/sip-130.md","frontmatter":{"sip":130,"sccp":null,"title":"New SIP Workflow","network":"Ethereum","author":"Kain Warwick (@kaiynne), David Goldberg (@TBC)","type":"Governance","proposal":null,"implementor":null,"release":null,"created":"2021-03-18T00:00:00.000Z","updated":null,"status":"Implemented"},"html":"

Simple Summary

\n\n

The introduction of the Spartan Council into the SIP governance process has generated a number of new states that a SIP can occupy. This SIP proposes a new workflow to augment the ones proposed in SIP-1, SIP-93 and SIP-104.

\n

Abstract

\n\n

The current flow for a SIP is below:

\n
[ WIP ] -> [ PROPOSED ] -> [ APPROVED ] -> [ IMPLEMENTED ] X [ REJECTED ]\n
\n

This SIP proposes a new flow:

\n
[ DRAFT ] -> [ FEASIBILITY ] -> [ SC REVIEW PENDING ] -> [ VOTE PENDING  ] -> [ APPROVED ] -> [ IMPLEMENTED ]\n                                                                         -> [ REJECTED ]\n                                                                         -> [ FEASIBILITY ]\n
\n

Motivation

\n\n

Following the implementation of SIP-104 a number of issues have arisen. The original SIP workflow worked well but over time a number of conventions have emerged that require additional states. The most important of these is the introduction in SIP-104 of a Spartan Council review meeting between various stakeholders in the SIP process, where the SIP Author must present the SIP to the Council, providing them an opportunity to interrogate any issues the SIP might introduce as well as the risks associated with the change. In adition to this by convention most SIPs would have a core contributor as a champion in the past, however, as more community SIPs have been proposed a process is now required to ensure the Council can communicate the priotisation of all open SIPs to the core contributors. This state has been named feasibility where the Core Contributors and Spartan Council will agree to assign an engineer to assess the feasibility of a community SIP alognside the SIP author.

\n

Specification

\n\n

Overview

\n\n

The existing states are replaced by the states below and these states will need to be implemented on the SIPs website or the SIPs website will need to be upgraded/replaced in the future to ensure these states are handled.

\n

DRAFT (The initial state of a new SIP before the Spartan Council and core contributors have assessed it)\nFEASIBILITY (Once assessed a SIP is moved into Feasibility and a CC is assigned)\nSC REVIEW PENDING (Once the Author and the CC doing the feasibility study are satisfied a SIP is in Spartan Council Review Pending)\nVOTE PENDING (Once the Spartan Council has formally reviewed the SIP during the SIP presentation they can either move it to a vote or send it back to Feasibility)\nAPPROVED (If a vote is successful the SIP is moved to Approved, otherwise it is Rejected)\nREJECTED (If a vote is not successful the SIP is moved to Rejected)\nIMPLEMENTED (Once implemented on-chain the SIP is moved to Implemented state)

\n

Rationale

\n\n

The introduction of the new states ensures that at all times all stakeholders know where in the SIP workflow a SIP is and what the next steps are. This will help with coordination efforts as the CC and SC now span multiple timeszones so ambigous states lead to significant uncertainty and inefficiency.

\n

Technical Specification

\n\n

N/A

\n

Test Cases

\n\n

N/A

\n

Configurable Values (Via SCCP)

\n\n

N/A

\n

Copyright

\n

Copyright and related rights waived via CC0.

"}},"pageContext":{"id":"fd48eeb1-5936-5ef5-8b97-32589d650b2f","frontmatter__sip":130,"__params":{"frontmatter__sip":"130"}}},"staticQueryHashes":[]}