W3C home > Mailing lists > Public > public-webapi@w3.org > January 2007

Re: Selectors API naming

From: Jon Ferraiolo <jferrai@us.ibm.com>
Date: Thu, 25 Jan 2007 12:39:47 -0800
To: Ian Hickson <ian@hixie.ch>
Cc: Joćo Eiras <joao.eiras@gmail.com>, Web APIs WG <public-webapi@w3.org>
Message-ID: <OF3B211DEB.6A5E7EB5-ON8825726E.0070F2E0-8825726E.007181B1@us.ibm.com>

While I agree that the W3C should change as the world changes within it,
process changes at W3C aren't something that occur just because you or I
have a particular opinion about what process changes should occur. I
encourage you to read the process document, particularly the section about
how decisions are made:
http://www.w3.org/2005/10/Process-20051014/policies.html#Consensus. Maybe
these sections can be changed in the future, but until those changes occur,
WGs should follow W3C rules, not Ian's opinions (or anyone else's opinion)
about what the rules should be.


Jon Ferraiolo <jferrai@us.ibm.com>
Web Architect, Emerging Technologies
IBM, Menlo Park, CA
Mobile: +1-650-926-5865

             Ian Hickson                                                   
             Sent by:                                                   To 
             public-webapi-req         Jon Ferraiolo/Menlo Park/IBM@IBMUS  
             uest@w3.org                                                cc 
                                       Joćo Eiras <joao.eiras@gmail.com>,  
                                       Web APIs WG <public-webapi@w3.org>  
             01/25/2007 11:43                                      Subject 
             AM                        Re: Selectors API naming            

On Thu, 25 Jan 2007, Jon Ferraiolo wrote:
> Editors are in charge of the words in a spec and simply make sure that
> the will of the WG is reflected in the spec. I don't understand where
> there is bad precedent in this.

While this has indeed been the way that the W3C has developed
specifications for a long time, the W3C's own technologies -- HTML, HTTP,
etc -- have led the Web to a place where massive collaboration is the
norm. The blogosphere and sites like Wikipedia are one example of this,
but another is the collaborative open spec development that has for a long
time been the hallmark of the IETF, but is now becoming standard in other
areas, like the Microformats community. The Web API working group long ago
decided to follow open principles as well.

Web specifications affect everyone in the Web community, and so Web
specifications should be developed in the open. The term "Working Group
Member" is misleading -- there should not be anything special to being a
W3C member when it comes to the development of Web technologies. Given the
prohibitively high price of W3C membership, not to mention the cost of
attending regular meetings around the globe, it is absolutely imperative
that we not limit equal participation to only those capable of paying the
W3C to become Working Group members.

Thus, an editor's responsibility is not simply to make sure the will of
the "Working Group Members" is reflected in the spec -- the editor's
responsibility is to make sure the will of the entire Web community is
reflected in the spec, and the Working Group's responsibility is to make
sure that the editor indeed does this.

> On the other hand, it would be very bad precedent if editors attempted
> to override the will of the WG to make specs reflect their own personal
> opinions.

Yes, naturally. Nobody, I hope, is suggesting that this should happen.
Editors should always try to balance the opinions of all those in the
wider community, and develop well-balanced, consistent APIs and
technologies that handle the 80% case well, without falling prey to scope
creep and certainly, as you point out, without letting their own opinions
make them ignore important parts of the community.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

(image/gif attachment: graycol.gif)

(image/gif attachment: pic04706.gif)

(image/gif attachment: ecblank.gif)

Received on Thursday, 25 January 2007 20:40:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:22 UTC