W3C home > Mailing lists > Public > public-html@w3.org > July 2011

Re: Thoughts on restricting non-bugzilla-driven spec changes during Last Call

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Wed, 20 Jul 2011 12:50:58 -0400
Message-ID: <CAKA+Axn3EsALCfHydUz-iWFNzCEO+n+jJQWW49GM3zP6oXZ6YA@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: "public-html@w3.org WG" <public-html@w3.org>
On Wed, Jul 20, 2011 at 3:26 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> Tentative conclusions:
>     1.A) Since the CVS history provides adequate public documentation at the
> "diff" level, we don't need to increase documentation requirements for minor
> changes.

This makes sense to me.

>     1.B) We do need "summary" documentation of substantive changes. This
> could be in the form of bugs, or it could be or it could generated manually
> after the fact.

Ian already marks all commits as either editorial or non-editorial,
and provides a commit summary.  Why can't we just automatically
generate a list of all summaries for non-editorial commits that
affected the HTML5 draft?

> Setting aside for the moment what we do for LC1, for LC2 (or later) these
> standards may be sensible:
> I. Feature additions should be declined except by explicit WG decision
> otherwise. Bugs of this type should be automatically RESOLVED LATER and
> changes that slip in otherwise must be reverted.
> II. Other substantive changes require constructive prior notice since any
> that is made will require yet another LC. It's probably reasonable to
> require a bug ahead of the change. I'm not sure if we should give the bug a
> minimum lifetime to make it considered "prior". Sam previously said that he
> thinks a few hours are not enough.
> III. Minor changes require only documentation. Thus, in principle we can do
> entirely without bugs or with after-the-fact bugs. The main issue would be
> to ensure none of these are actually substantive changes.

If substantive changes have already been made to a given LC, why
should further substantive changes have a higher bar than minor
changes, assuming there are no objections to them?  They have no
special effect.  Another LC will be needed regardless as soon as one
substantive change is made, and at that point others can come along
for the ride at no extra cost.

In any event, I share the opinion of a number of Working Group members
that the Process' notion of spec maturity is completely unsuited to
large complicated standards like HTML5, and all this is an exercise is
bureaucracy.  The basic fact here is that if the W3C requires that we
stop substantive changes to HTML5 at some point, the resulting
standard will not just be incomplete (as it has been for a few years)
but outright wrong and quickly useless.

Thus the best approach is to do whatever the minimum is to satisfy the
Process, then ignore the resulting error-ridden drafts as quickly as
possible.  That means either the HTMLWG starts work on HTML6 as a new
Editor's Draft and then everyone ignores HTML5, or the HTMLWG doesn't
start work on HTML6 and everyone uses the WHATWG draft and ignores all
the W3C specs.  Either way is fine with me.  The details of what we do
with the rapidly-obsolescent HTML5 spec after we can't fix bugs
anymore are not of particular importance, so long as no one is misled
into thinking that it's actually worth looking at.

So whatever requires the least effort from everyone is probably best.
This might mean splitting the source text off -- no longer syncing it
with the WHATWG source spec at all -- and only backporting bug fixes
to the dead version of the spec if they're very serious and they're
specifically reported in the W3C Bugzilla.  And make sure we put some
notice at the start of the spec telling people not to actually follow
it, however strongly-worded the W3C will let us get away with.

Of course, the right way to handle this would be to petition for some
kind of special status for HTML5 so that we don't have to stop making
useful changes to it at all.  But without strong backing by multiple
major implementers, this seems unlikely to work.
Received on Wednesday, 20 July 2011 16:51:52 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:15 UTC