From 9b7a2bb78d9f91266eb800be97d6a8305ab05e65 Mon Sep 17 00:00:00 2001 From: Jacob Creech <82475023+jacobcreech@users.noreply.github.com> Date: Fri, 9 Dec 2022 17:13:38 -0600 Subject: [PATCH] Add SIMD-0001: A process for improvements (#1) 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 --- XXXX-template.md | 58 +++++++++++ proposals/0001-simd-process.md | 172 +++++++++++++++++++++++++++++++++ 2 files changed, 230 insertions(+) create mode 100644 XXXX-template.md create mode 100644 proposals/0001-simd-process.md diff --git a/XXXX-template.md b/XXXX-template.md new file mode 100644 index 0000000..5e7be7c --- /dev/null +++ b/XXXX-template.md @@ -0,0 +1,58 @@ +--- +simd: 'XXXX' +title: Title of SIMD +authors: + - (fill in with names of authors) +category: Standard/Meta +type: Core/Networking/Interface/Meta +status: Draft +created: (fill me in with today's date, YYYY-MM-DD) +feature: (fill in with feature tracking issues once accepted) +--- + +## Summary + +A brief summary of what the feature is. + +## Motivation + +Why are we doing this? What use cases does it support? What is the expected +outcome? + +## Alternatives Considered + +What alternative designs were considered and what pros/cons does this feature +have relative to them? + +## New Terminology + +Is there any new terminology introduced with this proposal? + +## Detailed Design + +Explain the feature as if it was already implemented and you're explaining it +to another Solana core contributor. The generally means: + +- Explain the proposed change and how it works +- Where the feature fits in to the runtime, core, or relevant sub-system +- How this feature was/could be implemented +- Interaction with other features +- Edge cases + +## Impact + +How will the implemented proposal impacts dapp developers, validators, and core contributors? + +## Security Considerations + +What security implications/considerations come with implementing this feature? +Are there any implementation-specific guidance or pitfalls? + +## Drawbacks *(Optional)* + +Why should we not do this? + +## Backwards Compatibility *(Optional)* + +Does the feature introduce any breaking changes? All incompatibilities and +consequences should be listed. \ No newline at end of file diff --git a/proposals/0001-simd-process.md b/proposals/0001-simd-process.md new file mode 100644 index 0000000..0d2eeea --- /dev/null +++ b/proposals/0001-simd-process.md @@ -0,0 +1,172 @@ +--- +simd: '0001' +title: Solana Proposal Process +authors: + - Jacob Creech (Solana Foundation) +category: Meta +type: Meta +status: Draft +created: 2022-10-18 +--- + +## What is a Proposal? + +A proposal is a design document describing a new feature for Solana or its +processes or environment. The proposal should document the rationale for the +feature and enough documentation to understand the implementation. + +## Rationale + +A proposal is intended to be reviewed by core engineering and community members +keeping in mind security concerns, tradeoffs, and backwards compatibility. +Having a proposal process helps identify design issues early, alert the +community on a change, helps scale newer contributors on the architecture, and +acts as a historical record of the design decisions that have gone into Solana. +For implementors, the proposal is a blueprint for the feature and helps track +the development of a feature. + +## When you need to follow this process + +You need to follow this process if you intend to make "substantial" changes to +the Validator, RPC, consensus, or a change to the proposal process itself. What +constitutes a "substantial" change is evolving based on community norms and +varies depending on what part of the ecosystem you are proposing to change, but +may include the following: + +- A change in format of a RPC API method +- Networking interface changes between validators +- Compute requirement changes on the runtime + +Some changes do not require a proposal: + +- Rephrasing, reorganizing, refactoring, or otherwise "changing shape does not +change meaning". +- Additions that strictly improve objective, numerical quality criteria +(warning removal, speedup, better platform coverage, more parallelism, trap +more errors, etc.) + +## Proposal Types + +There are two types of proposals: + +- A **Standard** Proposal describes any change that affects most or all Solana +implementations, such as a change to the network protocol, consensus, proposed +application standards/conventions, block or transaction validity, or any change +or addition that affects the interoperability of applications using Solana. +Standard proposals can be broken down into the following categories: + + - **Core**: Anything that affects consensus or substantial changes to the +validator. + - **Networking**: Changes or substantial improvements to network protocol +specifications. + - **Interfaces**: Breaking changes around the client JSON RPC API +specifications and standards. + +- A **Meta** Proposal describes a process surrounding Solana or proposes a +change to (or an event in) a process. Process Proposals are like Standard +Proposals but apply to areas other than the Solana protocol itself. They may +propose an implementation, but not to Solana's codebase; they often require +community consensus and users are typically not free to ignore them. Examples +include procedures, guidelines, changes to the decision-making process, and +changes to the tools or environment used in Solana development. Any meta-EIP is +also considered a Process Proposals. + +## Proposal Lifecycle + +The stages in a lifecycle of a proposal are as follows: + +- Idea +- Draft +- Review +- Accepted +- Stagnant +- Withdrawn +- Implemented + +```mermaid +flowchart LR + Idea + Draft + Review + Accepted + + subgraph fail[ ]; + Stagnant + Withdrawn + end + + style fail fill:#ffe8e7,stroke:none + style Accepted fill:#f3f8dc,stroke:#c3db50; + + Idea ---> Draft; + Draft ---> Review; + Review ---> Accepted; + + Draft ---> Stagnant; + Review ---> Stagnant; + Review ---> Withdrawn; +``` + +### Idea + +At the idea stage, parties involved in the proposal are you -- the champion or +proposal author -- the reviewers, and the Solana Core Contributors. + +Before you begin writing a formal proposal, you should vet your idea. Ask the +Solana core community first if an idea is original to avoid wasting time on +something that will be rejected based on prior research. It is thus recommended +to discuss the proposal on the Solana Tech Discord under the #core-technology +channel. + +### Draft + +To begin drafting the proposal, do the following: + +- Fork the proposal repository +- Copy `proposals/XXXX-template.md` to `proposals/XXXX-my-feature.md` (where +"my-feature" is descriptive) +- Fill in the proposal. Put care into the details: proposals that do not +present convincing motivation, demonstrate lack of understanding of the +design's impact, or are disingenuous about the drawbacks or alternatives tend +to be poorly received. +- Submit a pull request. +- Now that your proposal has an open pull request, use the issue number of the +PR to update the `XXXX-` prefix to the number. + +### Review + +During review, the owner of the proposal is in charge of gathering and +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 +or withdrawn. This step is typically taken when enough tradeoffs have been +considered for the core contributors to make a decision. It is not necessary +for all participants to reach consensus. However, there should not be a strong +consensus against the proposal outside of the core contributors. + +### Accepted + +Some accepted proposals represent vital features that can be implemented right +away. Other accepted proposals can wait until some arbitrary core contributor +feels like doing the work. Every accepted proposal should have an associated +tracking issue in the Solana repository. If the implementation requires the +feature to be activated using the feature activation program, a feature-gate +issue for tracking across clusters should also be created. While it is not +*necessary* for the proposal author to also write the implementation, it is by +far the most effective way to see a proposal through to completion: authors +should not expect that other project developers will take on responsibility for +implementing their accepted feature. + +### Stagnant + +If a proposal reaches 6 months without activity, the proposal will be +marked as stale to be closed. A new proposal can be opened if the proposal is +closed and has a chance of reaching consensus. + +### Withdrawn + +The author has withdrawn the proposal. This state has finality and can no +longer be resurrected. If the idea is pursued at a later date it is considered +a new proposal. +