Standard process for new features or breaking changes

[trusktr]

Just starting a discussion here so it can be tracked and not lost in Discord.

(from https://discord.com/channels/722131463138705510/780502110772658196/958091536384532521)

I've been wondering if perhaps there can be an official process by which APIs modifications (at least breaking changes) and new additions can be vetted. Perhaps a stage system like in solid-primitives or ECMAScript.

To reword EcmaScript stages, but in relation to Solid, maybe something like this:

0. The idea exists (requires only one person to make the idea, and one merge approval), may have any amount of complete or incomplete description, maybe implementation (not required yet), although at this stage no amount of design or implementation is criteria for advancing to the next stage

1. Concensus is made that we may move forward in the idea (by core team). Work starts to get consensus on the API shape (if we haven't already, anyone can participate).

2. At this point, initial API shape consensus is reached (by core team), and we start an implementation (if we haven't already, anyone can try).

3. Implementation is reached (if we haven't already). At this stage, we publish to npm as a pre-release that is still subject to change. Maybe APIs in experimental state are prefixed with experimental in their name, or exported from an experimental folder, to make it clear. At this point we are confident the API will be mostly like what end users will have, but needs testing and verification, and there's a non-zero chance it could change.

At any stage, core may get concensus to downgrade to a lower stage and re-hash ideas.

4. This one is critical, after testing, and usage, we determine we like the API, and finally it goes out of pre-release and is considered stage 4.