RFC 53: updates to RFC process

.github/ISSUE_TEMPLATE/tracking-issue.md

@@ -7,13 +7,39 @@ labels: management/tracking, status/proposed
 
 ## Description
 
-<!-- Short description of the proposed feature -->
+Short description of the proposed feature:
+* First sentence describes the feature (think changelog entry)
+* Describe the change to users as if it was already been implemented (i.e. like it would be described in the README).
+* Add code or CLI commands as appropriate
+* Keep it short
 
-## Working Backwards
+## Roles
 
-<!-- Present this feature/change to users as if it was already been implemented -->
+| Role                | User
+|---------------------|------------------------------
+| Proposed by         | @alias
+| Driver              | @alias
+| Approvers           | @alias, @alias
+| Stakeholders        | @alias, @alias, @alias
+| Implementation lead | @alias
 
-## Roles
+## Workflow
+
+- [x] Tracking issue created (label: `status/proposed`)
+- [ ] Driver assigned
+- [ ] Approvers assigned
+- [ ] Stakeholders identified
+- [ ] Kick off meeting
+- [ ] RFC pull request created (label: `status/review`)
+- [ ] Community reach out (via Slack and/or Twitter)
+- [ ] Final comments period (label: `status/final-comments-period`)
+- [ ] Approved and merged (label: `status/approved`)
+- [ ] Implementation lead assigned
+- [ ] Execution plan submitted (label: `status/planning`)
+- [ ] Plan approved and merged (label: `status/implementing`)
+- [ ] Implementation complete (label: `status/done`)
+
+---
 
-* **Driver** (drives the proposal to completion): @user
-* **Approver(s)**: (assigned by CDK team)
+> Driver is responsible drive the RFC according to this checklist, and apply the
+relevant labels to this issue so that the RFC table in README gets updated.

0000-template.md

@@ -1,52 +1,43 @@
----
-rfc pr: [#xxx](https://github.com/aws/aws-cdk-rfcs/pull/xxx) <-- fill this after you've already created the PR
-tracking issue: https://github.com/aws/aws-cdk-rfcs/issues/yyy
----
-
 # [TITLE]
 
 > One sentence: brief description of the feature from a user perspective.
 
+* Tracking issue: https://github.com/aws/aws-cdk-rfcs/issues/yyy
+* Author(s): @alias, @alias, ...
+* Approver(s): @alias, @alias, ...
+
 ## Working Backwards
 
 > This section should contain one or more "artifacts from the future", as if the
-> feature was already released and we are publishing its CHANGELOG, README
-> and optionally a PRESS RELEASE.
->
-> This is the most important section of your RFC. It's a powerful thought
-> exercise which will challenge you to truly think about this feature from a
-> user's point of view.
-
-### CHANGELOG
-
-> Write the changelog entry for this feature in conventional form (e.g.
-> `feat(eks): cluster tags`).
->
-> If this change includes a breaking change, include a `BREAKING CHANGE` clause
-> with information on how to migrate. If migration is complicated, refer to a
-> fictional GitHub issue and add its contents here.
-
-### README
-
-> If this is a new feature, write the README section which describes this new
-> feature. It should describe the feature and walk users through usage examples
-> and description of the various options and behavior.
-
-### PRESS RELEASE
-
-> If this is a major feature (~6 months of work), write the PRESS RELEASE which
-> announces this feature. The press release is a single page that includes 7
-> paragraphs: (1) summary, (2) problem, (3) solution, (4) leader quote, (5) user
-> experience, (6) customer testimonial and (7) one sentence call to action.
-
-## FAQ
-
-> This section should contain answers to questions customers will likely ask about
-> this release. Similar to the working backwards section, this section should be
-> written "from the future" in a language as if the feature is now released.
+> feature was already released and we are publishing its CHANGELOG, README and
+> optionally a PRESS RELEASE. This is the most important section of your RFC.
+> It's a powerful thought exercise which will challenge you to truly think about
+> this feature from a user's point of view. 
+
+> Choose *one or more* of the options below:
+> * **CHANGELOG**: Write the changelog entry for this feature in conventional form
+> (e.g. `feat(eks): cluster tags`). If this change includes a breaking change,
+> include a `BREAKING CHANGE` clause with information on how to migrate. If
+> migration is complicated, refer to a fictional GitHub issue and add its
+> contents here.
+> * **README**: If this is a new feature, write the README section which describes
+> this new feature. It should describe the feature and walk users through usage
+> examples and description of the various options and behavior.
+> * **PRESS RELEASE**: If this is a major feature (~6 months of work), write the
+> press release which announces this feature. The press release is a single page
+> that includes 7 paragraphs: (1) summary, (2) problem, (3) solution, (4) leader
+> quote, (5) user experience, (6) customer testimonial and (7) one sentence call
+> to action.
+
+## Frequently Asked Questions
+
+> This section should include answers to questions readers will likely ask about
+> this release. Similar to the "working backwards", this section should be
+> written in a language as if the feature is now released.
 >
-> The template includes a bunch of common questions, and you should add
-> questions that might be relevant to this feature.
+> The template includes a some common questions, feel free to add any questions
+> that might be relevant to this feature or omit questions that you feel are not
+> applicable.
 
 ### What are we launching today?