Design: Proposal: reorganize feature planning

Created on 15 May 2017  路  9Comments  路  Source: WebAssembly/design

We currently track future features in a super ad-hoc manner:

  • In FutureFeatures.md
  • In random other files
  • In issues
  • In individual repos
  • In our heads

I'm volunteering to organize all of this, because it's madness. The current arrangement is impossible for casual WebAssemblers to understand, and I forget things all the time.

I propose:

  • File one issue per future feature.
  • Unless there's a repo for bigger features that are well along (or close the issue if so).
  • List prior discussions.
  • Rewrite FututreFeatures.md to point at the issue / repo, document the champion, and the Unicode identifier we're using to refer to the feature.

Importantly, I'd keep all post-MVP features which have been accepted, and document then date when added. Maybe at some point we'd do something like caniuse and document which engine implemented each feature fully, and when.

Thoughts?

Most helpful comment

To me the most important artifact here is a single document listing all in-development features, and linking to the place where they are being worked on. As long as that is present, everything else is just bonus.

All 9 comments

I suggest one issue for each future feature, even if it has it's own repo (in which case, the issue would have a link to the repo). Each future feature should be labeled as such. With this, you can have a direct link to a complete list of all future features. This link can be added to the site for easy discoverability.

To me the most important artifact here is a single document listing all in-development features, and linking to the place where they are being worked on. As long as that is present, everything else is just bonus.

What @RyanLamansky said, but with the requirement that any external artifacts (e.g. work repos) be linked in the top comment for easier searchability.

I opened #1073 and #1075 to track threads and SIMD, and I've removed them from FutureFeatures.md. Please take a look and let me know if the general structure is sensible. If so I'll proceed with all the other features that need to be tracked.

Once that's done I should also add an explanation of feature tracking somewhere... Probably the readme? Or FutureFeatures.md (which would be empty by then)? Or FeatureDetection.md?

and I've removed them from FutureFeatures.md.

Wait, but where do I go now to find a list of all future/in-development features?

I'll have a list there. Should have started already! Will do, sorry!

@domenic added a table: https://github.com/WebAssembly/design/commit/74676255fbc2d482d404cfe66c9ce4f072cc57a0
Which other fields do you think would be useful there?

@domenic @jfbastien As long as labels are used religiously, future features can currently be located with this URL, too: https://github.com/WebAssembly/design/labels/tracking

Right, but having a list on webassembly.org is also desirable. I guess we could auto-generate it.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

cretz picture cretz  路  5Comments

nikhedonia picture nikhedonia  路  7Comments

badumt55 picture badumt55  路  8Comments

thysultan picture thysultan  路  4Comments

dpw picture dpw  路  3Comments