Re: Even for Note-track? Re: CFC - Standing permission to publish Working Drafts of COGA Gap Analysis

With HTML for example, we ask the Editors to add a bullet to the 
changelog whenever they make a significant change to the spec. It takes 
perhaps 2 minutes extra effort to do it.

I'd also argue that commit logs are not the most usable of things. If 
you're used to working with Github it's ok, but my impression is that 
many in this WG do not use Github regularly and so do not have that 
level of familiarity.


On 02/02/2018 16:27, Michael Cooper wrote:
> My personal view is that a link to github commit history is sufficient 
> to meet the spirit of the Process document advice James referenced. For 
> Rec-track stuff I support going further with practices that have 
> emerged. That said, if it's the will of the WG to require an actively 
> managed change log in order to feel comfortable giving standing 
> publication consent, then that's the WG decision. I manage the change 
> log for WCAG 2.1, and it's a lot more work than it seems, so I am *not* 
> prepared to take that on for the COGA gap analysis. We will need to 
> ensure that the document editors accept this responsibility. Once we 
> sort that out hopefully we can move forward with a decision. Michael
> 
> 
> On 02/02/2018 6:54 AM, Léonie Watson wrote:
>>
>> On 01/02/2018 22:43, Michael Cooper wrote:
>>> I need to point out that the COGA Roadmap and Gap Analysis is not a 
>>> spec - it's a Note-track document. Therefore I don't think it should 
>>> be held to the practices of specs. Change logs are great in specs, 
>>> and in ARIA we use them even without standing consent to publish on 
>>> the books. But Note-track documents are often edited in less discrete 
>>> chunks than specs, making it hard to make a meaningful change log. To 
>>> ensure there is WG review, we explicitly plan for review opportunity 
>>> and explicit WG consensus before transition to Note status, so I 
>>> don't think things will sneak past the WG long-term. It is certainly 
>>> possible to put a link to the github commit  history in the document, 
>>> which people who really want to track its evolution can use. But if 
>>> the WG doesn't support a standing consent to publish over this issue, 
>>> the TF will have to ask for WG approval every time it wants to 
>>> publish a draft, which will be more burden on all of us and more 
>>> bureaucracy than I feel is needed for a Note-track document.
>>
>> Without a changelog you're expecting WG members to be able to identify 
>> what's changed between one WD and the next. If, as you say, the 
>> changes in this case are in "less than discrete chunks", that means 
>> it'll be even harder to quickly review what's changed.
>>
>> The changelog doesn't need to be complicated. It just needs to be a 
>> list of high level changes, plus links to the relevant Github commits. 
>> For example:
>>
>> "Section X updated to include Y + [link to Github commit]".
>>
>> That way someone can review the changelog and decide whether they want 
>> to review the change in detail (using the commit log), or not.
>>
>>
>> Léonie.
>>
>>>
>>> Given all that, is it really needed to have a change log in this 
>>> Note-track document to get consent for standing Working Draft 
>>> publication authority?
>>>
>>> Michael
>>>
>>>
>>> On 01/02/2018 1:12 PM, Léonie Watson wrote:
>>>> -1
>>>>
>>>> In the absence of a CFC that summarises the changes between updates, 
>>>> there needs to be a changelog in the spec that makes it easy for WG 
>>>> members to ascertain what's changed for themselves. Currently the 
>>>> spec doesn't have such a thing.
>>>>
>>>>
>>>> On 01/02/2018 17:15, Andrew Kirkpatrick wrote:
>>>>> Call For Consensus — ends Monday February 5th at 12:30pm Boston time.
>>>>>
>>>>> The AGWG discussed a decision to grant standing permission for the 
>>>>> COGA Task Force to publish updated working drafts of their Gap 
>>>>> Analysis.
>>>>>
>>>>> The First Public Working Draft (FPWD) of their Gap Analysis is 
>>>>> available here: 
>>>>> https://www.w3.org/TR/2017/WD-coga-gap-analysis-20171207/
>>>>>
>>>>> Please note there is a concurrent CfC on this same question in the 
>>>>> Accessible Platform Architectures Working Group (APA WG). Members 
>>>>> of both groups are asked to respond on both CfCs.
>>>>>
>>>>> Call minutes: https://www.w3.org/2018/02/01-ag-minutes.html#item01
>>>>>
>>>>> If you have concerns about this proposed consensus position that 
>>>>> have not been discussed already and feel that those concerns result 
>>>>> in you “not being able to live with” this decision, please let the 
>>>>> group know before the CfC deadline.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> AWK
>>>>>
>>>>> Andrew Kirkpatrick
>>>>>
>>>>> Group Product Manager, Accessibility
>>>>>
>>>>> Adobe
>>>>>
>>>>> akirkpat@adobe.com <mailto:akirkpat@adobe.com>
>>>>>
>>>>> http://twitter.com/awkawk 
>>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fawkawk&data=02%7C01%7C%7C54093524ef264326424008d51cd66c05%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636446629619786436&sdata=c5UP0xiniJIppvd6Esu1XA%2FbX1ykpABkhgCCmBp%2Fht8%3D&reserved=0> 
>>>>>
>>>>>
>>>>
>>>
>>
> 

-- 
@LeonieWatson @tink@toot.cafe Carpe diem

Received on Friday, 2 February 2018 16:41:38 UTC