-
Notifications
You must be signed in to change notification settings - Fork 694
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: reorganize feature planning #1066
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? |
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 @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. |
We should removing GC.md as part of #1066. It's more aspirational that concrete, and we're now tracking GC work with #1079 as well as in https://github.com/WebAssembly/gc/. Caveat before removing this: * Other pages link to it. I'll clean up. * Some of the content may still be valid. We should move it to the GC proposal instead so it doesn't become stale.
We should removing GC.md as part of #1066. It's more aspirational that concrete, and we're now tracking GC work with #1079 as well as in https://github.com/WebAssembly/gc/. Caveat before removing this: * Other pages link to it. I'll clean up. * Some of the content may still be valid. We should move it to the GC proposal instead so it doesn't become stale.
We currently track future features in a super ad-hoc manner:
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:
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?
The text was updated successfully, but these errors were encountered: