Adding a document describing the phases through which a proposal will pass. #25

flagxor · 2017-07-06T15:17:00Z

No description provided.

rossberg

Looks good. It wouldn't harm to include some clarification about whose responsibility it is to push a proposal through the various stages. That is, the onus is on the "champion(s)" to do the work, or find other people to do it.

rossberg · 2017-07-06T15:41:04Z

process/phases.md

+  * A CG member has an idea.
+
+During this phase a new repository forking the spec repo is created (CG members
+can request this). PRs + Issues iterate on the design of the feature. If human


Nit: drop "human readable" (or replace with something else), since it implicates that the spec is not readable. ;)

rossberg · 2017-07-06T15:41:32Z

process/phases.md

+During this phase a new repository forking the spec repo is created (CG members
+can request this). PRs + Issues iterate on the design of the feature. If human
+readable design repo style .md files are useful, these are added to describe
+the feature as it's being designed. A tracking issue is created in the design


What is the role of the tracking issue?

WebAssembly/design#1066

It would be good to add a link here to the label: https://github.com/WebAssembly/design/labels/tracking

Added link.

jfbastien

Throughout, I'd spell out CG and WG fully.

jfbastien · 2017-07-07T17:49:35Z

process/phases.md

+Entry requirements:
+  * A CG member has an idea.
+
+During this phase a new repository forking the spec repo is created (CG members


There should be a step before this where someone just files a bug, and proposes something. Discussion ensues, and then people agree that the feature is worth going forward with and this happen.

I think we have to a degree assume goodwill from the champion (save genuine spam).
I.e. I would think that the bar should be pretty low if a CG member says they want a repo to develop a proposal in?
Perhaps some verbiage about no objection about confusion / spam / duplication?

It's not about goodwill. People who read this document coming in will think "hmm, I have to fork a thing... eh, don't care enough".

Ok, added a new step zero and incremented.

jfbastien · 2017-07-07T17:50:45Z

process/phases.md

+# WebAssembly W3C Process
+
+This file describes how feature proposals will progress through
+the standardization process.


I'd like to clarify what a "feature" is. Forking a repo is a super big overhead for bug fixes, and it isn't clear enough where the line is between fixing issues and creating a new feature.

I think we should require a proposal repo for everything that adds or changes a "feature". Criterions for that could be:

Adds an opcode or other pieces of abstract syntax

Changes or extends the binary format

Changes or extends the text format

Requires adding or changing tests

Requires extending or changing the reference interpreter.

Any of these implies that all conforming implementations are forced to be changed, which justifies going through a bit of process.

A "fix" on the other hand is something that e.g. is merely a clarification, and does not necessarily require implementations to change. That's perfectly doable as a simple PR.

Adopted those bullets.

jfbastien · 2017-07-07T17:51:48Z

process/phases.md

+During this phase a new repository forking the spec repo is created (CG members
+can request this). PRs + Issues iterate on the design of the feature. If human
+readable design repo style .md files are useful, these are added to describe
+the feature as it's being designed. A tracking issue is created in the design


WebAssembly/design#1066

It would be good to add a link here to the label: https://github.com/WebAssembly/design/labels/tracking

jfbastien · 2017-07-07T17:57:16Z

process/phases.md

+
+If relevant to demonstrate the viability of a feature, prototype
+implementations of the feature are implemented in interested engines (possibly
+on a branch).


I think the interesting thing here is to implement in:

An embedder

A toolchain

Some features would require both, some one, some neither.

Note that a browser engine is an embedder, but embedder can be non-browser as well. This is important. Some features don't necessarily need to be first prototyped in a browser.

So engine struck me as more clear, as embedder sounds relevant if the feature can wholely be done outside the core engine, but odd in reference to some part of the core format?
See below on the other variation on this.

"Embedder" is what we use elsewhere, so it's clear in the wider WebAssembly context.

jfbastien · 2017-07-07T17:57:29Z

process/phases.md

+## 1. Proposed Spec Text Available [CG/WG]
+
+Entry requirements:
+   * Full proposed english spec text available in a forked repo around which a


jfbastien · 2017-07-07T18:00:47Z

process/phases.md

+   * At least one toolchain implements the feature.
+   * The formalisation and the OCaml reference interpreter are usually updated
+     (though these two can be done as part of step 3 at the WG chair's discretion).
+     CG + general consensus has continued to this point (as throughout).


I'm not sure I understand what that means? I think what's missing is "Community Group is the sole venue where substantial work can occur." This should be stated at the beginning to clarify that iteration on the major design points of a feature are iterated on in the CG, but integrating it in the rest of the spec and getting the details right happen in the WG.

jfbastien · 2017-07-07T18:05:30Z

process/phases.md

+At this point the feature is fully handed off to the WG.
+During this phase, WG members discuss the feature, consider edge cases, and
+work towards consensus that the feature is now complete (kicking it back to an
+earlier stage in the CG if issues are uncovered).


I'd rephrase to: Unless substantial work is deemed required (in which case the feature is sent back to the Community Group).

reworded similarly.

jfbastien · 2017-07-07T18:06:15Z

process/phases.md

+## 3. Standardize the Feature [WG]
+
+Entry requirements:
+   * Two or more Web VMs implement the feature.


I think we also need some signal from others that there's interest in implementing. I think it's another one of those "the Chair decides what looks like consensus, but if people consistently feel like the Chair ignores them then things will break down".

So the last bullet was meant to cover the consensus issue (it was missing the bullet tag). I've also added a parenthetical regarding the chair's role in this.
I think the point of the two WebVM bar was that in addition to consensus, there should be track record with the feature working on the Web, given the Web's higher bar for compatibility etc., as we want to make sure the feature will eventually be universal.
Again, curious what others think on this point?

jfbastien · 2017-07-07T18:07:49Z

process/phases.md

+into master on the spec repo.
+The W3C snapshots (for REC) are made at a regular cadence (in a W3C repo), used
+to stamp official version. Matching tags are added in the github spec repo.
+The feature is enabled on stable by various browsers, converging on all.


Is this worth mentioning? People can just ship stuff if they want, so that clause doesn't really mean much.

Domenic and others brought this one up, and my understanding is that these tags + versions carry special legal weight in terms of patent exclusion periods etc. (But I am not a lawyer).

That seems unrelated to "enabled on stable by various browsers", no?

Ah, wrong line. Yes, dropped.

jfbastien · 2017-07-07T18:08:12Z

process/phases.md

+
+The spec and spec forks will move to a W3C Documents and Software License.
+Other related repos for prototypes + tools will continue under their respective
+licenses.


Point to the actual license files.

flagxor · 2017-07-07T23:13:58Z

PTAL

jfbastien · 2017-07-08T06:53:14Z

I replied to a bunch of comments. Not sure GitHub shows all the replies unless you expand "outdated" comments.

jfbastien · 2017-07-28T16:43:06Z

Ping? There are still some (now hidden) comments which need to be addressed.

flagxor · 2017-08-16T23:37:28Z

PTAL

lukewagner · 2017-08-17T15:04:25Z

Could we perhaps identify a clear point in the process where the CG (and/or WG?) gives a "green light" for browsers to start shipping (on-by-default) their implementation of a feature? This would seem to be somewhere in the middle of Step 4. I was also thinking it might be useful if this event produced some sort of linkable artifact, analogous to the MVP email.

jfbastien · 2017-08-17T20:40:10Z

If we do this "green-light" thing, we need a phase when we say "do ship if you want, but it may break", and then we need to specify when we intend to keep compatibility as much as possible (I assume that's when it's in the spec).

lukewagner · 2017-08-17T21:06:04Z

Ah, that's slightly different than what we messaged with the MVP email (which was that minor stuff might change, but only in minor ways that shouldn't break content in the wild). That's sortof what green light means, at least to me.

jfbastien · 2017-08-17T21:09:11Z

I think we might want to do discuss this addition in a video call, to be sure that everyone is on board with it. Agreed that the distinction you make from what I said is important.

Regardless of which way we go, the last bit I propose (when is it set in stone, except for force majeure) is still something I'd like in there.

@flagxor do you think this would be ready to discuss at next Tuesday's meeting? I think this entire document needs to be more or less ready to go by then.

flagxor · 2017-09-12T17:16:20Z

Reluctant to map to "recommended ship" until we've discussed.
Would a WG discussion on the topic be useful?
Any other changes. Perhaps we could checkpoint this if I added a DRAFT tag on top?

jfbastien · 2017-09-13T15:20:14Z

I think this should be a CG discussion, since it discusses how the CG's work is used. Can you add it to the agenda? Fine by me to commit with DRAFT notice, and pointer to the scheduled discussion.

… pass.

flagxor · 2017-09-14T17:29:24Z

sgtm

flagxor requested review from jfbastien, MikeHolman and lukewagner July 6, 2017 15:17

rossberg reviewed Jul 6, 2017

View reviewed changes

jfbastien reviewed Jul 7, 2017

View reviewed changes

flagxor requested a review from titzer July 7, 2017 23:13

flagxor force-pushed the phases branch from b43c23e to 74e2941 Compare July 7, 2017 23:13

flagxor force-pushed the phases branch 4 times, most recently from 3a63ab9 to 4235210 Compare August 16, 2017 23:37

jfbastien mentioned this pull request Sep 8, 2017

Adding a WG meeting. #66

Merged

Add WG items.

a0a5aea

Adding a document describing the phases through which a proposal will…

6006343

… pass.

flagxor force-pushed the phases branch from 4235210 to 6006343 Compare September 14, 2017 17:29

flagxor merged commit b9edb7f into WebAssembly:master Sep 14, 2017

flagxor deleted the phases branch September 14, 2017 17:29

Adding a document describing the phases through which a proposal will pass. #25

Adding a document describing the phases through which a proposal will pass. #25

Conversation

flagxor commented Jul 6, 2017

rossberg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jfbastien left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rossberg Jul 10, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

flagxor commented Jul 7, 2017

jfbastien commented Jul 8, 2017

jfbastien commented Jul 28, 2017

flagxor commented Aug 16, 2017

lukewagner commented Aug 17, 2017

jfbastien commented Aug 17, 2017

lukewagner commented Aug 17, 2017

jfbastien commented Aug 17, 2017

flagxor commented Sep 12, 2017

jfbastien commented Sep 13, 2017

flagxor commented Sep 14, 2017

rossberg Jul 10, 2017 •

edited

Loading