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

Re: Fundamental assumptions (Was: SVGWG SVG-in-HTML proposal)

From: Philip TAYLOR (Ret'd) <P.Taylor@Rhul.Ac.Uk>
Date: Tue, 29 Jul 2008 12:52:45 +0100
Message-ID: <488F048D.3040000@Rhul.Ac.Uk>
To: Ian Hickson <ian@hixie.ch>
CC: HTML WG <public-html@w3.org>

OK, let's address the most important point first :

 > I have many times explained that I think consensus is overrated and that
 > the W3C's decision policy is outdated and should be rethought.

 > The HTML5 work isn't using the traditional W3C approach, and will never
 > use a consensus approach so long as I am editor. Consensus simply isn't a
 > good way to get technically solid specifications, and is in any case
 > basically impossible to achieve in a group with hundreds of participants
 > such as this one.

You, as an individual, believe that consensus is overrated (etc).
Fine, I am sure you and I disagree on many things, the importance
of consensus being one of them, and I certainly respect your
right to regard consensus as being over-rated, just as I hope
you regard my right to believe in the importance of consensus.

Yet you, as the Editor, are bound by the Charter of the WG
(as am I, as an "Invited Expert" to the WG).  And below
I quote the relevant parts :

> Decision Policy
> 
> As explained in the Process Document (section 3.3), 
 > this group will seek to make decisions when there is
 > consensus. We expect that typically, an editor
 > makes an initial proposal, which is refined in
 > discussion with Working Group members and other
 > reviewers, and consensus emerges with little
 > formal decision-making. However, if a decision
 > is necessary for timely progress, but after due
 > consideration of different opinions, consensus
 > is not achieved, the Chair should put a question
 > (allowing for remote, asynchronous participation
 > using, for example, email and/or web-based survey
 > techniques) and record a decision and any objections,
 > and consider the matter resolved, at least until new
 > information becomes available.
> 
> This charter is written in accordance with Section 3.4, 
 > Votes of the W3C Process Document and includes no voting
 > procedures beyond what the Process Document requires.

So, what you believe as an individual is neither here nor
there; what matters is what you practice as Editor.  If
you follow the WG Charter, and seek consensus, referring
the matter to the Chair(s) when consensus clearly cannot
be reached, then I see no problem.  But if you allow your
personal opinions on consensus to interfere with W3C process,
then I afraid that this will be interpreted by many
(myself included) as evidence that you are unfit to serve
as Editor, and I imagine that this might then lead to calls
for you to be replaced.

Now, as to timescale.  You wrote

>>> If evidence to turn these assumptions around were indeed to come up, 
>>> then this would have a massive effect on the HTML5 spec, and would 
>>> probably put us back at least 6 months so that we could reengineer the 
>>> spec to be designed with the new principles in mind.

and you were clearly asserting here that a delay of six months
would be significant.  Yet you now say :

> I think one would be hard pressed to call the HTML5 timetable "rushed". 
> From start to finish the current timetable calls for a 19 year plan, which 
> is longer than the entire lifetime of the Web so far (2003-2022 [2]).
> 
> If evidence were to turn up that showed these assumptions to be flawed, 
> then we should indeed change the spec. In the text you quote above, I'm 
> just pointing out that this would take at least 6 months.
> 
> [2] http://www.whatwg.org/specs/web-apps/current-work/TIMETABLE

so six months in the great scheme of things is neither here
nor there.  As I wrote in my preceding message,

> Far better to delay by six months than to 
> [...] release something that is fundamentally flawed.

Philip TAYLOR
Received on Tuesday, 29 July 2008 11:53:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:56 UTC