Use a table for SIPS (draft -> ratified)

[wileyj]

Need to verify the links and activation status, but this is currently up to date and gives a nicer 1-pager of sips.

rather than the standard list of ratified sips - this change adds a markdown table of all sips that have been accepted and a number assigned (no matter the status).

the caveat is this will need to be updated regularly by sip editors (etc) so it remains current.

[wileyj]

to see how this would look if merged, check my branch readme: https://github.com/wileyj/sips/tree/chore/update_readme

[whoabuddy]

I like tables for display 👍

rather than the standard list of ratified sips - this change adds a markdown table of all sips that have been accepted and a number assigned (no matter the status).

could do one table per list with a detail block to allow expand/contract too:

SIPs

Ratified SIPs

SIP Number	SIP Title	Status
000	The Stacks Improvement Proposal Process	Ratified
001	The Clarity Smart Contract Language	Ratified
002	The Clarity Smart Contract Language	Ratified
003	Stacks P2P Network	Ratified
004	Cryptographic Commitment to Materialized Views	Ratified
005	Blocks, Transactions, and Accounts	Ratified
006	Clarity Cost Execution Assessment	Ratified
007	Stacking Consensus	Ratified
008	Clarity	Ratified

In-Progress SIPs

SIP Number	SIP Title	Status
032	Improved stacking	Draft
033	Clarity Smart Contract Language, version 4	Activation-In-Progress
034	Dimension-Specific Tenure Extend Variants	Activation-in-Progress
035	Clarification of Clarity's secp256r1-verify Behavior	Ratified
036	BTC addresses for Stacks transactions	Draft
037	Agent Coordination Framework	Draft
038	Standard Trait Definition for Commitment-Based Private Metadata (Encrypted NFTs)	Draft
039	Clarity 5 and Epoch 3.4	Draft
040	SIP for improved post-conditions	Draft
041	Agent Registries (ERC-8004 on Stacks)	Draft

the caveat is this will need to be updated regularly by sip editors (etc) so it remains current.

this is the issue either way. if we know the exact flow a SIP should take on GitHub then we can make sure this gets updated when we merge in the ratified status. #145 was the first attempt at that

[wileyj]

I like tables for display 👍

rather than the standard list of ratified sips - this change adds a markdown table of all sips that have been accepted and a number assigned (no matter the status).

could do one table per list with a detail block to allow expand/contract too:

SIPs

Ratified SIPs
SIP Number SIP Title Status
000 The Stacks Improvement Proposal Process Ratified
001 The Clarity Smart Contract Language Ratified
002 The Clarity Smart Contract Language Ratified
003 Stacks P2P Network Ratified
004 Cryptographic Commitment to Materialized Views Ratified
005 Blocks, Transactions, and Accounts Ratified
006 Clarity Cost Execution Assessment Ratified
007 Stacking Consensus Ratified
008 Clarity Ratified
In-Progress SIPs
SIP Number SIP Title Status
032 Improved stacking Draft
033 Clarity Smart Contract Language, version 4 Activation-In-Progress
034 Dimension-Specific Tenure Extend Variants Activation-in-Progress
035 Clarification of Clarity's secp256r1-verify Behavior Ratified
036 BTC addresses for Stacks transactions Draft
037 Agent Coordination Framework Draft
038 Standard Trait Definition for Commitment-Based Private Metadata (Encrypted NFTs) Draft
039 Clarity 5 and Epoch 3.4 Draft
040 SIP for improved post-conditions Draft
041 Agent Registries (ERC-8004 on Stacks) Draft

the caveat is this will need to be updated regularly by sip editors (etc) so it remains current.

this is the issue either way. if we know the exact flow a SIP should take on GitHub then we can make sure this gets updated when we merge in the ratified status. #145 was the first attempt at that

neat! the expandable table is nice, my approach was definitely KISS - but i'm not opposed to refactoring to your suggestion (will wait for more feedback).
as long as we show the full list, the format isn't important.

The one thing i would add between the two approaches is your suggestion would require slightly more care, since an editor would be moving a row from one table to another. other than that, i don't see anything that would prevent using your method vs what was proposed (and to be clear, that's a process/people issue vs anything technical).

I also looked at the issue - definitely agree there needs to be some standard process in place. to that end, i have been picking away at an update to sip-000, perhaps we can codify what's expected there?

[Hero-Gamer]

I personally like the KISS approach as per Jw's file. One step closer aligned with Bitcoin's organization structure. Showing all available ideas even if they are fully ratified.

Only thing we might want to display in that table is the GAPS i.e. SIP-014 and SIP-017 are also displayed as a line item in the list, and saying it's available to be assigned?

So that SIP Editors can utilize those slots.

[brice-stacks]

I like it!

[314159265359879]

Cross-posting this here for visibility, original in reply to a question from Brice on Discord about why some SIP numbers are not present/used.

At the time, authors of SIPs may have picked a number for their SIP rather than waiting for someone else to assign one, out of an abundance of caution, picked numbers they were sure weren't in use yet.

It also looks like 017 was briefly assigned/used for this https://github.com/stacksgov/sips/pull/56/files and 014 was briefly used for a standard for smart contract documentation but I don't think it got past draft status #32. SIP-011 is also missing, that is because it wasn't activated.

I remember Jude said that they don't have to be given in chronological order. We can still give 14 or 17 to a SIP in the future. Perhaps it will make sense for some future sip to give it a lower number like 14 or 17. In the meantime we can do as you did and hand out numbers from where we are (36... and now 42).

I don't think we should reorder existing SIP just because of the references in documentation to the current numbers. It would cause unnecessary confusion. For the same reason, I don't think we should reuse SIP numbers once they have been assigned to a SIP, even if they eventually are not merged. They may still be after revision, and we prevent confusion by ensuring a SIP number does not refer to two completely different improvement proposals.

[314159265359879]

I think this is an improvement because it provides a more convenient overview with the table. Want to add the missing SIPs before you merge @wileyj?

Perhaps this helps:

SIP Number	SIP Title	Status
011	The buy-in-ustx Standard for non-custodial Marketplace traits	Rejected
014	Contract Documentation Standard	Withdrawn Draft
017	Schnorr Signatures	Withdrawn Draft

[314159265359879]

we should also include SIP-042 Removal of at-block #262

[brice-stacks]

lgtm!

[wileyj]

lgtm!

a few more changes I'll want to add per @314159265359879 but I'll get those tonight

[wileyj]

Added several missing SIPs to the list, i think this is currently accurate/complete

[brice-stacks]

Was this one ever approved by the technical cab? I see notes about requesting some changes and then a re-review, but no follow up.

[wileyj]

https://github.com/stacksgov/sips/blob/main/considerations/minutes/technical-cab/2023-10-27-pr-152-153.md#pr-153

however, activation criteria has not likely been met so it should probably transition to rejected by sc.