W3C home > Mailing lists > Public > public-w3process@w3.org > October 2013

Re: small comment on the AB draft process document

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Fri, 18 Oct 2013 01:50:39 +0200
Cc: public-w3process@w3.org
To: "Ivan Herman" <ivan@w3.org>
Message-ID: <op.w44hupjfy3oazb@chaals.local>
On Wed, 16 Oct 2013 10:44:38 +0200, Ivan Herman <ivan@w3.org> wrote:
> chaals wrote
>> Ivan had written
>>> 7.6.2, classes #1 and #2 of changes: does it mean that the Working
>>> Group (or the team) is allowed to make changes on the documents
>>> directly, in situ, on the TR pages? Or does it mean that a new
>>> document is created (with a new dated URI) by the Working Group, which
>>> is then silently put up on /TR (maybe with a home page announcement)?
>>
>> This text was inherited from the existing process document. I believe  
>> the practice is that in the first case the changes can be made in situ  
>> (although there is a difference between changing the invisible content  
>> of markup and the actual text of a link, IMHO). I am not sure when the  
>> second class of change would be made, but my inclination is to either  
>> remove it, or require an Edited Recommendation rather than allowing in  
>> situ editing.
>>
> Actually, I do like what is there, ie, that even #2 changes can be done  
> in situ. Let me give a typical example: we have a document in the making  
> (JSON-LD), that has a dependency on Promises (or whatever the name in  
> vogue is these days). We would really like to publish this as a Rec  
> today, but the reference to the Promises document cannot be normative.  
> Say in 6 month the Promises document, in its current format, becomes  
> final and cast in concrete. That means that a new JSON-LD document  
> should be issued with the reference changed to normative. This change  
> would not affect conformance of implementations, but it is not a broken  
> link or invalid markup change: ie, it falls under category #2. On the  
> other hand, it looks like madness to go through the whole hoopla and  
> contacting the AC over this change, so I would like the team or the WG  
> to make the change in situ, announce the change and go on with their  
> lives...

I raised ISSUE-47 for this point. I think that markup changes should be
allowed "silently" - i.e. no announcement required.

I agree that it is reasonable to update a reference (another example that
leaps to mind is IETF URIs that vanish) with a simple announcement. This
is a judgement call, since it may be that the change (for example in the
case of promises) is accompanied by a change in the target that actually
affects conformance. But if not, it should as you say be possible to make
a quick change and get on with more important things.

However beyond that, I think editorial changes should be reviewed (I've
seen, and probably even made, too many "editorial" chagnes that turned out
to have a serious impact on someone out thereā€¦).

So I propose to change class 2 of changes to be references, and allow
markup changes silently, references to be changed with a new publication
and announcement but no formal review, and fold editorial changes into
class 3, requiring an Edited Rec.

And I'll put that into the draft I am working on right now and will
publish before I go to sleep.

cheers,

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
         chaals@yandex-team.ru         Find more at http://yandex.com
Received on Thursday, 17 October 2013 23:51:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:09 UTC