Add SIMD-0001: A process for improvements#1
Conversation
|
I think we should call this SIMD-0000 because array indexes begin with zero |
Don't have any strong feels on the 0001. Updated to 0000 |
|
Thanks for working on this! I'm curious, what's the motivation for making a new site? Do you have a vision yet for where the new site will be hosted, who will own it, how proposals will be added and updated? |
A new site is required to be separate from the original Labs proposal process and be dedicated to proposals only. The proposals will be added under New site would be hosts at simd.solana.com and be owned by Solana Foundation. |
|
Ok moving the process over to Foundation makes sense.
Do we have guidance on what changes will require a proposal? |
There's some guidance here. For example, every feature today would have a proposal. |
|
I'd like to find a different term than SIMD for all this. |
0ab807c to
fea5d75
Compare
fdc4576 to
7106c3a
Compare
|
Planning on getting this merged to be battle tested/start updating at 3pm PST, December 9th, 2022. Last call for concerns or updates. |
| integrating feedback. The most relevant core contributors to the proposal | ||
| should be included in the review process. Review will take place completely | ||
| through Github so that all comments are collected and documented. Once | ||
| consensus is met by the core contributors, the proposal can either be accepted |
There was a problem hiding this comment.
How is consensus reached or measured? This seems like the most important part of this new process.
There was a problem hiding this comment.
I have added more information about consensus. While it is important, I am trying to avoid defining what consensus looks like, other than as a social construct. I want the process of proposals to be very similar to how it is today, driven by the norms of core contributors, and not impose more structure than is necessary.
There was a problem hiding this comment.
I think consensus on proposals, at least on the activation thereof, should be migrated to on-chain voting by means of stake-weighted realms DAO. Right now the on-chain voting is severely lacking both in application and functionality, as it requires a cumbersome CLI-driven token transfer and provides no opportunity to dissent and little access or insight into voting record or history.
A Realms DAO can be created where voting power is synchronized to stake-weight every epoch, feature activation should require a majority of stake to vote in favour of it. Currently the momentum of upgrading to a feature-including version forces validators to comply with no opportunity to dissent, the only option is "don't adopt a change you don't agree with" which however means suicide as one can no longer participate in the chain. An opportunity to openly and transparently vote and express assent or dissent is needed.
There was a problem hiding this comment.
@michaelh-laine I agree with your sentiment on wanting to be able to have a voice and that there should be more around feature activations. For this proposal I'd like to stay on the process of proposals vs the implementation and activation.
Update simd-0001 with mermaid markdown diagrams update to use frontmatter on SIMDs update simd-0001 to use frontmatter Addressing comments on structure Update simd structure update simd number to 0001 Add info on consensus for simd-0001
Agreed, very confusing as a hardware guy. Makes me think of GPUs. |
Apparently people think the confusion is good :) |
Not my intention to be confusing. We can update, especially this early in the process |
fix linting, formatting, and header
Current Proposal Process Shortfalls
The current proposal process is as follows:
github issue(s).
docs/src/proposals.
Accepted Design proposalsand live on SolanaDocs
feature-gateissue is created and kept up-to-date to trackthe feature's activation.
reviewed by the same group in step 3.
Accepted Design ProposalstoImplemented Proposals.While this is a good flow to fast iteration, there are a few shortfalls:
Proposal for process:
The main changes to the current process:
The process proposed was based on both RFC and EIP.