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

@@ -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.

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[&nbsp];
+    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.
+