summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authorShannon Woods <158105547+swoods-nv@users.noreply.github.com>2024-07-01 11:14:17 -0400
committerGitHub <noreply@github.com>2024-07-01 11:14:17 -0400
commit15c02eb82896b94fbc183608e39e16661abfb882 (patch)
tree5f9693a44e08de91c47eda3329aae896dd75c805 /docs
parente19e0474639d579e6f0dc33d6b0c9b2a6d723fae (diff)
Add clearer information about how to submit a proposal document. (#4514)
Bug: 4511 Author: Shannon Woods
Diffstat (limited to 'docs')
-rw-r--r--docs/proposals/README.md14
1 files changed, 12 insertions, 2 deletions
diff --git a/docs/proposals/README.md b/docs/proposals/README.md
index 9df8052c4..4dbf0760c 100644
--- a/docs/proposals/README.md
+++ b/docs/proposals/README.md
@@ -4,5 +4,15 @@ Proposals
This directory contains proposals / "RFCs" for Slang language/compiler/system features.
In general, proposals are used for features that are large or complicated enough that the design and/or plan benefits from being discussed in detail before we commit to making code changes.
-Design *discussion* can often be facilitated by a GitHub/GitLab issue, or PR review comments, but often it is difficult for a developer to get a clear summary of the final decisions/POR without reading an entire discussion thread.
-By framing design discussion around a document that captures the decisions, we hope to ensure that the at the end of the discussion we have useful collateral for anybody who goes to implement a feature.
+## How to make a proposal ##
+
+1. Copy the template doc, `000-template.md` to a new document. Fill in the details of your proposal, and give the document a descriptive name following the same formatting. Leave the number as `000`.
+2. Submit a PR with your proposal doc in the `slang/docs/proposals/ directory` to solicit input from the maintainers of Slang.
+3. Integrate feedback and iterate until you have affirmative approval from maintainers.
+4. Include maintainer approval information and update the proposal status in your proposal header prior to merge.
+
+The maintainer accepting the merge should assign the proposal a number.
+
+Implementation of features large enough to require a proposal doc should not begin until the doc has been accepted and merged.
+
+