RFC 53: updates to RFC process

.github/ISSUE_TEMPLATE/tracking-issue.md

@@ -7,13 +7,36 @@ labels: management/tracking, status/proposed
 
 ## Description
 
-<!-- Short description of the proposed feature -->
+Short description of the proposed feature.
 
-## Working Backwards
+## Roles
 
-<!-- Present this feature/change to users as if it was already been implemented -->
+| Role                | User
+|---------------------|------------------------------
+| Proposed by         | @alias
+| Author(s)           | @alias, @alias, @alias
+| API Bar Raiser      | @alias
+| Stakeholders        | @alias, @alias, @alias
 
-## Roles
+> See [RFC Process](https://github.com/aws/aws-cdk-rfcs#rfc-process) for details
+
+## Workflow
+
+- [x] Tracking issue created (label: `status/proposed`)
+- [ ] API bar raiser assigned (ping us at
+  [#aws-cdk-rfcs](https://cdk-dev.slack.com/archives/C025ZFGMUCD) if needed)
+- [ ] Kick off meeting
+- [ ] RFC pull request submitted (label: `status/review`)
+- [ ] Community reach out (via Slack and/or Twitter)
+- [ ] API signed-off (label `api-approved` applied to pull request)
+- [ ] Final comments period (label: `status/final-comments-period`)
+- [ ] Approved and merged (label: `status/approved`)
+- [ ] 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)
+> Author is responsible to progress the RFC according to this checklist, and
+apply the relevant labels to this issue so that the RFC table in README gets
+updated.

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,7 +1,10 @@
-* Tracking issue: #
-* [Rendered version](/my-branch/text/xxxx.md)
+This is a request for comments about {RFC_DESCRIPTION}. See #{TRACKING_ISSUE} for
+additional details. 
+
+APIs are signed off by @{BAR_RAISER}.
 
 ---
 
 _By submitting this pull request, I confirm that my contribution is made under
 the terms of the Apache-2.0 license_
+

0000-template.md

@@ -1,52 +1,55 @@
----
-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
----
+# {RFC_TITLE}
 
-# [TITLE]
+* **Original Author(s):**: @{AUTHOR}
+* **Tracking Issue**: #{TRACKING_ISSUE}
+* **API Bar Raiser**: @{BAR_RAISER_USER}
 
-> One sentence: brief description of the feature from a user perspective.
+> Write one sentence which is a brief description of the feature from a user
+> perspective ("impact on users").
 
 ## 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.
+> feature was already released and we are publishing its CHANGELOG, README,
+> CONTRIBUTING.md 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.
 >
-> 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`).
+> Choose *one or more* of the options below:
 >
-> 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.
+> * **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.
 
-### PRESS RELEASE
+Ticking the box below indicates that the public API of this RFC has been
+signed-off by the API bar raiser (the `api-approved` label was applied to the
+RFC pull request):
 
-> 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.
+```
+[ ] Signed-off by API Bar Raiser @xxxxx
+```
 
-## FAQ
+## Public 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.
+> 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?
 
@@ -75,7 +78,7 @@ tracking issue: https://github.com/aws/aws-cdk-rfcs/issues/yyy
 > Is there a way to address this use case with the current product? What are the
 > downsides of implementing this feature?
 
-### What changes are required to enable this change?
+### What is the technical solution (design) of this feature?
 
 > Briefly describe the high-level design approach for implementing this feature.
 >