Re: Requirements --> GitHub issues

Hi Jaro,

It's great that you're looking into the automated creation of issues for 
each of the requirements.

In case you are also looking at the tagging, I have added labels for 
each of the requirements' categories:

https://github.com/w3c/dxwg/labels

Let us know how you get on.

Best wishes,

Alejandra


On 17/01/2018 15:25, Jaroslav Pullmann wrote:
>    Hello Simon,  hello Rob
>
>      thank you, the example is really useful! I've entered a long distance train, a reason I'll probably miss today's DCAT call
>    but a chance to dedicate time on the requirement conversion.  As mentioned by Rob, the GitHub REST API is the right tool
>    (which I have to familiarize with first). The import should be done by Friday/next Monday.
>
>     Best regards
>   Jaro
>
>
> On Wednesday, January 17, 2018 07:14 CET, Rob Atkinson <rob@metalinkage.com.au> wrote:
>   
>> Was hoping that Jaro would be able to adapt his scripts to pump out all the
>> issues to github via the REST api :-)
>>
>> rob
>>
>>
>> On Wed, 17 Jan 2018 at 16:15 <Simon.Cox@csiro.au> wrote:
>>
>>> OK folk, I broke down and did one manually to illustrate what I was hoping
>>> could be done automatically.
>>>
>>>
>>>
>>> https://github.com/w3c/dxwg/issues/50 corresponds to
>>> https://www.w3.org/TR/dcat-ucr/#RDID
>>>
>>>
>>>
>>> I copied the link to the UCR document into the issue.
>>>
>>> I gave it the following labels
>>>
>>> (i)                  [requirement]
>>>
>>> (ii)                [dcat] according to the deliverable-related tag
>>> inherited from Use Case that generated the requirement
>>>
>>>
>>>
>>> Putting it in a standard issue-tracker allows us to follow the progress of
>>> satisfying this requirement, or re-classifying it by changing the labels
>>> (tags) if necessary.
>>>
>>> I just used the text from the UCR document directly, which includes the
>>> sub-heading number (6.1.1 in this case) which may be non-persistent if the
>>> UCR document is revised. On the other hand, the code [RDID] is also
>>> visible, which I think was intended to be a persistent identifier.
>>>
>>>
>>> This issue is now found by a standard query for
>>>
>>> -          Issues tagged [dcat]
>>>
>>> o
>>> https://github.com/w3c/dxwg/issues?utf8=%E2%9C%93&q=is%3Aopen+label%3Adcat+
>>>
>>>
>>> -          Issues tagged [dcat] and [requirement]
>>>
>>> o
>>> https://github.com/w3c/dxwg/issues?utf8=%E2%9C%93&q=is%3Aopen+label%3Arequirement+label%3Adcat+
>>>
>>>
>>>
>>>
>>> I also see that Jaro has done a lot of clever Javascripting to get similar
>>> selection functions into the UCR document itself
>>>
>>> https://www.w3.org/TR/dcat-ucr/#Tags but I suggest that if we can use a
>>> generic tool (GitHub) which also does the dynamic record-keeping, then
>>> maybe we can reduce the need for bespoke scripting moving forward.
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *Simon J D Cox *
>>>
>>> Research Scientist
>>>
>>> Environmental Informatics
>>>
>>> CSIRO Land and Water <http://www.csiro.au/Research/LWF>
>>>
>>>
>>>
>>> *E* simon.cox@csiro.au *T* +61 3 9545 2365 <(03)%209545%202365> *M* +61
>>> 403 302 672 <0403%20302%20672>
>>>
>>>     *Mail:* Private Bag 10, Clayton South, Vic 3169
>>>
>>> *   Visit: *Central Reception, Research Way, Clayton, Vic 3168
>>>
>>> *   Deliver: *Gate 3, Normanby Road, Clayton, Vic
>>> <https://maps.google.com/?q=3,+Normanby+Road,+Clayton,+Vic&entry=gmail&source=g>
>>> 3168
>>>
>>> people.csiro.au/Simon-Cox
>>>
>>> orcid.org/0000-0002-3884-3420
>>>
>>> researchgate.net/profile/Simon_Cox3
>>> <https://www.researchgate.net/profile/Simon_Cox3>
>>>
>>> github.com/dr-shorthair
>>>
>>> lov.okfn.org/dataset/lov/agents/Simon%20Cox
>>>
>>> @dr_shorthair <https://twitter.com/dr_shorthair>
>>>
>>> https://xkcd.com/1810/
>>>
>>>
>>>
>>> *PLEASE NOTE*
>>>
>>> The information contained in this email may be confidential or privileged.
>>> Any unauthorised use or disclosure is prohibited. If you have received this
>>> email in error, please delete it immediately and notify the sender by
>>> return email. Thank you. To the extent permitted by law, CSIRO does not
>>> represent, warrant and/or guarantee that the integrity of this
>>> communication has been maintained or that the communication is free of
>>> errors, virus, interception or interference.
>>>
>>>
>>>
>>> *Please consider the environment before printing this email.*
>>>
>>>
>>>
>>>
>>>
>   
>   
>   

Received on Wednesday, 17 January 2018 21:17:51 UTC