Merge pull request #867 from wagenet/advancement-workflow-docs

Advancement workflow docs

Author: wagenet

.github/READTHIS.md

@@ -12,7 +12,8 @@ This has various checks to ensure new the RFC has correct metadata, filename, et
 This should be tested when updating actions/find-added-or-modified-rfcs or any of
 the actions used within that action. See [testing](#testing).
 
-Test the following:
+#### Testing Steps
+
 - [ ] Adding a new RFC. A new pull request should be opened with a new RFC, the
   first job should correctly determine that an RFC has been added and the other
   jobs should run.
@@ -34,7 +35,8 @@ whether the pull request adds a new RFC. If it does, it labels the pull request
 This should be tested when updating actions/find-added-or-modified-rfcs or any of
 the actions used within that action. See [testing](#testing).
 
-Test the following:
+#### Testing Steps
+
 - [ ] Adding a new RFC. A new pull request should be opened with a new RFC, the
   first job should correctly determine that an RFC has been added and the other
   jobs should run. The label `S-Proposed` should be added.
@@ -57,7 +59,8 @@ If an RFC stage was modified, this triggers the open-advancement-pr.yml workflow
 This should be tested when updating actions/find-added-or-modified-rfcs or any of
 the actions used within that action. See [testing](#testing).
 
-Test the following:
+#### Testing Steps
+
 - [ ] Adding a new RFC. Merging a pull request that adds an RFC should open a
   pull request to advance to the next stage using the correct template.
 - [ ] Updating an RFC stage. Merging a pull request that modifies an existing RFC's
@@ -74,7 +77,15 @@ This workflow runs on workflow_dispatch and can be triggered from the GitHub UI.
 It takes a path to an RFC and will open a PR to advance it to the next stage, if
 applicable.
 
-Test the following:
+RFCs that already existed before the implementation of
+[Staged RFCs](https://github.com/emberjs/rfcs/blob/master/text/0617-rfc-stages.md)
+did not get advancement PRs to their next stage. To create an advancement PR you
+can manually run the workflow from the Github UI.
+
+![Screenshot of the Github UI for manually triggering a workflow](./doc-assets/advance-rfc.png)
+
+#### Testing Steps
+
 - [ ] In the UI, on this workflow, trigger with a path of an existing RFC. A pull
   request should be opened to advance the RFC to the next stage.
 - [ ] In the UI, on this workflow, trigger with a path of an existing RFC at the

.github/doc-assets/advance-rfc.png

@@ -14,7 +14,7 @@ The process is intended to provide a consistent and controlled path for new
 features and changes to enter the framework. RFCs can be created by any member
 of the community.
 
---- 
+---
 ## Quick links for Pull Requests for proposed and advancing RFCs
 [Quick links for Pull Requests for proposed and advancing RFCs]: #quick-links-for-pull-requests-for-proposed-and-advancing-rfcs
 
@@ -82,7 +82,7 @@ If that period is successful, with no new unaddressed concerns raised, the RFC
 is merged and is now in the [Accepted] stage.
 
 An RFC that does not achieve consensus to be accepted may enter a
-[Final Comment Period](#final-comment-periods-fcp) to move the RFC to the 
+[Final Comment Period](#final-comment-periods-fcp) to move the RFC to the
 [Closed] stage.
 
 ### Merged Proposals
@@ -276,30 +276,30 @@ Ember.
 Following the RFC repository is the best way to keep up with the proposed
 changes to Ember and with the implementation of accepted changes.
 
-Watching the repository will alert you to any newly created RFCs. Setting up 
-notifications on a particular pull request will help you follow the progress of 
+Watching the repository will alert you to any newly created RFCs. Setting up
+notifications on a particular pull request will help you follow the progress of
 that RFC.
 
 RFCs in [Final Comment Periods](#final-comment-periods-fcp) are labeled with
 [Final Comment Period](https://github.com/emberjs/rfcs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+label%3A%22Final+Comment+Period%22)
 and are announced on the [Ember twitter account](https://twitter.com/emberjs).
 
-[Quick links](#quick-links-for-pull-requests-for-proposed-and-advancing-rfcs) 
+[Quick links](#quick-links-for-pull-requests-for-proposed-and-advancing-rfcs)
 are provided at the top of the README to help you review what you are interested in.
 
 
 ## Commenting on an RFC
 [Commenting on an RFC]: #commenting-on-an-rfc
 
-Comments are the very heart of the RFC process. Comments are the primary way community 
-members and core team members can provide feedback and collaborate on the design 
-of a feature. 
+Comments are the very heart of the RFC process. Comments are the primary way community
+members and core team members can provide feedback and collaborate on the design
+of a feature.
 
-Comments should also be used to ensure the author has completed the RFC template 
-and addressed implications of the feature across the Ember project, including 
-documentation, addons, and tooling. 
+Comments should also be used to ensure the author has completed the RFC template
+and addressed implications of the feature across the Ember project, including
+documentation, addons, and tooling.
 
-Comments should be constructive and respectful, following our 
+Comments should be constructive and respectful, following our
 [Community Guidelines](http://emberjs.com/guidelines/).
 
 ## Creating an RFC
@@ -398,15 +398,15 @@ shepherding its progress. [Read more about the Champion's job](#champion-respons
 ## Implementing an RFC
 [Implementing an RFC]: #implementing-an-rfc
 
-Coordination and tracking of implementation of an RFC is done primarily on the 
+Coordination and tracking of implementation of an RFC is done primarily on the
 pull request to advance the RFC to the [Ready for Release] stage.
 
 The author of an RFC is not obligated to implement it. Of course, the
 RFC author (like any other developer) is welcome to work on the implementation.
 
 If you are interested in working on the implementation for an [Accepted]
 RFC, but cannot determine if someone else is already working on it,
-please ask (e.g. by leaving a comment on the pull request to advance the RFC to 
+please ask (e.g. by leaving a comment on the pull request to advance the RFC to
 the [Ready for Release] stage).
 
 ### Editing merged RFCs
@@ -423,7 +423,7 @@ about this feature." This note is not intended to be updated across time.
 - Updating any part of the RFC prose, in order to keep a written record of the
 changes and rationale.
 
-Major changes should have a new RFC. The old RFC is moved to the [Discontinued] 
+Major changes should have a new RFC. The old RFC is moved to the [Discontinued]
 stage when the replacement is merged.
 
 ## Reference
@@ -521,6 +521,11 @@ champion at any time.
 - [ ] Prepare for advancing the RFC to the next stage if applicable (e.g.
   opening a placeholder PR)
 
+For RFCs opened before the implementation of
+[Staged RFCs](https://github.com/emberjs/rfcs/blob/master/text/0617-rfc-stages.md)
+did not get advancement PRs to their next stage. See the
+[automations docs](https://github.com/emberjs/rfcs/blob/master/.github/READTHIS.md#trigger-opening-advancement-pryml) for instructions on how to trigger the advancement workflow.
+
 #### Move to FCP to Close
 - [ ] Achieve consensus to move to "FCP to Close" from relevant core teams
 - [ ] Comment in the RFC to explain the decision