Re: small comment on the AB draft process document

On Fri, 18 Oct 2013 01:50:39 +0200, Charles McCathie Nevile
<chaals@yandex-team.ru> wrote:

> 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)?

Currently, the process is unclear - it doesn't say what is expected or
required in such cases, although it now does refer to  "Requirements for
modification of W3C Technical Reports" [1] in which the Team describes some
requirements. This is being tracked in ISSUE-47 and the most recent
resolution of the Task Force was that we would revert to the current text.

I foreshadowed making an objection to that text and proposing further
changes, perhaps in part under this issue and/or as a new issue.

[1] http://www.w3.org/2003/01/republishing

[this email is to close ACTION-13 on me]

cheers

Chaals

>>> 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 Tuesday, 22 October 2013 02:18:12 UTC