(In reply to comment #0)
> Aryeh Gregor writes:
> In particular, I'd like to know whether the
> editor will remain free to make substantive changes provided they
> prove uncontroversial

It is difficult to establish that a given change is "uncontroversial" if there is no prior discussion or even simple notification to the Working Group prior to the change being made.

I would consider a bug report to be sufficient for notification provided that sufficient opportunity was provided for people to comment on the bug.  As an example of an avoidable problem, bug 11984 is an example of where a bug was opened and resolved on the same day (in fact, within 90 minutes) resulting in the chairs needing to involve a rather heavyweight multi-day process to cause a revert.

By "provided they prove uncontroversial", I meant to imply that if they proved uncontroversial ex post facto, they could be left in with no procedural qualms even if there was no bug filed.  If someone objected, they could be reverted after the fact.  This simply makes it simpler to change the spec in the fairly common case that the editor can predict in advance that the change will be uncontroversial.  If he's wrong sometimes, there's no harm done -- he can be asked to revert it.  As long as a large majority of changes are uncontroversial, which I believe has historically been the case, this optimizes for the common case and saves effort overall.  By contrast, requiring up-front discussion across the board adds process burden even in the large majority of cases where it won't change anything.

This bug seems related to bug 12029 and bug 12675. I'll see if I can address this while processing those.

My proposed resolution to one of the other bugs is here:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12029#c9

Via other bugs the text now makes clear that any feature addition should preferably be preflighted with the WG, and any feature addition (even where its feature status is debatable) could be subject to a revert request. Anything that no one objects to will not get reverted.

In that sense, any change is ok as long as it proves uncontroversial ex post facto (no one asks to revert), but we strongly recommend that anything which is even arguably a feature addition, even to document longstanding legacy APIs, should be suitably preflighted with the group. Not just in a letter-of-the-law way but a bug or mailing list post with fair opportunity for comments.

I think this is now clear enough from the rest of the policy. If my co-chairs agree, my resolution would be to simply remove the remaining FIXME. I'd also like to give Aryeh a chance to comment on whether his concerns are addressed now.

My concerns are addressed by the current text, as long as no one takes it upon themselves to review all diffs and object on principle to anything they think is a feature addition or removal.  The current text would appear to permit this, since it suggests there's a blanket ban on feature additions/removals and doesn't require anyone to object to the addition or removal itself.

I would prefer it if the policy said that the chairs would normally not make a revert request unless someone objected to the technical substance of the commit.  To be clear, I'm not saying that they should have to provide any rationale -- "I don't think this is a good feature" would be good enough for me.  But not an objection solely on procedural grounds, or based on the hypothetical possible existence of someone who might not like the change.  For instance, Sam Ruby's complaint about the addition of an atob/btoa spec was not grounded in an assertion that he or anyone else had an actual problem with the feature.

Still, I can live with this policy as long as no one systematically requests the revert of large classes of new changes.

(In reply to comment #5)
> 
> I think this is now clear enough from the rest of the policy. If my co-chairs
> agree, my resolution would be to simply remove the remaining FIXME.

+1

- Sam Ruby

http://lists.w3.org/Archives/Public/public-html-comments/2011Jun/0023.html
http://lists.w3.org/Archives/Public/public-html-comments/2011Jun/0024.html
http://lists.w3.org/Archives/Public/public-html-comments/2011Jun/0025.html

Related: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16481#c1

Per bug 16481, we are considering a blanket ban on features, without prior WG approval.

In order to close down on the spec, we may need to eliminate changes that happen entirely outside the process, i.e. without even a bug. Updating title to: "Starting with LC2 or perhaps before, all changes need to be associated with a duly filed LC2 or earlier bug"

Created attachment 1112 [details]
Diff implementing a bug for every change requirement for LC2 and later

(In reply to comment #11)
> Created attachment 1112 [details]
> Diff implementing a bug for every change requirement for LC2 and later

s/tobugs/to bugs/

Modulo this typo: +1

Created attachment 1117 [details]
v2 fixing the typo

Based on <http://dev.w3.org/html5/decision-policy/html5-2014-plan.html>, this proposal should reflect CR instead of LC2.

Closed (superceeded by time). To reopen, please file an issue here:
https://github.com/w3c/html/issues