Skip to content
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

Open
jfbastien opened this issue May 15, 2017 · 9 comments
Open

Proposal: reorganize feature planning #1066

jfbastien opened this issue May 15, 2017 · 9 comments
Assignees

Comments

@jfbastien
Copy link
Member

jfbastien commented May 15, 2017

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?

@jfbastien jfbastien self-assigned this May 15, 2017
@RyanLamansky
Copy link

RyanLamansky commented May 15, 2017

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
Copy link
Member

domenic commented May 15, 2017

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
Copy link

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 added a commit that referenced this issue May 23, 2017
Now tracked here: #1073
As discussed here: #1066
jfbastien added a commit that referenced this issue May 23, 2017
Now tracked by: #1075
As discussed here: #1066
@jfbastien
Copy link
Member Author

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
Copy link
Member

domenic commented May 23, 2017

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
Copy link
Member Author

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

@jfbastien
Copy link
Member Author

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

@RyanLamansky
Copy link

@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
Copy link
Member Author

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

jfbastien added a commit that referenced this issue May 25, 2017
Tracked by #1077
As discussed here: #1066
jfbastien added a commit that referenced this issue May 25, 2017
Now tracked by: #1078
As discussed here: #1066
jfbastien added a commit that referenced this issue May 25, 2017
Now tracked by: #1079
As discussed here: #1066
jfbastien added a commit that referenced this issue May 25, 2017
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.
jfbastien added a commit that referenced this issue Jun 2, 2017
Now tracked by: #1087
As discussed here: #1066
jfbastien added a commit that referenced this issue Jul 13, 2017
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants