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.