W3C home > Mailing lists > Public > public-esw-thes@w3.org > April 2005

RE: [PORT] Proposed management process for SKOS Core

From: Ralph R. Swick <swick@w3.org>
Date: Fri, 29 Apr 2005 11:36:57 -0400
Message-Id: <5.1.0.14.2.20050428160404.02da6d90@127.0.0.1>
To: Alistair Miles <A.J.Miles@rl.ac.uk>
Cc: <public-esw-thes@w3.org>, <public-swbp-wg@w3.org>, <danbri@w3.org>

At 02:48 PM 4/25/2005 +0100, Miles, AJ (Alistair) wrote:
>Mark Van Assem sent me some comments on [1], and raised the concern that the model proposed gives too much power to the reviewers - reviewers could possibly veto changes in opposition to strong consensus within the public-esw-thes community.

While this could happen, I think that the SWBPD Working Group would
be very unwise to take such action without significant prior discussion.
That discussion would be open and I hope would explicitly include
public-esw-thes.  I can only imagine that there would have to be a
significant difference in fundamental architectural principles for the
WG to veto a change that had strong community consensus.

>  The problem is how to fit SKOS Core into the W3C process, without sacrificing the principle that anyone may become actively involved in SKOS Core development at any time via the public-esw-thes mailing list, and that consensus on that mailing list is the primary driver for change.

There are other kinds of W3C Technical Reports that do not require
a Working Group process but I suggest to the community that the
purpose of the Working Group process is to raise the work to the
attention of all interested parties.  A question to be considered is whether
the benefits of widening the community of consensus are worth some
loss of change control.

We might all also decide that a new W3C Working Group would
provide a better forum for SKOS specification management -- more
focused, for example.  When a new Working Group charter is being
drafted the participation options from which to choose are very broad.

>Proposal for SKOS Core Management Process (version 0.2):
>---
>
>(1) The WG periodically reviews the 'SKOS Core Guide' and 'SKOS Core Vocabulary Specification' and publishes new Public Working Draft versions of these documents after each review.
>
>(2) In the interim period between Public Working Draft versions, no changes may be made to the SKOS Core Vocabulary.  Hence the SKOS Core Vocabulary RDF/OWL description will not be changed during the interim period.
>
>(3) In the interim period between Public Working Draft versions, the delegated SKOS Core editors (myself and Danbri) will maintain a public list of proposed changes to the SKOS Core Vocabulary.
>
>(4) Proposed changes to SKOS Core must be added to the public list at least 2 weeks before a scheduled WG review, to allow the wider community to comment and to raise objections.  

As the SWBPD Working Group is likely to have a two-week period from
the request to review an editor's draft to the proposal to publish a new
version of the working draft, there is some parallelism possible in these
four stages.  The following seems an equivalent expression of your
proposed process:

1. After publication of a Working Draft version, the latest Working Draft
version is considered to be the authoritative specification of SKOS Core.

2. The SKOS Core editors maintain a public list of proposed changes to
the SKOS Core Vocabulary.  These changes may be discussed on
the public-esw-thes mailing list and/or the public-swbp-wg mailing list.

3. The SKOS Core editors will make available a public editor's draft
of the SKOS Core documents containing selected changes from the
list in [2] at least two weeks prior to considering a motion in SWBPD WG
to publish a new Working Draft.

>(4a) Proposed changes to SKOS Core should not go to review without reasonable consensus from the members of the public-esw-thes@w3.org mailing list.
>
>(5) At each subsequent review, the reviewers delegated by the WG may of course review the SKOS Core Guide and the SKOS Core Vocabulary Specification in their entirety.  However, the focus of each review will be to evaluate the list of proposed changes.
>
>(6) Those changes approved by the reviewers, or approved in a modified form after negotiation with the reviewers, will be implemented by the editors.  New Public Working Draft versions of the SKOS Core Guide and SKOS Core Vocabulary Specification will then be published by the WG.

And I would replace 4a-6 with:

4. When discussing a motion to publish an editor's draft as a new
Working Draft version, the SWBPD WG will consider the degree of
consensus on both public-esw-thes and public-swbp-wg for the
proposed changes.

(The requirement implied by (6) for the WG -- and the editors on behalf
of the WG -- to address specific issues raised by reviewers is subsumed
in the W3C Process [2] required of all Working Groups.

  [2] http://www.w3.org/2004/02/Process-20040205/tr.html#doc-reviews
)

And I propose:

5. To assist the coordination of discussion, the editors will maintain
a public issues list for SKOS Core containing issue identifiers.  This
list may be combined with the proposed changes list provided there
is a clear mechanism to denote open issues and to (separately)
denote current proposed changes.

>Also, what about a review every 2 months instead of 3?

I suggest leaving this open, though setting an expectation of
a new editor's draft at two-month intervals is fine.  The W3C "Working
Group Heartbeat requirement" [3] sets an expectation for a public
update at no greater than 3 month intervals.  While the requirement
in [3] formally applies only if the WG proposes to put SKOS Core on
the track to become a W3C Recommendation, the spirit of that
"heartbeat requirement" is being more broadly applied.

[3] http://www.w3.org/2004/02/Process-20040205/groups.html#three-month-rule


>That's all for now,
>
>Al.
>
>[1] http://lists.w3.org/Archives/Public/public-esw-thes/2005Apr/0016.html
Received on Friday, 29 April 2005 15:37:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:53 GMT