Re: Success in a WG

I hesitate a bit to venture into this particular thread, but for the sake 
of clarity, I think that it is worth pointing out that a standard, 
classically so called, is not a work of art, or a journey without an end, 
or a Zen kaon.  It is a rather pedestrian, work-a-day - and above all - 
useful tool.  It can be something as simple as a 60 watt light bulb 
standard (neither shalt thy say 59 watts, nor 58 - and 61 is flat out). Or 
it can be the distance between two railway rails that no one really 
remembers for sure why it is what it is (and no, I don't believe it has 
any relation to the axle length of Roman chariots - although "urban myth" 
does stem from the Latin "urbs, urbis," even if myth has Greek origins).

But seriously.  There is a real difference between an open source project, 
which can, and should, constantly advance the state of the art, and a 
standards working group, that only provides value when it freezes - at 
least for a time, between versions, the state of the art.  Or at least 
there has been in the past. 

The W3C has been, at least to my mind, first and foremost about supplying 
humanity with some of the most important, creative and technologically 
sophisticated standards the world has seen to date, and upon which we have 
come to rely to an unsettling degree.  We can't afford to have anyone 
treat them as art for art's sake.

So here's the question: should the W3C extend its resources to support 
efforts that by choice may not be interested in ever freezing a work 
product in a point in time such that it can become useful as a standard? 
Or should it afford its limited resources to underwrite art for art's sake 
as well?

While it may seem like I'm assuming the answer, I'm not, since I'm not a 
member of W3C.  But after reading the comments below it strikes me as 
being pertinent to ask the question that baldly so that a self-aware 
recommendation (small "r") can be made by this task force back to the 
powers that be.

Andy

public-vision-newstd-request@w3.org wrote on 06/24/2010 08:25:08 PM:

> Great contrast Robin.
> 
> In short I think partly what's going on is that:
> 
> "rough consensus and running code" trumps any label no matter how 
> many blessings a label may imply.
> 
> A FPWD with 2+ reasonably interoperable implementations trumps a REC
> with no (or even one) implementation.
> 
> Heck, a public domain *wiki page* "spec" with reasonably 
> interoperable implementations trumps a REC.
> 
> The lack of (reasonably) complete and valid test suites[1] for most 
> things called "W3C Recommendations" makes a lot of people (myself 
> included) quite cynical about the REC label (it rings a bit hollow).
> 
> In fact I think W3C would do itself a great intellectual honesty 
> service if it took all such RECs and reset them to CRs (to be fair 
> most such RECs were published before the CR phase was introduced).
> 
> And for any AC reps here, please vote NO on any PRs that lack 
> reasonably complete and valid test suites plus 2+ interoperable 
> implementations documented by implementation reports[2]. 
> 
> For the worthy RECs to mean something, the hollow ones must be 
> rejected or downgraded.
> 
> Tantek Çelik
> CSS WG, HTML WG invited expert
> and general bottom-up public-domain standards advocate
> 
> [1] See the notes/minutes/video/irclogs from the "test suites / QA" 
> panel that myself and Ian Hickson organized at the 2004 TPAC where 
> we (impolitely) called on the carpet several RECs with *invalid* 
> test suites. Here is my brief page of links from that session - I'm 
> sure someone at W3C can better recall the 2004 TPAC URLs.  Ian had a
> whole grid of links to the test suites (if any) of all RECs as of 
> then which demonstrated their invalidity.
> http://tantek.com/presentations/2004w3cplenary/csstestsuiteslessons.html

> 
> [2] 
> http://tantek.com/2010/136/t2/w3c-ac-reps-specs-w-o-test-or-interop-

