- From: Jeremy Tandy <jeremy.tandy@gmail.com>
- Date: Sun, 22 Nov 2015 16:05:49 +0000
- To: Dan Brickley <danbri@google.com>, Ivan Herman <ivan@w3.org>
- Cc: W3C CSV on the Web Working Group <public-csv-wg@w3.org>
- Message-ID: <CADtUq_3KAgfGNc4Vmcnat9ddMt0F8jeGUHz0zMhZvRLP4ShNgg@mail.gmail.com>
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 >> >> >> >> >>
Received on Sunday, 22 November 2015 16:06:29 UTC