Add missing frontmatter

text/0001-transform-attribute-meta-parameter.md

@@ -1,14 +1,18 @@
 ---
+Stage: Released
 Start Date: 2014-08-14
+Release Date: 2016-05-03
+Release Versions:
+  ember-data: v2.5.0
+Relevant Team(s): Ember Data
 RFC PR: https://github.com/emberjs/rfcs/pull/1
 Ember Issue: https://github.com/emberjs/data/pull/4086
-
 ---
 
 # Summary
 
 For Ember Data. Pass through attribute meta data, which includes `parentType`, `options`, `name`, etc.,
-to the transform associated with that attribute. This will allow provide the following function signiture updates to `DS.Transform`: 
+to the transform associated with that attribute. This will allow provide the following function signiture updates to `DS.Transform`:
 
 * `transform.serialize(deserialized, attributeMeta)`
 * `transform.deserialize(serialized, attributeMeta)`
@@ -66,10 +70,10 @@ App.MarkdownTransform = DS.Transform.extend({
   serialize: function (deserialized, attributeMeta) {
     return deserialized.raw;
   },
-  
+
   deserialize: function (serialized, attributeMeta) {
     var options = attributeMeta.options.markdown || {};
-    
+
     return marked(serialized, options);
   }
 });

text/0003-block-params.md

@@ -1,5 +1,10 @@
 ---
+Stage: Recommended
 Start Date: 2014-08-18
+Release Date: 2015-02-07
+Release Versions:
+  ember-source: v1.10.0
+Relevant Team(s): Ember.js
 RFC PR: https://github.com/emberjs/rfcs/pull/3
 Issues:
   Ember Stream support: emberjs/ember.js#5522

text/0003-cli-ember-doctor.md

@@ -1,5 +1,10 @@
 ---
+Stage: Accepted
 Start Date: 2015-01-10
+Release Date: Unreleased
+Release Versions:
+  ember-source: vX.Y.Z
+  ember-data: vX.Y.Z
 Relevant Team(s): Ember CLI
 RFC PR: https://github.com/ember-cli/rfcs/pull/3
 

text/0010-engines.md

@@ -1,5 +1,9 @@
 ---
+Stage: Released
 Start Date: 2014-10-24
+Release Date: FIXME
+Release Versions: FIXME
+Relevant Team(s): FIXME
 RFC PR: https://github.com/emberjs/rfcs/pull/10
 Ember Issue: https://github.com/emberjs/ember.js/pull/12685
 

text/0011-improved-cp-syntax.md

@@ -1,5 +1,9 @@
 ---
+Stage: Discontinued
 Start Date: 2014-09-30
+Release Date: FIXME
+Release Versions: FIXME
+Relevant Team(s): Ember.js
 RFC PR: https://github.com/emberjs/rfcs/pull/11
 Ember Issue: https://github.com/emberjs/ember.js/pull/9527
 

text/0012-help-json-output.md

@@ -1,5 +1,8 @@
 ---
+Stage: Released
 Start Date: 2015-05-16
+Release Date: FIXME
+Release Versions: FIXME
 Relevant Team(s): Ember CLI
 RFC PR: https://github.com/ember-cli/rfcs/pull/12
 

text/0015-the-road-to-ember-2-0.md

@@ -1,5 +1,10 @@
 ---
+# FIXME: Is this correct?
+Stage: Discontinued
 Start Date: 2014-12-03
+Release Date: FIXME
+Release Versions: FIXME
+Relevant Team(s): FIXME
 RFC PR: https://github.com/emberjs/rfcs/pull/15
 Ember Issue: This RFC is implemented over many Ember PRs
 
@@ -590,7 +595,7 @@ In order to do that refactoring, several things will change:
 * In addition to the asynchronous `model` hook in routes, routes will
   also be able to define a `attrs` hook, which can return additional
   asynchronous data that should be provided to the component.
-* Routeable Components should be placed in a "pod" naming convention. For 
+* Routeable Components should be placed in a "pod" naming convention. For
   example, the component for the `blog-post` route would be
   `app/blog-post/component.js`.
 

text/0020-sri-default.md

@@ -1,5 +1,8 @@
 ---
+Stage: Recommended
 Start Date: 2015-07-10
+Release Date: FIXME
+Release Versions: FIXME
 Relevant Team(s): Ember CLI
 RFC PR: https://github.com/ember-cli/rfcs/pull/20
 

text/0023-command-line-completion.md

@@ -1,4 +1,5 @@
 ---
+Stage: Accepted
 Start Date: 2015-08-18
 Relevant Team(s): Ember CLI
 RFC PR: https://github.com/ember-cli/rfcs/pull/23

text/0024-bound-attributes.md

@@ -1,5 +1,9 @@
 ---
-Start Date: 2014-11-26 
+Stage: Recommended
+Start Date: 2014-11-26
+Release Date: FIXME
+Release Versions: FIXME
+Relevant Team(s): Ember.js
 RFC PR: https://github.com/emberjs/rfcs/pull/24
 
 ---

text/0028-app-import-output-file.md

