WIP: Setup a Features dashboard to show upcoming feature flags

[acorncom]

I noticed a Dashboard page that @wycats built earlier this year (https://github.com/emberjs/website/blob/master/source/dashboard.html.erb) but it looks like it never got fully implemented.

This pull request picks up where he left off and moves it in under the Builds area of the website:

My main question before I work on this much further is: is this something we actually want to do? Did it get left undone due to lack of time or did the core team decide it shouldn't happen?

If we want it to happen, I'll enjoy messing around here a bit :-)

[rwjblue]

I think we generally want it, and it was dropped due to lack of time.

I'm also a tad concerned with upkeep after the initial push is done. It would be unfortunate to have a nice page with these details that never gets updated. Definitely looking for folks to help with this sort of thing....

[acorncom]

I'm also a tad concerned with upkeep after the initial push is done. It would be unfortunate to have a nice page with these details that never gets updated

Agreed. Seems like this is only useful if it doesn't add more work to your workflow. I'd been thinking of doing Ajax calls back to Github to retrieve the features.json file from the various branches, but would need meta info (primarily a description and probably the original pull request / rfc). Is there some way we can shoehorn that into the features.json file without breaking the rest of our infrastructure?

I'd wondered about doing this In features.json:

{
  "features": {
    "features-stripped-test": {
        "description": "Stripping out features, a cool description",
        "pr": 9311,
    },
    "ember-htmlbars-component-generation": null,
    "ember-testing-checkbox-helpers": null,
    "ember-application-visit": null,
    "ember-routing-route-configured-query-params": null,
    "ember-libraries-isregistered": null,
    "ember-debug-handlers": true,
    "ember-routing-routable-components": null,
    "ember-metal-ember-assign": null,
    "ember-contextual-components": null
  }
}

What I would hope is that the feature system would be able to continue doing it's true / false comparisons while allowing us to read more meta data as desired.

Do you think that'd be doable or will that break a ton of things?

[mixonic]

FWIW features already have descriptions at https://github.com/emberjs/ember.js/blob/master/FEATURES.md

[acorncom]

Good point on those features being there. I was hoping to not have to parse Markdown in order to display things on that dashboard though ;-) Think that'd be best or can we wangle this some other way?

[wycats]

@acorncom we've talked about changing the format of FEATURES.md to make it easier to parse. Thoughts?

[wycats]

@acorncom incidentally, we had already designed an improved dashboard that maybe you want to take a crack at (thanks @thoughtbot).

[wycats]

It would probably make sense for the timeline to be in reverse order (most recent on the top).

[wycats]

Also, putting the features in features.json means we can't remove them from features.json once they're merged. We likely want a history.json (or perhaps, 😲 XML) that has the full history of features including when they were merged.

[acorncom]

Question regarding the dashboard design. Per @locks on this pull request (at the bottom), the thoughtbot redesign for the guides looks different than the design for the builds page. Are we keeping a common header across the various pages or are these pages going to look different?

[acorncom]

Re: where to retrieve data. I can pull from FEATURES.md on various branches if we agree on a specific format. But that seems prone to breakage unless people are being quite careful.

But I'd prefer using a history.json file if that's doable logistically and doesn't add more tedious overhead. Having it might also open up other integrations for other sites down the road ...

[acorncom]

Two other questions:

• we currently a far more elaborate "Builds" page than is shown on the redesign page. Would we be throwing the "Tagged Releases" and various channels / links away in the process? From what I've gathered, @rwjblue uses that heavily :-)
• do we want to continue building this page in the Ember globals app that we're using now or should we shift that to an Ember-CLI app? If shifting to an Ember-CLI app, should we be aiming for that app to also replace the "About", "Community" and other pages or should we wait on that so we don't affect SEO?

[rwjblue]

we currently a far more elaborate "Builds" page than is shown on the redesign page. Would we be throwing the "Tagged Releases" and various channels / links away in the process? From what I've gathered, @rwjblue uses that heavily :-)

Ya, we will have to have a way to see past versions (but it might be included in another page).

do we want to continue building this page in the Ember globals app that we're using now or should we shift that to an Ember-CLI app? If shifting to an Ember-CLI app, should we be aiming for that app to also replace the "About", "Community" and other pages or should we wait on that so we don't affect SEO?

Yes, the builds page should move to an ember-cli app that is built then copied into the current website upon deploy. I do not think it should incorporate other sections, but don't feel super strongly about this.

[locks]

I am closing this issue because I'm mostly done porting the builds page into an Ember CLI application, and this should be moved into our internal tracking until we actually start work on it.
Feel free to re-open the issue if you think it's still justified, thank you!