We are both encouraged and humbled by the recent flurry of proposals for making the Stacks blockchain better! As you may have read elsewhere, these proposals are the starting point for official Stacks Improvement Proposals (SIPs), and must pass through the SIP process. The SIP process is a formal procedure that Stacks ecosystem members follow in order to discuss, document, ratify, and amend the rules that govern how the blockchain and its ecosystem are organized and operated. The SIPs that come out of the SIP process describe how and why a particular facet of the ecosystem works the way it does. SIPs are not limited to technical specifications, either. Today, there are tracks for governance, economics, ethics, and diversity SIPs that describe how the people in the ecosystem are expected to work together.
No one is above the SIP process. Even the most senior developers must follow it for each network upgrade they write in order to make backwards-incompatible changes in an orderly fashion. Such SIPs require explicit community approval, as has been done for SIPs 001 through 008 and the more-recent SIP 012 upgrade. Given the recent high influx of inbound proposals for backwards-incompatible changes, we are aiming to clarify the process and create spaces for more conversations. To this end, we at the Stacks Foundation are taking the following steps:
Weekly SIPs Call. We will hold a public weekly call where SIP authors can give short presentations on their “pre-SIP” proposals and do Q&A with other community members and SIP committee members. Date and time to be announced soon.
SIP Resident. The Stacks Foundation will create a paid position for an individual who will spend up to a year supporting SIP authors through the SIP process as needed and desired, helping them to take their proposals from an idea to a fully-scoped SIP and corresponding implementation. They will use their learnings from the experience to further streamline the SIP process, and will communicate the status and updates of in-progress SIPs to the community.
Community pre-approval. To prioritize the growing volume of proposals, we propose the creation of a pre-approval process whereby the community helps determine which up-and-coming proposals will be considered for the next network upgrade. It will take a few iterations to figure out the best way to do this, so we would love your input on designing it. If this works out well, we’ll formalize it with a governance-track SIP submission (subject to community ratification, of course!).
Mentorship. In order for a SIP to advance to ratification, it needs to include both the detailed technical description of the proposed change, as well as a reference implementation. To help guide technical SIP authors through the process, authors of pre-approved SIPs will have access to mentorship from a current core developer. The mentoring developer will help the SIP author(s) set up a testnet deployment with their implementation, and help them get their code merged into the codebase. Over time, this mentorship program is expected to grow the number of contributors to core development, thereby increasing the number of person-hours available to work on future network upgrades.
If you want to read more about the SIP process, a good starting point is SIP 000, which describes the SIP ratification procedure in detail. All SIPs, including submitted works-in-progress, are stored in the SIPs repository on Github.
Thank you again for all of the discussion! Let’s keep this conversation going below.