Re: Chaos, Process

-----Original Message-----
From: Simon St.Laurent <simonstl@simonstl.com>
To: xml-uri@w3.org <xml-uri@w3.org>
Date: Wednesday, May 31, 2000 2:46 PM
Subject: Chaos, Process


>At 01:04 PM 5/31/00 -0400, Tim Berners-Lee wrote:
>SSL>[This is a set of side issues TimBL brought up in the
>SSL>Moving on thread.  They're important, but I fear that
>SSL>they could muddy that discussion in communal violence,
>SSL>so I've separated them.]
>>
>TBL>(A good idea ...whenever the actual topic changes.
>TBL>Other list users take note.)
>
>I changed the header again, as I plan to address only a portion of your
>reply initially while I sort out the rest.  I hope you didn't mean
>'communal violence' was a good idea, though I fear that further conflict
>may be where this is headed long term.
>
>[I've attempted to clean up line breaks and indicate writers as well,
>hoping to make this more readable.  TBL1 refers to comments from a previous
>message than the one to which I'm replying]
>
>TBL>Yes, I suppose feel hurt when I and a team of people who
>TBL>have been paid to do it work hard to bring people together
>TBL>to form plans for the future which all can agree on, and
>TBL>somehere down the road, our attempts to hold ongoing activity
>TBL>together by pointing out the ties which bind it are referred
>TBL>to as "random"!  Often, the w3C staff are in a very difficult
>TBL>position when groups seem be very happy to work independently
>TBL>and prodcue something which in the end didn't fit together.
>TBL>Then, the team's job is to point these things out.
>
>>From the outside of the black box, there appears to be an enormous amount
>of randomness inside the black box.  The view on the inside may well be
>different.  We simply have no way of knowing, and being told that documents
>published as NOTEs have 'axiomatic' status makes life even more confusing.


(Something can be axiomatic in the design without being published at all!)
We agree we need a better process for refining general architectural
invariants. It may look like the process for redining the process.

>I'd like to point out that 'random' is not necessarily bad, or even
>unorderly.  Systems that aren't predictable frequently produce better
>results than systems that are predictable.
>
>You seem to disagree, but that may have something to do with your role as
>Director of a research organization that appears to believe strongly, if
>occasionally, in a top-down approach to building Web architecture.


You need a small number of strong global invariants and a
large number of weak local ones, and everything in between.
So the more strong, the more occasional.  This is the art.
Not anarchy or total centralized control.

>TBL>When someone on an open list attacks the ties
>TBL>which bind the system together, it may be a time
>TBL>for feedback and it maybe a time for education. It
>TBL>may be a time for more complex process. But it is a
>TBL>time to respect other parts of the system.
>
>I'm not certain why you're feel 'the ties which bind the system together'
>are being attacked.

The use of URI for important concepts such as namespaces is such a tie, "to
take an arbitrary example".



>TBL>Ok, I can compare those two paragraphs carefully.  Under
>TBL>the process, the individuals and corporations and other
>TBL>organziations which are involved in W3C work within a
>TBL>process so that their actions are not random.
>
>I don't quite understand your apparently severe irritation with the word
>random.

I thought you had used it to encapsulate your complaint.

>TBL>For example,
>TBL>when the staff analyse the working group response to last
>TBL>call comments there is a commitment that the document
>TBL>should only go though if they have been addressed appropriately.
>TBL>So the result of the review cannot be random.  There is no veto.
>
>The result of the review will be as good as the effort that went into the
>initial document and the review.  'The result of the review cannot be
>random' is a major overstatement.
>
>'There is no veto'?  I thought the Director of the W3C had real power over
>Recommendations, limited only by the costs of infuriating large blocs of
>members but (within the process itself) absolute nonetheless.  I suspect
>this leads to smaller vetoes within W3C process as well, but can't confirm
>that.


There is no veto. There is a judgement as to whether the process has been
done appropriately.  There is a concept of a consensus, which implies
unanimity, or unanimity with abstention, or a minority report. Minority
reports
have to be taken up to the next stage.  This is the general idea throughout
the
process. A veto means one person saying no over everyone else. That can't
happen.
The staff can point out that the comments (public or member) in previous
phases have not been addressed, for example, or that the criteria of
demonstrable implementatins
has not been set.

>TBL>By contrast, on a public list, there is no commitment to any
>TBL>process so that people can be free to criticize for their own
>TBL>purposes. I am not criticizing people here, I am comparing
>TBL>processes. I am interested in and have spent a lot of time in both.
>
>There is no commitment, but there is frequently community.  Communities can
>and do create things of lasting value.  I'd point to SAX and SAX2 as one
>example, and the work coming out of SML-DEV (see
>http://www.docuverse.com/smldev/index.html) as another.


I agree. The web grew on alt.hypertext, and  www-talk@info.cern.ch, later
www-talk@w3.org.

>There may be more visible randomness, but what coherence exists is also
>public.


You are preaching to the converted here.  I wouldn't have started this list
if
I didn't believe in the value of getting the issues out in an open
referencable
discussion.


>TBL>You say "in position of control".  What is control? Who has
>TBL>control? Many people on this list write code, and that controls
>TBL>what actually is.  That is control, maybe.  The appearance of
>TBL>power which the consortium has stems from the fact that people
>TBL>in it consort - they agree to work together.
>
>Code writing provides some level of control, if you can get people to use
>your code.  Some organizations do very well writing code that reflects
>their needs and distributing it, others don't.
>
>The 'position of control' that the W3C has is rather tenuous, in some ways,
>but much stronger than other consortia in other ways.  The history of the
>W3C's director has given it considerably more 'moral authority' than any
>other vendor consortium I'm aware of, and its work affects a larger body of
>people.  Instead of being merely as strong as its members' commitment, the
>W3C can also trade in on the well-wishes it receives for past success.
>
>Within the W3C, it's clear that there are various positions of control, as
>there tend to be in any vaguely sophisticated design process.  The
>decisions made by the holders of those positions - be they members,
>editors, staff, or the Director - have an enormous impact on a much larger
>body of people than the W3C officially holds themselves responsible to.


You have explained that, while a public list officially has no
accountability,
it can have an ethos of responsability.  So can the W3C.

>It seems likely, even probably that that 'larger body of people' will not
>always share the goals and interests of the W3C itself.

Who is this "w3c itself"? It is developers too, people with very much the
same needs as you who develop stuff but have chosen not to join.  You could
argue in the same way that xml-uri or xml-dev is not responsible to a larger
body of people.  But in the end, groups have to form and do their best and
do what they can to keep in touch.

>Griping about
>negative responses from that larger body and trying to push 'axioms' on
>that body doesn't seem very productive.  I'd suggest a friendlier form of
>community outreach.


If there are technical invariants which I think are important then I will
continue to push them as I am doing on this list in order to preserve
the essential and really exciting prpoerties of the web.

Suggestions, though, for friendlier forms of community outreach in general?

>TBL>They participate and commit things. Time - that they will review
>TBL>other people's specifications. Money - to provide an infrastructure
>TBL>and a full-time staff to help with the vary challenging business
>TBL>of collaboration and consensus across cultures. They also make a
>TBL>commitment that they are working toward an interoperable solution
>TBL>across the board.  The result has prodcued some specs. No one has
>TBL>to use them, but because a lot of people put a lot of time in, and
>TBL>because the way they fit together has been the matter of some
>TBL>thought, they are generally considered useful.
>
>I participate and commit myself to public projects all of the time, without
>pay.  I write and review specifications, and participate in discussions
>about those specifications.  Some of those might even prove to be useful.


I appreciate that. Many people on this list make great contributions to the
community.
How can we fit this in with work being done in more structured groups? Some
have not made the commitment to be on a working group,
maybe because they want to operate only on public lists and the groups you
would have been interested in used closed lists (not all do), maybe becasue
they want to participate but cannot predict at what levels, maybe because
they find the group works using long distance telephone or airplanes

>All of those projects are performed in a less formal process than that of
>the W3C. There may be randomness contained in some of the specifications.
>On the other hand, it's much easier to figure how those specs appeared -
>all discussions are  public, including vetoes.  Explaining gaps isn't that
>hard.
>
>SSL>Reconciling those two will be difficult, of course.
>SSL>Balancing top-down directed development with organically
>SSL>unmanaged bottom-up development is rarely a fun job.
>>
>TBL>Yes.  Some weblike mixture is what works in practice.
>TBL>It is getting the balance. And for each person realizing
>TBL>where they fit in.
>
>I worry about 'Weblike mixtures' here.  I strongly hope that the 'Weblike
>mixture' you have in mind refers to the early highly collaborative Web you
>initially proposed, and not the mostly-read-only Web that we have today.


But of course.  I mean basically a web not a tree -- having
cross-connections to keep its diameter down. Low diameter, therefore
fractal.

>I'm also not sure that "each person realizing where they fit in" is
>meaningful in this context.  If I was feeling cranky, I could read that as
>"you're not a member, so go away."  Since I'm trying rather hard not to be
>cranky, I'll just worry that you're suggesting that how people fit in is
>somehow obvious, when in my (limited) experience, it's definitely not.


No - on the contrary - figuring out where we can best fit in for the good
of the community is one of the really difficult things. An exciting thing is
when the web makes it easier, but it gives us more choices.

>TBL1>I think some form of public issues list with incoming
>TBL1>issues automatically logged, and disposition including
>TBL1>hypertext links to the resolution, may be a good interface
>TBL1>between a working group and a wider public interest group.
>>
>SSL>Sounds like a good idea, one I'd like to see the W3C put in
>SSL>practice across all of its activities.  That'd help, certainly.
>>
>TBL>We have had the plan on the table for a long time.  <sigh/>
>TBL>We wanted a moderated state-tracking system for architecture
>TBL>discussions. But in fact the tools are not things you can get
>TBL>off the shelf and we don't have unlimited resources to spend
>TBL>on creating them.
>
>Well, at least the intent is good.  I've been happy to see a number of
>working groups (XLink, XML Schema) using their public lists quite actively,
>a nice change from previous times when public questions went (publicly,
>anyway) unanswered.


I really want to make sure that that doesn't happen again.
I am not accepting a review which says, of a comment, "we discussed that
and we decided it was misinformed", unless it says "and here is a link to
the message
saying so" and ideally the achnolowedgement.



>Simon St.Laurent
>XML Elements of Style / XML: A Primer, 2nd Ed.
>Building XML Applications
>Inside XML DTDs: Scientific and Technical
>Cookies / Sharing Bandwidth
>http://www.simonstl.com
>

Received on Thursday, 1 June 2000 17:49:05 UTC