Proposal: reorganize feature planning

[jfbastien]

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?

[RyanLamansky]

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.

[domenic]

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.

[jgravelle-google]

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

[jfbastien]

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?

[domenic]

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?

[jfbastien]

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

[jfbastien]

@domenic added a table: 7467625
Which other fields do you think would be useful there?

[RyanLamansky]

@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

[jfbastien]

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

[sunfishcode]

The list of features with their implementation status is now published at

https://webassembly.org/features/

The CG now tracks all proposals at

https://github.com/WebAssembly/proposals/

The process for adding new features is now documentted:

https://github.com/WebAssembly/meetings/blob/main/process/phases.md

There's still the open question about what we do about FutureFeatures.md and other documents which are no longer used and now historical, but that's a separate topic.