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

Success in a WG

From: Robin Berjon <robin@robineko.com>
Date: Fri, 25 Jun 2010 01:42:19 +0200
Message-Id: <789A4321-59EF-4161-8AA2-6425DE98ABC1@robineko.com>
To: public-vision-newstd@w3.org

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
Received on Thursday, 24 June 2010 23:42:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:47:26 UTC