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
This commit is contained in:
parent
54da8e5ef0
commit
9b7a2bb78d
|
@ -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.
|
|
@ -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.
|
||||||
|
|
Loading…
Reference in New Issue