Re: Success in a WG

Hi Tantek,

On Jun 25, 2010, at 02:25 , Tantek Celik wrote:
> "rough consensus and running code" trumps any label no matter how many blessings a label may imply.
> (...)
> 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).

In an ideal universe we might take the time to do that, and to continuously evaluate past documents in the light of today's best practices. But in a world in which we have time constraints and much on our plates, I am not convinced that this would be the best use of our collective energies (keep in mind that the Team would not be in a good position to unilaterally enact your above proposal, so that the "W3C" there would be us).

Frankly, I don't care about intellectual honesty — I care about rough consensus and running code ;)

So rather than looking backwards, I think that we should be looking forwards. What are the differences between "rough consensus and running code" and a Recommendation, and how do we reconcile the two? In my experience, the push for more quality (not just tests but correctly testable assertions and all that goes with) has come mostly from the Team, which had to educate new WGs, new participants, etc. each time. How do we spread that out to improve the community's reviewal acumen? How do we encourage groups to prefer small, minimalistic specifications that can be both thoroughly tested and shipped within reasonable time frames (even if it means having several versions in more or less rapid succession) over behemonoliths?

Karl mentions the "must have a test before a feature can go in" rule, but in my experience that doesn't hold long. It also leads to a lot of wasted work when redesign happens (or conversely, to stabilising on a suboptimal design because the group doesn't feel like doing all that work all over again). It also leads to sloppy tests being accepted because people are too tired to review them properly.

It's just a thought but I wonder if focusing on better writing from the get go wouldn't be more efficient. You don't need tests to get something into the spec, but your text needs to be simple and straightforward enough that it is obviously testable.

There's a *lot* of good material out there, in the Editor's Guide, in the Chair's Guide, in the QA Library, in various notes from Best Practices groups about how to write a good spec. But it's scattered and voluminous enough that few get to read even parts of it (and those who do often forget large chunks of it). I wonder if we couldn't collect the most salient and important parts of all of that into a single, not-too-long document that would be systematically put in front of new participants (especially editors). Perhaps taking http://www.w3.org/TR/test-methodology/ as a starting point would work. The idea is to provide a core for the lore, something to live and breathe while writing standards. It could also be the core for a potential lighterweight process (or the common quality metric).

WDYT?

--
Robin Berjon
  robineko — hired gun, higher standards
  http://robineko.com/

Received on Monday, 28 June 2010 09:33:31 UTC