SIP-000-1: SIP Process SIP-000 Upgrade

[Hero-Gamer]

SIP-000-1 packs a number of refinement of the SIP Process we've learned over the past few years.

Below is a "Change log" of SIP-000-1

1. Update Abstract to mention this replaces SIP-000 and the rationale
2. Added “## Backwards Compatibility” but it is NA
3. In "## SIP Format", reordered some fields sequence according to SIP_Template.md
4. Moved 2 ## SIP Flow subsections together, renamed the first to SIP Status
5. Moved “## SIP Types” to logical order, after “## Layer”
6. New subsection “## SIP Layers” created by moving the explanations from Preambles
7. Preambles’ spec’s ordering of fields reordered to match the SIP_TEMPLATE
8. Added “### SIP Authoring Rules”
9. Added “### Expectation of Minimum Timelines And Rules”
10. Added “### SIP Versioning and Replacement Update Policy”
11. Added “### Documentation, Repo Maintancne, Merging into Main”


• This PR should serve as a starting point of SIP-000 improvements we want to add.
• Some great ideas from @whoabuddy in this PR too we can include: Documenting the SIP approval process #145
  So please welcome to make changes and add/remove suggestions!

Some unanswered questions:

• Hard Fork SIPs code freeze rules - Define process for code freeze and creation of dedicated release branches. - Only milestone changes for that release may be merged into the fork branch.

• SIP-000 folder naming: I tried both folder naming ideas, whether it's "_1" or "-1" (see images below), might look both little odd and confusing, I'd actually perhaps propose keeping the SIP-000 folder naming as is. Only the the MD files get updated according to the SIP-000 versioning policy, and filed correctly within.

• Rider SIPs rules of engagement: How Rider SIPs should be handled approval wise. And documentation wise.

[Hero-Gamer]

Added "### Post-CAB Vote Updates" details cc: @whoabuddy

[wileyj]

thanks for this! looking it over

[wileyj]

Moving to draft for now

[Hero-Gamer]

As much lots of technical people can directly submit SIP proposal to SIP Repo directly and get feedback that way

• but from history, people (a range of people from new devs to devs with experience of SIP process) better have a clearer defined process, which we could include into SIP-000-1.

Taking transparency and public feedback period needed in general, I'd actually suggest considering ensuring all SIP authors go through a defined process (which can be reinforced by showing it on ZeroAuthority platform)

1. Stacks Forum post creation
2. SIP Call - discussion and direction
3. Working group feedback (e.g. technical SIPs send to → Clarity Working Group)
4. GitHub PR submission
5. Comments resolution with SIP editors and community
6. CAB voting when ready
7. (optional) Community-wide token voting if needed

SIP Editors (mid-process) and SIP Deputies (earlier process) will assist the Authors throughout the process.
@wileyj @314159265359879 @clairetopalian @xyzerobtc

[behaddy]

As much lots of technical people can directly submit SIP proposal to SIP Repo directly and get feedback that way

• but from history, people (a range of people from new devs to devs with experience of SIP process) better have a clearer defined process, which we could include into SIP-000-1.

Taking transparency and public feedback period needed in general, I'd actually suggest considering ensuring all SIP authors go through a defined process (which can be reinforced by showing it on ZeroAuthority platform)

1. Stacks Forum post creation

2. SIP Call - discussion and direction

3. Working group feedback (e.g. technical SIPs send to → Clarity Working Group)

4. GitHub PR submission

5. Comments resolution with SIP editors and community

6. CAB voting when ready

7. (optional) Community-wide token voting if needed

SIP Editors (mid-process) and SIP Deputies (earlier process) will assist the Authors throughout the process.

@wileyj @314159265359879 @clairetopalian @xyzerobtc

Thanks @Hero-Gamer

So as @wileyj said, only 4-6 are enforceable and 1-3 are suggested, especially for getting community engagement.

[314159265359879]

Thanks Hero-Gamer for the work here, I know you talked to a lot of people to get to this list and several items are worth keeping. But not in SIP-000, let me explain.

This PR started from the question in #228: how do we update a ratified SIP, including SIP-000 itself. SIP-000 already answers that. It has the Replaced status, the Replaces and Superseded-By preamble fields, and it says substantial changes to a ratified SIP must be done as a separate SIP. A process update is a Meta type SIP under the Governance consideration and it gets the next free number like any other SIP. That is also exactly the BIP2 to BIP3 precedent you confirmed with the BIP editor in #228. So we do not need to change SIP-000 to be able to update SIP-000, and we do not need a SIP-000-1 numbering scheme.

On the content: items 1 to 7 of the changelog are reordering and moving text, no change in meaning, not worth a ratification cycle. The fork-only rule, comment resolution etiquette and merge checklist are useful but they are repo working rules, they belong in a CONTRIBUTING or process doc where we can improve them without a vote. The merge checklist as written also conflicts with SIP-000, which requires Accepted SIPs to be committed to the repo before CAB review. The post CAB vote rule is good practice and CABs can adopt it in their own bylaws today. The minimum 6 week timeline I am against, SIP-000 deliberately says fair, speedy, timely, some SIPs need six months and some need two weeks, and an undefined emergency exception undoes the rule exactly when it matters. Hard fork release branches are engineering process, SIP-000 explicitly keeps ratification independent of that, this belongs in stacks-core release management.

Next steps:

• I am closing this PR, the text stays available as reference.
• The operational rules move to a CONTRIBUTING/process doc PR, together with the workflow mapping from Documenting the SIP approval process #145. That can merge quickly.
• SIP Update Policy #228 gets closed with a reference to this answer, replacement model, already in SIP-000.
• When we collect substantive governance changes that genuinely do not fit the current SIP-000 text, that becomes a proper replacement SIP with complete text, a normal number and an Activation section, through the standard process.

[xyzerobtc]

Taking transparency and public feedback period needed in general, I'd actually suggest considering ensuring all SIP authors go through a defined process (which can be reinforced by showing it on ZeroAuthority platform)

1. Stacks Forum post creation
2. SIP Call - discussion and direction
3. Working group feedback (e.g. technical SIPs send to → Clarity Working Group)
4. GitHub PR submission
5. Comments resolution with SIP editors and community
6. CAB voting when ready
7. (optional) Community-wide token voting if needed

We could implement process updates to make transparency and public feedback period needed - it would also help people understand current status