- 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>
Aryeh Gregor wrote: > > The first priority (implicitly) is that nothing can be in the spec if > it won't be implemented. Agreed > 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". (http://lists.w3.org/Archives/Public/public-html/2010Jun/0247.html) 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." http://wiki.whatwg.org/wiki/FAQ#How_does_the_WHATWG_work.3F Autocracy: 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 http://www.merriam-webster.com/dictionary/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 corrected. > 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. http://dev.w3.org/html5/decision-policy/decision-policy.html *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. ** http://dev.w3.org/html5/decision-policy/decision-policy.html#escalation 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 'rule'. 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 "implementation". 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 stamp...). JF
Received on Thursday, 10 June 2010 02:57:58 UTC