@@ -1,5 +1,9 @@
 ---
+# FIXME: This may be a further stage
+Stage: Accepted
 Start Date: 2015-11-02
+Release Date: FIXME
+Release Versions: FIXME
 Relevant Team(s): Ember CLI
 RFC PR: https://github.com/ember-cli/rfcs/pull/28
 

text/0029-addon-black-and-whitelist-for-apps.md

@@ -1,5 +1,9 @@
 ---
+# FIXME: This may be a further stage
+Stage: Accepted
 Start Date: 2015-11-11
+Release Date: FIXME
+Release Versions: FIXME
 Relevant Team(s): Ember CLI
 RFC PR: https://github.com/ember-cli/rfcs/pull/29
 

text/0045-internet-explorer.md

@@ -1,5 +1,10 @@
 ---
+# FIXME: Is this correct?
+Stage: Discontinued
 Start Date: 2015-06-07
+Release Date: FIXME
+Release Versions: FIXME
+Relevant Team(s): FIXME
 RFC PR: https://github.com/emberjs/rfcs/pull/45
 
 ---

text/0046-cli-improved-release-process.md

@@ -1,12 +1,15 @@
 ---
+Stage: Recommended
 Start Date: 2016-03-26
+Release Date: FIXME
+Release Versions: FIXME
 Relevant Team(s): Ember CLI
 RFC PR: https://github.com/ember-cli/rfcs/pull/46
 
 ---
 
 # Improved Release Process
- 
+
 ## Summary & Motivation
 
 ember-cli has followed an ad hoc release process throughout its existence which has made it difficult to know exactly when releases would come out, what features would and would not be supported, and the degree to which it would support existing Ember applications. With the proposal for lockstep SemVer there were ideals of guaranteeing compatibility, which we have mostly met, but that resulted in making decisions of delaying an official 2.X release of ember-cli to avoid additional major version bumps.
@@ -20,7 +23,7 @@ To begin there will be three separate channels: canary, beta, and release. We in
 - **Canary**: represents the latest work in ember-cli, and is synonymous with the `HEAD` of the `master` branch and is the least stable of all channels.
 - **Beta**: branched off of master every six weeks, exact commit decided upon manually. Updated and released weekly with commits that are prefixed `[BUGFIX beta]`. Less stable than `release` as it is a proving ground. No new features will be added once the branch has been created to allow for existing features to mature. Tags will match Ember's patterns, for example `v2.6.0-beta.1`. Branch name: `beta`.
 - **Release**: branched off of Beta every six weeks. Only rarely will this be updated, but possible for security issues and uncaught regressions. Branch name: `release`.
- 
+
 ember-cli will not support daily releases as time-based packaging doesn't make a lot of sense.
 
 ## New Features
@@ -49,7 +52,7 @@ In order to undertake this task, there are multiple workflows which must occur:
 - [ ] Teaching new patterns to ember-cli contributors, most specifically commit tagging and feature flagging.
 - [ ] Increased automation of the release process.
 - [ ] Tooling to support feature flags.
