Re: small comment on the AB draft process document

On Fri, 18 Oct 2013 02:10:25 +0200, Ian Jacobs <> wrote:

> On Oct 17, 2013, at 6:50 PM, Charles McCathie Nevile  
> <> wrote:
>> On Wed, 16 Oct 2013 10:44:38 +0200, Ivan Herman <> 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.
> Here is the Director's current policy:

Thanks. I am proposing to bring the Process more in line with this. But I  
am still not entirely happy with the section - it is unclear *who* can  
request or approve a change...

So I'll make changes to try and clarify, but leave the issue open.



>> 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
>>         Find more at
> --
> Ian Jacobs <>
> Tel:                                          +1 718 260 9447

Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex         Find more at

Received on Friday, 18 October 2013 00:42:16 UTC