- From: <bugzilla@jessica.w3.org>
- Date: Fri, 18 Feb 2011 19:38:47 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12029 --- Comment #11 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 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. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Friday, 18 February 2011 19:38:49 UTC