Re: Proposal for an errata management

Hi. I don't have any experience of w3c's errata process- so I'm happy to +1
once consensus is found. Jeremy
On Sun, 22 Nov 2015 at 16:01, Dan Brickley <danbri@google.com> wrote:

> Thanks for exploring this.
>
> Is there any risk of API quotas being exceeded?
>
> Perhaps we could consider the Github area a kind of "errata drafting" or
> staging area, with potentially more official W3C hosted version at W3C
> proper. That would also allow a larger (e.g. community) group to maintain
> the github version...
>
> Dan
>
> On Sun, 22 Nov 2015, 16:13 Ivan Herman <ivan@w3.org> wrote:
>
>> Dear all,
>>
>> I played with Javascript and the Github API the past few days, and I have
>> a proposal improving what I originally set up.
>>
>> There is a mock_up file (that I used for the testing) at:
>>
>> http://w3c.github.io/csvw/errata/mock_up
>>
>> The important point is:
>>
>> - The HTML file runs a script that retrieves issues with a specific label
>> ('Errata') from a github repo (I used my old development repo which is
>> fairly dormant right now in that test mock_up file)
>> - The errata themselves are displayed among sections based on a specific
>> label assigned to that section. The same erratum can appear several times
>> if it is labelled accordingly. Finally, if an erratum does not use any of
>> those section specific labels, it is displayed in a separate section
>> - Each erratum is displayed with some of its important characteristics,
>> including other possible labels. There is also a possibility to add a
>> comment to the discussion (if any) starting with the word 'Summary:', which
>> is then displayed separately. This may be a good practice when raising an
>> erratum is followed by some discussions
>>
>> The file above shows what it does; the file below
>>
>> http://w3c.github.io/csvw/errata/errata
>>
>> shows how this would translate to our case, with a description of the
>> process.
>>
>> That means that report is done automatically, the average handling of an
>> erratum is entirely on the issue list and nowhere else. Keeping the report
>> on github also allows for an easier change on the text/workflow, etc, so it
>> may be worth keeping there (instead of hosting the report on W3C).
>>
>> One thought that I did not implement: we do have a number of issues that
>> we postponed for a possible future release. We could label these as errata
>> and add a separate section in the report for 'postponed issues'. Although
>> these are, technically, not errata, but it would be still o.k. in the W3C
>> terminology (W3C errata often include future improvement things.). But we
>> may decide to keep those apart.
>>
>> WDYT? Should I proceed and use the errata report page as above as the
>> 'official' one?
>>
>> Cheers
>>
>> Ivan
>>
>>
>>
>> On 18 Nov 2015, at 14:47, Ivan Herman <ivan@w3.org> wrote:
>>
>> Actually… I may have found some ways of including the issues
>> automatically into the errata page. It will require some javascripting, but
>> I do not mind playing with this. This means that the content of the errata
>> page will be filled automatically. I would still keep that page on github,
>> if anybody wants to make some change at some point later…
>>
>> Ivan
>>
>>
>>
>>
>> On 18 Nov 2015, at 14:23, Ivan Herman <ivan@w3.org> wrote:
>>
>> … while I was at it, I have made the necessary changes in the document
>> config for the REC, with the provisional date of the 17th of December.
>>
>> Additionally, I have set up an errata page. Although it has a W3C URI
>>
>> http://www.w3.org/2013/csvw/errata.html
>>
>> it redirects to
>>
>> http://w3c.github.io/csvw/errata/
>>
>> This is just a proposal on how we can proceed with errata; because we
>> always used GitHub, it seemed logical to use github for that purpose, too.
>>
>> It is a bit of a pain that the accepted errors have to be recorded on the
>> errata page manually, although it may help in separating the real errata
>> from the fake ones. Nevertheless… if somebody knows some good javascript
>> tricks to get the data directly from github on the fly rather than doing it
>> manually, that would be better. I believe there is Github API, so it may
>> not be impossible. I will have a look, but, in the meantime, what is there
>> may be fine.
>>
>> If you prefer another approach, let us discuss it now, while we still
>> have time…
>>
>> Cheers
>>
>> Ivan
>>
>> ----
>> Ivan Herman, W3C
>> Digital Publishing Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>
>>
>>
>>
>>
>>
>> ----
>> Ivan Herman, W3C
>> Digital Publishing Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>
>>
>>
>>
>>
>>
>> ----
>> Ivan Herman, W3C
>> Digital Publishing Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>
>>
>>
>>
>>