Re: [ALL] draft process for producing WG Notes

McBride, Brian wrote:

> Thanks for this Guus.
> 
> [...]
> 
> 
>>2. The TF starts work to produce a note. At some point the TF
>>    coordinator signals to the Working Group that the note is (almost)
>>    ready for public review. The TF coordinator asks the WG to review
>>    the note prior to public review.
>>
>>3. The WG assigns at least one WG participant outside the TF to review
>>    the note. The internal reviewing period should typically be 1-2
>>    weeks. The WG may either (1) take a decision directly to publish
>>    the note as a working draft for public review, leaving it to the
>>    discretion of the author(s) and reviewer(s) to revise the 
>>draft, or
>>    (2) postpone the decision to publish as working draft till after
>>    the review/revision process is completed.
> 
> 
> There are (at least) two possible models here:
> 
>   1) the WG produces a draft "to the best of its ability" and then seeks
> public review.  In this model publication for public review would be like
> last call and would only be done once consensus had been reached (or disent
> overruled) in the WG.
> 
>   2) the WG produces a draft and seeks early comment and input from the
> community.  This is common Working Draft (initial caps indicate formal W3C
> Working Draft) process.  One does not need consensus on the content to
> publish for external review, though it is common practice to not points of
> disagreement and specifically seek feedback.
> 
> The test here is whether voting for first publication indicates agreement to
> the content.  I think we need to be clear about this.

I meant 2), the common "Working draft" notion. We not have to agree with 
the content, but the WG should feel that publication serves a purpose to 
its "user community", i.e. semantic-web developers.

> 
>>4. The note is published as a working draft [note a] of the WG,
> 
> 
> This appears to be inventing new process.  The embryo note could be
> published as a Working Draft with a status section saying that it is not a
> rec track document. 
> 
>>From the process doc
> 
> [[
> 7.1.2 Maturity Level When Ending Work on a Technical Report
> 
> Working Group Note
>     A Working Group Note is published by a chartered Working Group to
> indicate that work has ended on a particular topic. A Working Group MAY
> publish a Working Group Note with or without its prior publication as a
> Working Draft.
> ]] 
> 
> This text at least suggests the publishing WDs and then turning them into
> notes has been forseen.  I'm not disagreeing with Guus' proposal, but I
> suggest the WG should understand why it is necessary to adopt a novel
> process.

Well, I first thought this was new process, but one could also see it as 
an ambiguity/inconsistency in the Process document as the definition of 
WG Note seems in line with what I suggest.

I propose that Ralph and I send a message about this interpretation to 
the process-issues list of the AC.

> 
> Will the drafts be like tag findings and located in the web space of the WG?

Yes, that is my expectation. I see no reason why not.

> 
> 
> 
>>    requesting public review. The draft should identify the mailing
>>    list to which comments should be sent (at the moment
>>    public-swbp-wg@w3.org with an appropriate message-label
>>    suggestion). The draft should also specify the review period
>>    (typically 4-6 weeks).
>>
>>5. The WG will strive for consensus on the contents of a WG Note,
>>    bearing in mind that the consensus can be of a different 
>>level than
>>    required for a recommendation.
> 
> 
> Consensus, as understood in W3C feels kinda binary to me; either there is
> expressed dissent or there is not.  I suspect Guus means:
> 
>   - we might hope the community will be more tolerant of things in a note
> they don't really agree with and more willing to abstain than they would be
> for a rec.
> 
>   - whilst the goal is consensus, the WG may not strive so hard to reach it,
> as it would for a rec.
> 
> I'm kinda nervous about the second of these.  Consensus seems to me be at
> the core of W3C values.

Well, consensus means something different in rec-track work than in 
best-practices. A rec is normative, so it is easier to find point one 
cannot live with. We typically will provide documents will guidelines, 
including alternatives approaches, and so on. So, I expect it will be 
easier for people to "live with" (an important concept in W3C process) 
text that you yourself not agree with.

A practical example can be imagined for the "classes-as-values" note. 
Somewhat might vehemently disagree with the solution that requires 
stepping outside OWL DL, because s/he thinks OWL Full is crap. Still, 
given the alternatives in the same note the person might well agree with 
publication of the guideline. Compare this to the DL/Full fights in Webont.

> 
> There is probably not a lot of point in discussing this in the abstract; its
> better to wait till/if we have a problem.  I'd suggest droping the "bearing
> in mind clause" though.
> 
> What we might do is adopt a the principal that if there is dissent, we don't
> ignore it, and if we can't reach consensus, we must at least document the
> dissent.

Yes, this should be documented.

I will revise the process description after the telecon.

Guus
> 
> Brian
> 

-- 
Free University Amsterdam, Computer Science
De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
Tel: +31 20 444 7739/7718
E-mail: schreiber@cs.vu.nl
Home page: http://www.cs.vu.nl/~guus/

Received on Thursday, 10 June 2004 07:59:47 UTC