Advance RFC #0617 to Stage Ready for Release

[wagenet]

Advance #617 to the Ready For Release Stage

Summary

RFC-617 has been Accepted but remains mostly unimplemented. Since it details how we should implement Staged RFCs, it should, itself, be the first to go through the process.

This pull request is advancing the RFC to the Ready For Release Stage.

• PR to Accepted Stage: RFC Stages #617

An FCP is required before merging this PR to advance.

Ready for Release Stage Description

This stage is complete when the implementation is complete according to plan outlined in the RFC, and is in harmony with any changes in Ember that have occurred since the RFC was first written. This includes any necessary learning materials. At this stage, features or deprecations may be available for use behind a feature flag, or with an optional package, etc.

For codebase changes, there are no open questions that are anticipated to
require breaking changes; the Ember team is ready to commit to the stability of
any interfaces exposed by the current implementation of the feature.

This stage should include a list of criteria for determining when the proposal can be considered Recommended after being Released.

An FCP is required to move into this stage.

Each Ember core team will be requested as a reviewer on the PR to move into this stage. A representative of each team adds a review. If a team does not respond to the request, and after the conclusion of the FCP, it is assumed that the release may proceed.

Actions

• Implementation is complete according to plan outlined in the RFC
• Any necessary learning materials have been updated
• The Ember team is ready to commit to the stability of
  any interfaces exposed by the current implementation of the feature
• Criteria for moving to Recommended Stage has been filled out
• Each team has reviewed and approved

Criteria for moving to Recommended (required)

A set of criteria for moving this RFC to the Recommended Stage, following release:

1. The stage of previously merged PRs back a reasonable amount of time has been verified and PRs to advance have been opened where necessary.

Track Implementation

• Write Blog Post (@kategengler): Blog post to announce addition of stages to the RFC Process ember-learn/ember-blog#1237
• Update stages and release dates: Add missing frontmatter, including stages #835
• Update README and templates: Update the README add RFC Stages #663
• Merge Update RFCs link ember-learn/ember-website#972
• Merge Designate rfcs.emberjs.com as the source of truth for RFCs ember-learn/guides-source#1863
• Update rfcs.emberjs.com to handle stages correctly: Support Staged RFCs ember-learn/rfcs-app#10
• Determine format for tracking these PRs in the frontmatter: [RFCs App Rendering] Reformat frontmatter #833
• Automations for next stage PRs: Add a workflow to open a PR to the next stage when the stage of an RFC has been updated #844

Before Merge

• Merge Add a workflow to open a PR to the next stage when the stage of an RFC has been updated #844.
  • make checks for newly opened RFCs required. They will pass on PRs that do not add an RFC.

On Merge

• Publish Blog post: Blog post to announce addition of stages to the RFC Process ember-learn/ember-blog#1237
• Merge Update the README add RFC Stages #663.
• Watch to see that a PR opened by the workflows added in Add a workflow to open a PR to the next stage when the stage of an RFC has been updated #844 is opened to move this RFC to 'Released'

[kategengler]

Nice to haves: Labels for each stage PR, templates for each stage PR (especially Ready for Release with a section for a checklist for criteria for recommended).

[wycats]

Do we want an RFC template for the recommended stage (similar to how we have a separate RFC template for deprecation)?

I was thinking it may make sense to have a dedicated document that focuses primarily on the teaching, migration and communication goals that are required for "Recommended".

We could just amend the existing RFC (I think that's roughly what #617 envisions), of course. That said, I was thinking it may be useful to have a separate "Action Plan" document that's similar to the kind of action plan we do for implementation.

[wagenet]

@wycats do you mean like what is in here #844?

[kategengler]

Pulling my reply from Discord:

The way we have designed it, stages has the same RFC move through and get modified along that way. Perhaps sections of the RFC that have instructions to be filled out by the time it gets to Recommended?
There are templates in the automation for the PRs that get opened. For example this is what a PR to recommended will look like when first opened kategengler/playground-ghas#32

[wycats]

@kategengler makes sense to me! Mostly what I'm thinking about is that the process to go from stable to recommended requires an action plan, and I was wondering if there's an obvious way to incorporate that action plan into an existing step.

I see that the advance-to-ready-for-release.md PR has "Criteria for moving to Recommended". Maybe we could copy the criteria into a draft advance-to-recommended.md PR that would serve as a tracking issue and could be updated as the plan evolves?

[kategengler]

That is what I would imagine would happen -- the template for the draft advance-to-recommended PR (that will automatically open once the stage is advanced to released) mentions the criteria in the Actions todo list. It'd be nice to have the workflow automatically move the criteria between the PRs, but that would be a little tricky so I think for now leaving it to the person shepherding the PR to paste in those criteria (prompted by that Actions list) and evolve them is ok.

[dfreeman]

TypeScript Core is 👍

[kategengler]

Approving for CLI

[ef4]

Approving for framework-core.

[jenweber]

The learning team meets on Monday, when we can do an official approval.

As the author of the RFC and an individual, this looks good to me!

[jenweber]

Approved for the Learning Team. We discussed it at today's meeting. Thanks all for moving this forward!

[runspired]

👋🏻 Approving for the Data team

I think labels as Katie suggested are probably the most useful thing to go with this RFC. Folks generally seem to scan the original RFC PRs and having the status label available is instant highly findable feedback. A little automation to go with those labels would be neat too but not required and since labels are pretty low overhead to create and apply this should be pretty easy for us to achieve.

[kategengler]

@runspired The labels and automation did end up implemented in #844. Proposed RFCs open as usual with the template and manually, then are automatically labeled as S-Proposed. It has to have that label removed and S-Exploring added to move to the Exploring stage. Merge to move to the accepted stage. On merge, it will automatically open a draft PR to move the RFC to Ready for Release and PR will be labeled S-Ready-for-Release. When that merges, it will automatically open a draft PR to Released, and then when that merges, automatically open a draft PR to Ready for Release.

The draft PR is intended to be used for coordination and as a tracking issue for getting to that next stage. All this is outlined in the new Readme that will merge when this is released.

[kategengler]

The FCP has been completed! We will be merging and releasing stages now.