Re: Success in a WG

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/

Received on Friday, 25 June 2010 00:26:04 UTC