> vote-no-prs-downgrade-recs
> 
> -----Original Message-----
> From: Robin Berjon <robin@robineko.com>
> Sender: public-vision-newstd-request@w3.org
> Date: Fri, 25 Jun 2010 01:42:19 
> To: <public-vision-newstd@w3.org>
> Subject: Success in a WG
> 
> Hi,
> 
> in a conversation earlier today, one eminent member of our community
> (whom I won't name as I didn't ask for his permission to quote him) 
> wondered why a number of members perceived the WebApps WG as being 
> particularly successful despite the fact that it hasn't produced a 
> Recommendation in quite a while. I think that this is a very valid 
> question, that touches directly on the matter at hand here.
> 
> I haven't conducted extensive interviews of the participants and so 
> am talking largely from intuitive perception, with all the grains of
> salt that it implies. That being said I think that the question 
> points at a distinction that may be useful.
> 
> For some participants, producing a Rec is what matters primarily. It
> is, after all, the goal of the Rec-track process. It's what gets 
> called a standard, and as such can be seen as the natural produce of
> a standards organisation.
> 
> But for others, and the WebApps crowd is heavily marked by that 
> idea, a Rec is more or less a potential by-product of what they're 
> interested in, which is a continuously updated "snapshot" of the 
> current consensus around a specific piece of technology. In this 
> view a group is successful if it is conducive to constructive 
> discussion amongst participants, and if it maintains a document that
> reflects the evolution of the discussion.
> 
> I think that the latter view is interesting because it matches the 
> open source and open content approaches. A Wikipedia article is 
> never "finished", even the best ones just document the consensus of 
> their authors. A finished open source project is generally a dead 
> one, and in most living ones releases come at a much faster rate 
> than Recommendations.
> 
> There's an impedance mismatch in there (that I regularly see in 
> DAP), and I think that we should look into it. Essentially I think 
> that it means splitting our analysis of the value of Rec-track into 
> two parts: pre- and post-CR. Based on the latter view, we could say 
> that the pre-CR phase is all about documenting ongoing consensus, 
> usually in parallel with experimental implementations; while the 
> post-CR phase is about sedimenting that into interoperability tests.
> 
> I wonder, and this is very much an open question, if we couldn't 
> somehow bring those two phases to overlap. I don't mean changing the
> existing process, but rather adding a new, lighterweight one that 
> wouldn't produce Recs but "Consensus Snapshots" (for lack of a 
> better name). One idea could be that instead of flagging an entire 
> document as stable, individual features would be thus flagged, which
> would require tests and implementations for them (thereby 
> integrating test development into the continual consensus process). 
> At regular intervals "releases" would be made with stable features 
> solidifying while more experimental ones are described in the same 
document.
> 
> Even if you think that the above process is crack-fueled (which is 
> fine by me :), I still think that we should pay attention to the 
> reason(s) why WebApps is perceived as successful, and that the 
> rationale above more or less points at a rough answer.
> 
> --
> Robin Berjon
>   robineko — hired gun, higher standards
>   http://robineko.com/

> 
> 
> 
> 
> 

See the new Gesmer.com http://www.gesmer.com


_____________________________________________________________
Any tax information or written tax advice contained herein   
   (including any attachments) is not intended to be and        
   cannot be used by any taxpayer for the purpose of avoiding
   tax penalties that may be imposed on the taxpayer. (The
   foregoing legend has been affixed pursuant to U.S.
   Treasury Regulations governing tax practice.)<br><br>
                                                             
   Electronic mail from Gesmer Updegrove LLP, 40 Broad       
   Street, Boston, MA 02109. Voice: (617) 350-6800, Fax:     
   (617) 350-6878. This communication is intended only for   
   the use of the individual or entity named as the          
   addressee. It may contain information which is privileged
   and/or confidential under applicable law. If you are not
   the intended recipient or such recipient's employee or
   agent, you are hereby notified that any dissemination,
   copy or disclosure of this communication is strictly
   prohibited. If you have received this communication in
   error, please immediately notify Christopher O'Sullivan at
   (617) 350-6800 and notify the sender by electronic mail.
   Please expunge this communication without making any
   copies. Thank you for your cooperation.