- From: Ralph R. Swick <swick@w3.org>
- Date: Fri, 29 Apr 2005 11:36:57 -0400
- 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:52 UTC