Re: review process [was: identify...]

> > > As with anybody else, the WG's obligation to me is to
> > >       -- convince me to withdraw
> > >       -- accept my suggestion, or
> > >       -- escalate the issue

To which Murray responded:

> > I read this and paused.  I got up and took a walk.  By the time I sat
> > down again, it was clear that you have no idea - absolutely none
> > whatsoever - how utterly *outrageous* this is.

To which Dan Connolly responded:

> Why is it outrageous to say that the WG is obligated to seek consensus
> among the community of reviewers, and escalate if they feel it's
> time to move on without it? IETF WGs have had this obligation
> for decades, and I haven't seen any objection to it. c.f

To which Murray replied:

-Really simple: you've expanded the scope of required consensus from
-simply the WG and the internal review mechanisms within the W3C to
-the entire world, where you know quite well there will never be a
-consensus.

I think you are trying to make the  process sound absurd in talking about
the "whole world".  Of course it works in fact because only a subset of the
world are interested in the issues.  The w3c is not as wide open toany
comment as the IETF, in that the working groups sometimes work in private
before publishing their working drafts. Also, the W3C AC are the final
guides, rather than the IESG.

On the contrary, the stage of moving the ideas of a small group out into a
larger group is very important. It is what W3C is all about.   each time you
extend the debate, the document is better honed, more questions are
answered, and the support is stronger. Sometimes, as you increase the domain
of review by an order of magnitude, you get the same number of new reviews.
This scales.
It takes more work than just writing incompatible bits alone at home, but it
is useful.

- There never can be a consensus in such a wide forum with
- no process or rules for creating consensus.

Well, the W3C process is created for finding a consensus
amongst the entire community.  This is why a working group
cannot  simply plan its own future without reference to the rest of the
consortium or the XML and Web communities in general. That is why public
comments must be responded to publically at last call, and why we have
a review process at all.

- If you wanted a public
- process like the IETF, XHTML should have been created within the IETF.

No, the IETF has a different model and a different scope. But it did inspire
some parts of the W3C process. Some w3C working groups use public lists.
W3C has a concept of the commitment from member companies,
and of an intergrated plan which is defined on the advice of the
Advisory Committee. But it does have a wide scope.

- I think it's pretty amazing to hear you reference the IETF process,
- when the W3C explicitly has a different one. As you well know.

Not as different as you seem to think.

- I'm beginning to see your strategy: move discussions into as wide a
- forum as possible, then let them die in endless discussion.

The process focusses at each stage on the very important
differentiation between the uninformed re-introduction of old settled
points, and input which is valuable as it brings a new perspective.
For example, an AC member who brings  up a complaint which has
been settled in a WG in which they took part can be overruled.
However, when input from a different group (inside or, increasingly,
 outside W3C) comes in, then it must be taken seriously.
Therefore, good ideas should progress through in finite time.

The business of good global engineering is not just making a smart
subsystem.
It is in being able intelligently to give way when your group's influence
expands to meet another subculture.  It is hard, and defensiveness makes it
very much harder. It is however the real work of achieveing shared
understanding and consequent interoperability.

-  I don't
- see every other W3C spec undergoing such a long and painful death,

You have clearly been unaware of the pain many specs have been though!
No, you don't see a death, because typically the spec gains strength during
initial reviews, and gains a larger and larger consensus behind it.
Some specs may die, of course, if they are broken or unimplementable.

- and I see little reason to follow you through this idiocy, which is
- unjustified by W3C process, regardless of your attempts to convince
- us otherwise. The W3C does *not* seek public consensus on its
- specifications, for better or worse.

The W3C does seek consensus for its specifications, including public input.
It does also have ways of ensuring that the process terminates and is not
attacked by "denial of service" attacks for example.

For example, the SMIL recommendation went though despite a critical review
because that review was considered unfair at that stage by the party in
question. The RDFS specification by contrast was held up because a negative
review was considered insufficiently answered, and a inter-group meeting was
organized which answered it.

The IETF recently went though an appeal of a single individual to the IAB
level where it was dismissed.  I hope we do not have too much of that
expenditure of effort too often!

There are checks and balances.

-  If it did, nothing would ever reach Recommendation.

This is not the case.  The WAI guidelines went to recommendation with the
benefit of much public input. Ask Judy Brewer.  It does take an attitude
that
there is a win-win situation, rather than a competitive one.  This has been
something which W3C inherited from the internet development community.
This attitude is very important, probably more important than the process. I
would encourage everyone on this list to approach this development in that
spirit.

Tim Berners-Lee
Director, W3C

...........................................................................
-Murray Altheim                            <mailto:altheim&#x40;eng.sun.com>
-XML Technology Center
-Sun Microsystems, Inc.,

Received on Thursday, 17 February 2000 17:32:07 UTC