This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12029 - Define a process for "particularly exceptional circumstances"
Summary: Define a process for "particularly exceptional circumstances"
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: working group Decision Policy (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-10 13:02 UTC by Sam Ruby
Modified: 2011-05-30 21:30 UTC (History)
10 users (show)

See Also:


Attachments

Description Sam Ruby 2011-02-10 13:02:45 UTC
In September, we established a "Enhanced change control after the Last Call cutoff"[1], and in it we used the words "new features should not be added after the cutoff, except in particularly exceptional circumstances."  These words were meant to convey the notion of there being a fairly high bar for new features at this time.

The cut-off for bugs to be considered as pre-LC feedback was in October[2], and yet well after that time we have had substantial changes that were made that ranged from controversial[3] to mundane[4].  This is continuing[5], often without any discussion at all occurring in the W3C HTML WG.

This is inconsistent with the notion of driving to a schedule.  This not only affects our ability to get to Last Call, but also CR, PR, and ultimately Rec.  At a minimum, we have members depending on us achieving these milestones in order to establish that this specification is IP clean.

Independent of the resolution of any of these particular changes, we need to make explicit the notion of what "particularly exceptional circumstances" means going forward, and in the process make it clear what the bar is for adding new features.

[1] http://lists.w3.org/Archives/Public/public-html/2010Sep/0125.html
[2] http://lists.w3.org/Archives/Public/public-html/2010Sep/0074.html
[3] http://lists.w3.org/Archives/Public/public-html/2011Feb/0114.html
[4] http://lists.w3.org/Archives/Public/public-html-diffs/2011Feb/0005.html
[5] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/030161.html
Comment 1 Ian 'Hixie' Hickson 2011-02-10 19:44:26 UTC
Oops, my bad. I didn't mean to include window.atob() in the W3C copy. Will take care of that.

Re [3], not sure what you mean. You specifically said to open a new bug on the topic [6], and the policy [2] states that a "UA behavior bug" is likely to be fine, so I fixed it. I'm happy to revert it in the W3C copy if you think that's the right thing to do (in fact I mentioned on IRC that I expected that would happen). Let me know what I should do there.

I haven't looked at [5] yet, so I doubt it has resulted in any change to the spec, so presumably there's nothing for me to do there either.

[6] http://lists.w3.org/Archives/Public/public-html/2011Jan/0415.html
Comment 2 contributor 2011-02-10 19:45:57 UTC
Checked in as WHATWG revision r5867.
Check-in comment: remove window.atob/btoa from the W3C draft
http://html5.org/tools/web-apps-tracker?from=5866&to=5867
Comment 3 Aryeh Gregor 2011-02-11 15:36:30 UTC
I don't think atob() and btoa() qualify as "new features".  They've been implemented interoperably for years by all browsers other than IE, and the spec merely codifies existing behavior.  They're extremely unlikely to be controversial, since the functions are very simple and the definitions given in the spec differ from how current browsers work only insofar as they standardize error handling.  Removing the definitions from the spec now will only delay interop on an existing feature.  In particular, I wrote thorough tests for the spec with the intent to submit them to the HTMLWG test repo, and now I have nowhere to submit them.

So I would like to ask you (Sam) for clarification on whether, given the above, you think atob() and btoa() need to be removed from the spec.  If you do, then I'd like to ask that either you confer with Paul and Maciej and officially ask Ian to keep them removed, or that Ian re-add them, since the original e-mail clearly said that features would only have to be removed if the chairs (not just one chair) requested it.


Additionally, when this bug is officially handled, I'd like clarification specifically on whether full specification of editing commands <http://dev.w3.org/html5/spec/dnd.html#editing-apis> would count as a "new feature", since I'm now working on that.  It would be a lot of new spec text, but again, just standardizing an existing feature (where we have very little interop).  It's the sort of thing that would probably have to be tweaked a lot in response to implementer feedback, but I don't see it as likely to raise objections as long as it's just standardizing existing behavior.

If standardization of editing APIs is considered too large a change to make now, I'd like to hear plans on how and when this sort of thing can be considered again.  It should be obvious that we don't want a huge gap where no new features are added to HTML a la HTML 4.  The spec text can always be submitted at the WHATWG, but there would be no central place to submit tests (unless we want the WHATWG to fork the W3C's tests, which I'm not even sure the license would allow).
Comment 4 Sam Ruby 2011-02-11 16:02:48 UTC
(In reply to comment #3)
> I don't think atob() and btoa() qualify as "new features".  They've been
> implemented interoperably for years by all browsers other than IE, and the spec
> merely codifies existing behavior.  They're extremely unlikely to be
> controversial, since the functions are very simple and the definitions given in
> the spec differ from how current browsers work only insofar as they standardize
> error handling.  Removing the definitions from the spec now will only delay
> interop on an existing feature.  In particular, I wrote thorough tests for the
> spec with the intent to submit them to the HTMLWG test repo, and now I have
> nowhere to submit them.

I intentionally used the word mundane as I did not think that the topic itself is likely to be controversial; what I intended to focus on in this defect is the process flaw in that apparently we (the chairs) weren't clear what the bar is.
 
> So I would like to ask you (Sam) for clarification on whether, given the above,
> you think atob() and btoa() need to be removed from the spec.  If you do, then
> I'd like to ask that either you confer with Paul and Maciej and officially ask
> Ian to keep them removed, or that Ian re-add them, since the original e-mail
> clearly said that features would only have to be removed if the chairs (not
> just one chair) requested it.

I did not ask for Ian to remove it, and therefore will not ask him to re-add it.

> Additionally, when this bug is officially handled, I'd like clarification
> specifically on whether full specification of editing commands
> <http://dev.w3.org/html5/spec/dnd.html#editing-apis> would count as a "new
> feature", since I'm now working on that.  It would be a lot of new spec text,
> but again, just standardizing an existing feature (where we have very little
> interop).  It's the sort of thing that would probably have to be tweaked a lot
> in response to implementer feedback, but I don't see it as likely to raise
> objections as long as it's just standardizing existing behavior.
> 
> If standardization of editing APIs is considered too large a change to make
> now, I'd like to hear plans on how and when this sort of thing can be
> considered again.  It should be obvious that we don't want a huge gap where no
> new features are added to HTML a la HTML 4.  The spec text can always be
> submitted at the WHATWG, but there would be no central place to submit tests
> (unless we want the WHATWG to fork the W3C's tests, which I'm not even sure the
> license would allow).

What goes into the spec is up to the Working Group to decide.  What I will say is that if it is discussed with the working group, and nobody objects, then I certainly wont.  Note: I am *not* suggesting that discussion ceases to occur elsewhere.  All I am saying is that if you want something to appear in a W3C spec, it probably is a good idea to actually discuss your ideas with the associated Working Group.

At a barest minimum, I suggest that you open a bug on each of these topics.  At a minimum, you will be guaranteed an editors response and the opportunity to take issue with that response.
Comment 5 Ian 'Hixie' Hickson 2011-02-11 19:21:35 UTC
Sam, your vague responses are infuriatingly unhelpful and not effective group leadership nor conducive to efficient use of the working group members' time.

> I did not ask for Ian to remove it, and therefore will not ask him to re-add
> it.

I'm going to assume this is Sam-speak for "atob() and btoa() are not examples of things that fall into the category of things that the enhanced change control e-mail applies to, despite it having been listed as an example of such in comment 0", and will re-add this feature.

It would be lovely if in the future you could be clearer about what you actually want. Thanks.
Comment 6 contributor 2011-02-11 19:42:40 UTC
Checked in as WHATWG revision r5874.
Check-in comment: revert 5867, which was apparently based on a miscommunication
http://html5.org/tools/web-apps-tracker?from=5873&to=5874
Comment 7 Sam Ruby 2011-02-11 19:44:11 UTC
(In reply to comment #5)
> Sam, your vague responses are infuriatingly unhelpful and not effective group
> leadership nor conducive to efficient use of the working group members' time.

You want me to be clear?  Fine.  I got an email from somebody asking me the origin of this feature.  After investigating, I found that it was added to the W3C draft well after after the cut-off, and furthermore to date I have found absolutely no evidence that there was any discussion in the W3 working group about this feature.
 
> > I did not ask for Ian to remove it, and therefore will not ask him to re-add
> > it.
> 
> I'm going to assume this is Sam-speak for "atob() and btoa() are not examples
> of things that fall into the category of things that the enhanced change
> control e-mail applies to, despite it having been listed as an example of such
> in comment 0", and will re-add this feature.

I did not say anything remotely like that.  The chairs are still discussing this, and may very well come to a different conclusion.
 
> It would be lovely if in the future you could be clearer about what you
> actually want. Thanks.

What I want: features added to the W3C draft to be discussed by the W3C WG.  Given that we have bugzilla notification routed to public-html, this can be as simple as requesting that any new feature be recorded in bugzilla.
Comment 8 Ian 'Hixie' Hickson 2011-02-11 21:57:33 UTC
That isn't how our charter works. It specifically says "We expect that typically, an editor makes an initial proposal". That's all that happened here. I made a proposal to the W3C HTML working group, as per the group's charter.
Comment 9 Maciej Stachowiak 2011-02-17 11:31:33 UTC
To address this bug, I propose language something like the following, to be added in a new "Last Call" section of the decision policy document. This is just a rough take, it probably needs to be cleaned up to be generic to any WG draft.

-------

As we move through W3C maturity levels, the process requires gradually locking down the spec. In particular:

* If substantial technical changes are made after a Last Call Working Draft, then the Working Group cannot proceed to Candidate Recommendation and must publish another LCWD. While it is not entirely clear what kinds of changes are substantial enough, it seems like feature additions, or for that matter feature removals, probably are.

* During Candidate Recommendation, if anything beyond very minor technical changes are made, other than dropping features marked "at risk", then the WG cannot proceed to Proposed Recommendation and must return to Working Draft status.

Given these rules, it seems wise to be careful about anything that is even arguably a feature addition - even arguably ambiguous cases such as documenting longstanding de facto standard features.

Thus, the Chairs propose that during the current pre-LC period, and during Last Call, feature additions or removals should only be done with sufficient prior notice to the group, in the form of a bug. We are not making bug filing mandatory for editorial changes or even technical changes that correct an error. We're also not trying to put any constraint on the WHATWG HTML draft. From the W3C HTML WG point of view, it is reasonable to add a feature to WHATWG HTML but then not propose it for inclusion in W3C HTML5 at all, if it is not ready to go through a stabilization cycle. It is also ok to put such features in other drafts. However, in order to fulfill process requirements, we can't have features freely added to the W3C draft without sufficient advance notice.
Comment 10 Sam Ruby 2011-02-17 13:51:06 UTC
(In reply to comment #9)

Generally +1

> Thus, the Chairs propose that during the current pre-LC period, and during Last
> Call, feature additions or removals should only be done with sufficient prior
> notice to the group, in the form of a bug. 

If we can trust people to operate in good faith, I am OK with us not elaborating on this further, as long as it is widely understood that the following proposal does not constitute "sufficient prior notice":

http://krijnhoetmer.nl/irc-logs/whatwg/20110211#l-1532

> We are not making bug filing
> mandatory for editorial changes or even technical changes that correct an
> error.

I'd like the bar a little higher than that: I suggest that any change that affects an approved test case requires sufficient prior notice to the group.
Comment 11 Aryeh Gregor 2011-02-18 19:38:46 UTC
(In reply to comment #9)
> * If substantial technical changes are made after a Last Call Working Draft,
> then the Working Group cannot proceed to Candidate Recommendation and must
> publish another LCWD. While it is not entirely clear what kinds of changes are
> substantial enough, it seems like feature additions, or for that matter feature
> removals, probably are.
> . . .
> Thus, the Chairs propose that during the current pre-LC period, and during Last
> Call, feature additions or removals should only be done with sufficient prior
> notice to the group, in the form of a bug.

Why is there any constraint on the pre-LC period?  Per W3C process, we're still a WD and can change freely now, no?

> We are not making bug filing
> mandatory for editorial changes or even technical changes that correct an
> error. We're also not trying to put any constraint on the WHATWG HTML draft.
> From the W3C HTML WG point of view, it is reasonable to add a feature to WHATWG
> HTML but then not propose it for inclusion in W3C HTML5 at all, if it is not
> ready to go through a stabilization cycle. It is also ok to put such features
> in other drafts. However, in order to fulfill process requirements, we can't
> have features freely added to the W3C draft without sufficient advance notice.

If the motivation is to conform to process requirements, I don't see how prior notice is relevant.  If the change is substantial, then we can't proceed to CR, and if it's not, we can -- regardless of whether there was prior notice given.

Furthermore, there appears to be no process limitation on changes right now, pre-LC.  And once we've made at least one substantial technical change during LC (as is almost certain to happen), we have to go back to WD anyway, so further substantial technical changes impose no additional process requirement that I can see, as long as they're not disputed.


To fulfill process requirements, it seems to me that it would be sufficient to do something more like:

1) During WD, substantial technical changes are allowed, but if such a change is disputed by anyone, it should be removed and punted to a future HTML version so that we don't get bogged down in an unlimited stream of new issues.

2) During LC or CR, no substantial technical changes are allowed without group approval, unless the group has already approved at least one substantial technical change (necessitating a return to WD), in which case see (1).

Would these be insufficient to satisfy W3C process requirements?  If so, why?  If not, clearly there's some reason for your proposal beyond just satisfying W3C process requirements, and I would be interested in hearing it.

(In reply to comment #10)
> > Thus, the Chairs propose that during the current pre-LC period, and during Last
> > Call, feature additions or removals should only be done with sufficient prior
> > notice to the group, in the form of a bug. 
> 
> If we can trust people to operate in good faith, I am OK with us not
> elaborating on this further, as long as it is widely understood that the
> following proposal does not constitute "sufficient prior notice":
> 
> http://krijnhoetmer.nl/irc-logs/whatwg/20110211#l-1532

Why not?  Automatic notice is still notice.  Or do you object to it not being meaningfully "prior"?  If so, I think you should clearly state some time period, e.g.: no substantial technical changes except in response to a bug that's been open on the issue in the W3C tracker for at least 48 hours.  (Practically speaking, I don't see why it matters, since the change can easily be reverted after the fact.)

> > We are not making bug filing
> > mandatory for editorial changes or even technical changes that correct an
> > error.
> 
> I'd like the bar a little higher than that: I suggest that any change that
> affects an approved test case requires sufficient prior notice to the group.

I don't know why you think that raises the bar, since virtually no normative statement in the spec has an approved test outside of canvas.  When we do have a comprehensive test suite, on the other hand, even minor bug fixes are going to affect approved test cases.
Comment 12 Maciej Stachowiak 2011-05-30 21:30:15 UTC
Resolved along the lines of comment #9 here:

http://dev.w3.org/cvsweb/html5/decision-policy/decision-policy-v2.html.diff?r1=1.27&r2=1.28&f=h

I did *not* add a requirement about any change that affects an approved test case. "particularly exceptional circumstances" applied to feature additions, so I addressed that. If anyone believes we should tighten the requirements on any change that affects a test case, then I suggest filing a follow-up bug.