- 
+
 ## References
 
 - [Ember's Post-1.0 Release Cycle](http://emberjs.com/blog/2013/09/06/new-ember-release-process.html)

text/0046-registry-reform.md

@@ -1,5 +1,9 @@
 ---
+Stage: Recommended
 Start Date: 2015-04-09
+Release Date: FIXME
+Release Versions: FIXME
+Relevant Team(s): Ember.js
 RFC PR: https://github.com/emberjs/rfcs/pull/46
 Ember Issue: https://github.com/emberjs/ember.js/pull/11440
 

text/0050-cli-production-code-stripping.md

@@ -1,5 +1,8 @@
 ---
+Stage: Recommended
 Start Date: 2016-04-06
+Release Date: FIXME
+Release Versions: FIXME
 Relevant Team(s): Ember CLI
 RFC PR: https://github.com/ember-cli/rfcs/pull/50
 

text/0050-improved-actions.md

@@ -1,5 +1,9 @@
 ---
+Stage: Discontinued
 Start Date: 2014-05-06
+Release Date: FIXME
+Release Versions: FIXME
+Relevant Team(s): Ember.js
 RFC PR: https://github.com/emberjs/rfcs/pull/50
 
 ---

text/0053-helpers.md

@@ -1,5 +1,9 @@
 ---
+Stage: Recommended
 Start Date: 2015-05-17
+Release Date: FIXME
+Release Versions: FIXME
+Relevant Team(s): Ember.js
 RFC PR: https://github.com/emberjs/rfcs/pull/53
 Ember Issue: https://github.com/emberjs/ember.js/pull/11278
 

text/0055-anonymous-amd.md

@@ -1,5 +1,9 @@
 ---
+# FIXME: This may be a further stage
+Stage: Accepted
 Start Date: 2016-06-14
+Release Date: FIXME
+Release Versions: FIXME
 Relevant Team(s): Ember CLI
 RFC PR: https://github.com/ember-cli/rfcs/pull/55
 

text/0056-improved-release-cycle.md

@@ -1,5 +1,9 @@
 ---
+Stage: Recommended
 Start Date: 2015-10-02
+Release Date: FIXME
+Release Versions: FIXME
+Relevant Team(s): FIXME
 RFC PR: https://github.com/emberjs/rfcs/pull/56
 
 ---
@@ -8,8 +12,8 @@ RFC PR: https://github.com/emberjs/rfcs/pull/56
 
 Ember balances a desire for overall stability with a desire for continued improvements using a two-pronged approach:
 
-* General adherence to Semantic Versioning, which means that we don't 
-  make breaking changes to public, documented APIs except when the 
+* General adherence to Semantic Versioning, which means that we don't
+  make breaking changes to public, documented APIs except when the
   major version changes.
 * A rapid release cycle that allows us to ship additive changes to the
   framework on a regular, digestible basis.
@@ -43,13 +47,13 @@ Ember 2.0 is the first major release cycle where we have followed these refineme
 * New features are added predictably, and it's relatively easy to
   follow the list of new APIs that are under development, and where
   they are in the process.
-* There is little pressure for contributors to land a feature 
+* There is little pressure for contributors to land a feature
   prematurely, because missing a release deadline isn't
   catastrophic–there will be another train six weeks hence.
 * We have a lot of very good automation tools that keep the trains
-  running–commits can be (mostly) automatically backported to the 
+  running–commits can be (mostly) automatically backported to the
   current beta or release version.
-* Upgrading Ember itself from version to version is typically a quick 
+* Upgrading Ember itself from version to version is typically a quick
   process, except when private APIs are in use. We aim for upgrades to
   be possible to slot into existing product sprints, and the nature of
   the process means that we tend to hit this goal for most users.
@@ -64,10 +68,10 @@ The process of getting from *here* to *there* is a series of incremental release
 
 While the approach we're using has provided a lot of benefits, there are a number of areas that could still use improvement:
 
-* While it is in theory possible to upgrade only once every few 
+* While it is in theory possible to upgrade only once every few
   releases, there is no guidance about exactly how to do that, and
   little clarity about how many releases we plan to support with
-  security fixes. (Because of the two-step deprecations of heavily 
+  security fixes. (Because of the two-step deprecations of heavily
   used  private APIs, it is in practice important to go through each
   intermediate release to clear deprecation warnings before
   proceeding.)
@@ -83,7 +87,7 @@ While the approach we're using has provided a lot of benefits, there are a numbe
   churn in the experience of using Ember without actual breakages.
 * While deprecations technically don't force you to change anything,
   in practice clearing deprecations is a part of the upgrade process.
-  A constant stream of deprecations, like in the lead-up to Ember 2.0, 
+  A constant stream of deprecations, like in the lead-up to Ember 2.0,
   can feel almost as bad as breaking changes.
 * In the lead-up to Ember 2.0, a desire to remove as much cruft as
   quickly as possible led to a need to land new features with much
@@ -121,23 +125,23 @@ In theory, it's possible to upgrade every few releases, instead of every release
 
 This means:
 
-* We will only remove heavily used private APIs if they were 
+* We will only remove heavily used private APIs if they were
   deprecated in a previous LTS release. This means that
-  if a feature is deprecated in 2.3, the first LTS release that 
-  the deprecation will appear in is 2.4, and it can therefore be 
+  if a feature is deprecated in 2.3, the first LTS release that
+  the deprecation will appear in is 2.4, and it can therefore be
   removed in 2.5.
 * We will provide release notes for each LTS release that
   roll up the changes for the releases it includes, including new
   deprecations and new features.
-* We will use the LTS releases to provide better big-picture 
+* We will use the LTS releases to provide better big-picture
   messaging on the goals of any deprecations and changes to
   idiomatic Ember.
 * Security fixes will always be backported to the most recent
   LTS release.
 * We will encourage the Ember ecosystem to maintain support for
   the LTS releases, and lead by example with our own
   projects that have not yet reached SemVer stability. Ideally, this
-  will give more of a voice to people who are upgrading less 
+  will give more of a voice to people who are upgrading less
   frequently.
 
 This means that people who want to stay on the latest and greatest can continue to upgrade every six weeks (with the same SemVer guarantees we've come to expect), and people who want to upgrade less frequently can do so.

text/0057-ember-data-reference-unification.md

@@ -1,5 +1,10 @@
 ---
+# FIXME: This may be a further stage
+Stage: Accepted
 Start Date: 2015-05-20
+Release Date: FIXME
+Release Versions: FIXME
+Relevant Team(s): Ember Data
 RFC PR: https://github.com/emberjs/rfcs/pull/57
 Ember Issue: https://github.com/emberjs/data/pull/3303
 

text/0058-helper-listing.md

@@ -1,5 +1,9 @@
 ---
+Stage: Discontinued
 Start Date: 2015-05-24
+Release Date: FIXME
+Release Versions: FIXME
+Relevant Team(s): Ember.js
 RFC PR: https://github.com/emberjs/rfcs/pull/58
 Ember Issue: https://github.com/emberjs/ember.js/pull/11393