RE: [PORT] review process

Ralph, David, is this a reasonable summary of the position re PORT review process ... 

At review, the PORT TF presents the reviewers with the list of proposed changes to consider, and asks, 'do you see any issues with these proposed changes?'

The PORT TF should attempt to resolve any issues raised by reviewers, but may make changes to SKOS Core and publish revised working drafts despite objections by reviewers if they feel that those changes represent consensus within the TF (supported by the members of public-esw-thes@w3.org), provided that objections and open issues are documented in any new working drafts.

... ?

Cheers,

Al.

 

> -----Original Message-----
> From: public-swbp-wg-request@w3.org
> [mailto:public-swbp-wg-request@w3.org]On Behalf Of Miles, AJ 
> (Alistair)
> Sent: 25 July 2005 14:47
> To: public-swbp-wg@w3.org; Ralph Swick (E-mail)
> Cc: Guus Schreiber (E-mail); dwood@mindswap.org; Dan Brickley 
> (E-mail);
> Thomas Baker (E-mail)
> Subject: RE: [PORT] review process
> 
> 
> 
> Hi Ralph,
> 
> > > The guidelines you propose sound to me like they're part of the
> > > process for the TF or WG to decide what changes to make.
> > > That's a design role, not the role of a document reviewer.
> > > 
> > > I thought I'd agreed to be available to consult on proposed
> > > changes before the selection was made.  "Make recommendations
> > > as to which proposed changes should be implemented" goes
> > > beyond my view of this consulting role.  But maybe this is
> > > interpretation.
> > > 
> > > I would encourage the TF to establish some regular mechanism
> > > by which it decides on behalf of the WG what changes should be
> > > made.  I guess that is what you are now doing, by defining more
> > > precisely what you meant by "reviewer to look at change proposals"
> > > in the 11 July WG telecon minutes.
> 
> Yes, a regular mechanism for deciding on changes is exactly 
> what we need.
> 
> What I had meant was that reviewers must 'approve' proposed 
> changes.  I.e. give the go-ahead to implement a proposed 
> change.  I was assuming that, because reviewers 'approve' the 
> working drafts for publication, they essentially have the 
> power to veto any changes, and therefore would have to 
> 'approve' them.  Am I misunderstanding WG process and the 
> role/power of a reviewer?    
> 
> The model I was assuming is something like this ... SKOS 
> community discusses proposals for change, SKOS editors decide 
> which proposals get on the proposals list (and hence go to 
> review), reviewers (appointed by WG) then have the power to 
> veto proposals ... is this the right model, or do we want to 
> do something different?
> 
> 
> > > 
> > > > 1. Reviewers should evaluate those proposed changes 
> > > published at [2] that have not been modified for a period of 
> > > 2 weeks prior to the beginning of the review, and make 
> > > recommendations as to which proposed changes should be 
> > > implemented.  (Implementing a change means updating the SKOS 
> > > Core RDF/OWL description, generating a new editor's draft of 
> > > the SKOS Core Spec, and rewriting/adding relevant sections to 
> > > the SKOS Core Guide as appropriate.)
> > > 
> > > Does the decision to implement or not implement a proposed change
> > > rest primarily on the recommendations of these reviewers, or does
> > > the Task Force expect to combine the reviewer's feedback 
> > with all the
> > > rest of its knowledge and retain responsibility for the 
> > > selection itself?
> > > (I'm more comfortable with the latter.)
> 
> I would also be happy with the latter, but didn't realise it 
> would be possible.  Again, I was assuming that because 
> reviewers are responsible for 'approving' working drafts for 
> publication, they essentially have the power to veto any changes.
> 
> 
> > > 
> > > > 3. Reviewers may make proposals for changes to SKOS Core, 
> > > which will be added to [2] and considered at the next review. 
> > >  However, reviewers may not insist on changes to SKOS Core 
> > > WDs (other than editorial) that have not been previously 
> > > published at [2] for the required period (2 weeks).
> > > 
> > > perfectly reasonable, but really this is just saying that the 
> > > reviewers
> > > have no special status to alter or fast-track the change proposal
> > > process.
> 
> Yes, that's what I meant.
> 
> 
> > > 
> > > >If this is OK (Guus, David, Dan?), then I suggest an 
> > > official start date for this review as asap.  This brings 
> > > into play all four proposals at [2].
> > > 
> > > Does that mean you will freeze [2] or that the reviewers 
> > are expected
> > > to select from [2] based on looking at the 'Date of last 
> > > modification'?
> > > 
> > > I think it would help to have some explicit way to denote the 
> > > proposals
> > > that are being considered for each review round.
> > > 
> 
> I was thinking that reviewers would select from [2] based on 
> dates of last modification, but a more explicit way to denote 
> proposals sounds like a good idea.  I could prepare something 
> for the reviewers before each review?
> 
> Thanks for your time Ralph.
> 
> Cheers,
> 
> Al.
> 
> [1] 
http://www.w3.org/TR/2005/WD-swbp-skos-core-spec-20050510/#secChange
[2] http://www.w3.org/2004/02/skos/core/proposals

Received on Monday, 25 July 2005 18:19:40 UTC