add: rfc template (#1428)

add: info about RFC process
update: CONTRIBUTING.md to mention RFCs

CONTRIBUTING.md

@@ -25,7 +25,8 @@ Contributions via pull requests are much appreciated. Before sending us a pull r
 
 1. You are working against the latest source on the *main* branch.
 2. You check existing open, and recently merged, pull requests to make sure someone else hasn't addressed the problem already.
-3. You open an issue to discuss any significant work - we would hate for your time to be wasted.
+3. **You open an issue to discuss any significant work** - we would hate for your time to be wasted. Alternatively, you
+   may submit an RFC. You can learn about our RFC process [here](./design/src/rfcs/overview.md).
 
 To send us a pull request, please:
 

design/src/rfcs/overview.md

@@ -1,5 +1,15 @@
 # RFCs
 
+**What is an RFC?:** An RFC is a document that proposes a change to `smithy-rs` or the AWS Rust SDK. Request for Comments means a request for discussion and oversight about the future of the project from maintainers, contributors and users.
+
+**When should I write an RFC?:** The AWS Rust SDK team proactively decides to write RFCs for major features or complex changes that we feel require extra scrutiny. However, the process can be used to request feedback on any change. Even changes that seem obvious and simple at first glance can be improved once a group of interested and experienced people have a chance to weigh in.
+
+**Who can submit an RFC?:** An RFC can be submitted by anyone. In most cases, RFCs are authored by SDK maintainers, but everyone is welcome to submit RFCs.
+
+**Where do I start?:** If you're ready to write and submit an RFC, please start a GitHub discussion with a summary of what you're trying to accomplish first. That way, the AWS Rust SDK team can ensure they have the bandwidth to review and shepherd the RFC through the whole process before you've expended effort in writing it. Once you've gotten the go-ahead, start with the [RFC template](./rfc_template.md).
+
+## Previously Submitted RFCs
+
 - [RFC-0001: AWS Configuration](./rfc0001_shared_config.md)
 - [RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream](./rfc0002_http_versions.md)
 - [RFC-0003: API for Presigned URLs](./rfc0003_presigning_api.md)

design/src/rfcs/rfc_template.md

@@ -0,0 +1,37 @@
+<!-- Give your RFC a descriptive name saying what it would accomplish or what feature it defines -->
+RFC: Your RFC
+=============
+
+<!-- RFCs start with the "RFC" status and are then either "Implemented" or "Rejected".  -->
+> Status: RFC
+
+<!-- A great RFC will include a list of changes at the bottom so that the implementor can be sure they haven't missed anything -->
+For a summarized list of proposed changes, see the [Changes Checklist](#changes-checklist) section.
+
+<!-- Insert a short paragraph explaining, at a high level, what this RFC is for -->
+This RFC defines how...
+
+<!-- The "Terminology" section is optional but is really useful for defining the technical terms you're using in the RFC -->
+Terminology
+-----------
+
+- **Some Term**: A definition for that term
+
+<!-- Explain how users will use this new feature and, if necessary, how this compares to the current user experience -->
+The user experience if this RFC is implemented
+----------------------------------------------
+
+In the current version of the SDK, users do X like this...
+Once this RFC is implemented, users will do X like this instead...
+
+<!-- Explain the implementation of this new feature -->
+How to actually implement this RFC
+----------------------------------
+
+In order to implement this feature, we need to add X and update Y...
+
+<!-- Include a checklist of all the things that need to happen for this RFC's implementation to be considered complete -->
+Changes checklist
+-----------------
+
+- [x] Create new struct `NewFeature`