W3C home > Mailing lists > Public > public-html@w3.org > June 2010

RE: Request for editing guidance

From: John Foliot <jfoliot@stanford.edu>
Date: Wed, 9 Jun 2010 19:57:20 -0700 (PDT)
To: "'Aryeh Gregor'" <Simetrical+w3c@gmail.com>, "'Julian Reschke'" <julian.reschke@gmx.de>
Cc: "'Jonas Sicking'" <jonas@sicking.cc>, "'Tab Atkins Jr.'" <jackalmage@gmail.com>, "'Jirka Kosek'" <jirka@kosek.cz>, "'Ian Hickson'" <ian@hixie.ch>, <public-html@w3.org>
Message-ID: <037201cb0848$a343ace0$e9cb06a0$@edu>
Aryeh Gregor wrote:
> The first priority (implicitly) is that nothing can be in the spec if
> it won't be implemented.


> Following that, we favor "users over authors
> over implementors over specifiers over theoretical purity".  In this
> case, the first solution would be preferred, followed by the third,
> followed by second, based on what implementers are willing to
> implement.

This one is tricky. In an unrelated conversation a few weeks back, an 
engineer from one of the browser developers made a comment to me that 
implementing something would take "...100's of hours of development..." to 
achieve foo (deliberately being vague as to the value of foo here as it is 
not important). That was however one comment from one implementer. It is 
still unclear (to me) if one implementer has enough clout to create the veto 
that would negate the best solution (#1 from the original list) thus 
rendering #3 the solution "least likely to attract an objection". According 
to Tab earlier today however the answer to that question is "somewhere 
around 1%, if past comments on the matter can be trusted". 

So while I want to believe that the users always come first, practical 
experience is suggesting to me that this notion is somewhat utopian, and in 
practice already we likely arrive at option 3 versus 1 more often than not.

> The real trick is figuring out what's best for users.
> > The problem we have is when decisions are
> > made at WHATWG (in what we must honestly agree is a mono-culture
> setting -
> > engineers talking to engineers) that misunderstands or mis-interprets
> the
> > needs/impact on the other groups. It is further compounded by the
> autocratic
> > decision process that is employed at WHATWG.
> I'd say the opposite.  The WHATWG is dominated by implementers.

Thus my comment regarding a mono-culture.
That comment is not made to be inflammatory, but simply to acknowledge what 
you also just said, but re-phrase it somewhat. "The WHATWG is dominated by 
implementers." - not users, not authors, implementers.

As well, the current 'process' for conflict resolution at WHATWG is that the 
editor has final say (and thus, autocratic):

	"...nobody is able to convince the editor to change the spec any more (e.g. 
because two people want opposite things, and the editor has considered all 
the information available and decided that one of the two proposals is the 
better one). This is not a consensus-based approach -- there's no guarantee 
that everyone will be happy! There is also no voting."

1 : the authority or rule of an autocrat
2 : government in which one person possesses unlimited power
3 : a community or state governed by autocracy

> Implementers are uniquely qualified to evaluate the needs of the web
> as a whole.

Perhaps of "the web", but not necessarily of "users", especially when some 
users might be accessing the 'web' with a tool-set that includes software 
above and beyond a browser - specifically users of Adaptive Technology. 
Here, the 'implementers' lack a visible depth of understanding and 
*participation* of users of that sub-set, which is a problem. I know that 
Marco Zehe is an AT user working for Mozilla, but I am unaware of any AT 
users at Opera, Apple/web-kit, Google/Chrome acting at the engineer level 
(but would be thrilled to be corrected - and if I've missed somebody please 
accept my apology). As such, their ability to evaluate the needs of all 
users is restricted because of the existing mono-culture. This is not a 
criticism, it is simply an observation of fact. Again, happy to be 

> There are only a few browsers, and each browser is used
> by a pretty representative slice of all web users.  In contrast,
> authors, users, and spec writers tend to see only a tiny and utterly
> non-representative part of the web in the course of their day-to-day
> life.  They have a correspondingly unrealistic view of the web,
> overemphasizing the importance of their own small slice.  The WHATWG
> operates by everyone presenting their needs, and the browser
> implementers deciding on their importance based on their perspective
> of the whole web.

Aryeh, this sounds an awful lot like you're moving into the 80/20 'rule', 
which (coincidently enough) corresponds to some older data I have from a 
Microsoft study of 2004:

1 in 4 has a vision difficulty (25%)
1 in 4 has a dexterity difficulty (25%)
1 in 5 has a hearing difficulty (20%)
16% of users have a cognitive difficulty or impairment

(Sadly it appears that Microsoft has removed the study's URL from active 
view: I have however a Word document that was linked in the online results 
backed up at my office. The old URL was:
	Study Commissioned by Microsoft Corporation and Conducted by Forrester 
Research, Inc. - www.microsoft.com/enable/research/computerusers.aspx)

For this reason, I personally have concerns whenever I hear that the 
implementers are "...deciding on their importance based on their perspective 
of the whole web." as their "whole web" is likely incomplete. (see 
Monoculture above)

> Pragmatically, this is what happens anyway.  Implementers are the
> gatekeepers, and if they don't think something is sensible, they'll
> just ignore it.  Trying to force things on implementers, rather than
> writing specs that all implementers agree with from the beginning, is
> what gets us specs that don't reflect reality.

However, given what I wrote above, we also need to have a healthy 
questioning of what their reality actually reflects. Is it everyone's 
reality, or their limited perspective of reality?

> If I understand Ian correctly, he'd be fine if things like that were a
> clearly-stated generally-applicable rule.  His objection is that the
> general rules are not stated clearly and officially.

Working Group Decision:
Issues escalated to the tracker will be decided by Working Group Decision. 
The Escalation Process* describes how Working Group decisions are made.

*Escalation Process

5.a. Consensus Found:
If there are no objections, very few (and weak) objections, or objections 
can be resolved, the chairs declare that the Call for Consensus becomes a 
resolution. The Working Group affirms or overrules the editor's decision 
depending on the outcome. The Basic Process then proceeds from step 7a or 
step 7b as appropriate. ** This is an endpoint for the escalation process. 

5.b. No Clear Consensus
If there are numerous and/or serious objections, or if it is unclear to the 
chairs what the position of the working group is, the chairs may use a poll 
to get a sense of the working group.

6. Poll or Vote
A WG decision may be entered based on an informative straw poll as one piece 
of input, or based on a formal and binding vote. Or the chairs can ask for a 
new round of proposals if the poll does not reveal a strongly preferred 
position; in this case, return to step 3. Otherwise, the Working Group 
affirms or overrules the editor's decision depending on the outcome. The 
Basic Process then proceeds from step 7a or step 7b as appropriate. ** This 
is an endpoint for the escalation process. **

Now that seems to be both fairly detailed and official to me. The problem we 
have today is with "Otherwise, the Working Group affirms or overrules the 
editor's decision depending on the outcome." ...which directly conflicts 
with WHATWG's 'policy', where the Editor is final arbitrator; the WHATWG 
being a monoculture of implementers who may or may not have a firm 
understanding of the needs of all users, include the 20% from the 80/20 

This whole thread appears to have emerged because the Editor apparently is 
unhappy that the above clear process resulted in the removal of text that 
alluded to OCR as being a potential suitable solution (aka Issue 66), when 
users and authors in a group outside of the engineer mono-culture protested 
loudly that this was false at best, and confusing to other authors, as it 
left the illusion that it might be viable. No proof of that assertion was 
conclusively made, and for the record, during the discussion around Issue 66 
even many engineers came around to agreeing with that general notion, and 
that removing this guidance from the specification had little impact on 

With that, the Editor shifted gears slightly and moved from 'Editor' to 
'Editorialist', complete with offensive language surrounding "Politics", and 
a back-handed slap at redundant references to WCAG.

Now the Chairs might disagree with me, as is their want, but if the Editor 
is really asking for editing guidance I would suggest the following:

1) Listen to all groups, not just implementers. Accept that there are other 
perspectives beyond the monoculture of the implementers view-point that the 
Editor might not agree with.

2) Re-review the W3C decision and escalation processes; ask for 
clarification if something is unclear.

3) Trust that nobody will think any less of Ian if he is wrong - everyone 
(and I mean everyone, even his most vocal opponents) has great respect for 
the herculean task he has undertaken. However, once an issue has been 
escalated using the W3C Process, the Editor should 'abandon ownership' of 
the issue and trust the collective wisdom of the entire WG to get it right. 
(If, collectively we fail and get it wrong, nobody will blame Ian either)

4) Make changes to the specification as directed by the Chairs, who are 
tasked with ensuring the above process is followed.

5) Edit, don't editorialize.

As always, my $0.02 worth (even if the bulk required a $5.00 postage 

Received on Thursday, 10 June 2010 02:57:58 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:20 UTC