W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > February 2019

Re: dxwg-ACTION-302: Request chairs to identify procedure for closing issues about requirement definitions and urge ucr team to consolidate and close such issues as appropriate.

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Fri, 22 Feb 2019 05:30:07 -0800
To: "Svensson, Lars" <L.Svensson@dnb.de>, "pedro.win.stan@gmail.com" <pedro.win.stan@gmail.com>
Cc: Dataset Exchange Working Group <public-dxwg-wg@w3.org>
Message-ID: <ed5aa321-a4f3-34dc-5115-7b0ab525a1ed@kcoyle.net>


On 2/22/19 12:25 AM, Svensson, Lars wrote:
> Karen,
> 
> On Thursday, February 21, 2019 5:39 PM, Karen Coyle [mailto:kcoyle@kcoyle.net] wrote:
> 
>> Lars, I'm not entirely sure of what you are asking, but we have seen
>> requirements that need to be addressed in more than one deliverable. If
>> you can determine that they have been addressed in all of the relevant
>> deliverables, or if the labels are not relevant, then they can be closed.
> 
> Perhaps I've misunderstood what the GitHub issues for requirements are about. So far I've thought that they are to discuss the requirements, find appropriate wording etc. and then get them into the UCR document. Then we use the UCR document as the baseline to see if we have addressed all our requirements.
> 
> Do I understand correctly that you take the view that we keep the agreed-on requirements as open GitHub issues until the requirement has been addressed in all deliverables the requirement refers to?
> 

Yes. That is how we've been using them in the profile guidance document,
and I think also in profiles ontology. We've put the requirements into
the draft and then used that to assure that the draft addresses the
requirement. You may have done otherwise in conneg - I suspect that you
had a better grasp of the document content starting out than we have
with the guidance document.

So I guess we've used them for multiple purposes - to complete the UCR
and then to guide the creation of the deliverables. And I don't think we
ever decided that it may have just happened. Sorry!

kc


>> For example, #217 "Responses can conform to multiple, modular profiles"
>> refers both to a conneg response but also to the modularity of profiles.
>> Something related to this will need to be included in the profiles
>> guidance document as well as conneg. The same is true for the
>> requirement that profiles have URIs - that needs to be in both
>> documents. If conneg has completed this you can remove the conneg label
>> and you are no long responsible for that issue. You may want to leave a
>> comment that you've included it in your document and are removing your
>> label.
>>
>> Does any of this answer your question?
> 
> No, but I think we're getting closer!
> 
> Best,
> 
> Lars
>  
>> On 2/21/19 8:04 AM, Svensson, Lars wrote:
>>> On Thursday, February 21, 2019 4:50 PM, Karen Coyle
>> [mailto:kcoyle@kcoyle.net] wrote:
>>>
>>>> I'd gladly see 2) happen for any issues that are ONLY marked conneg or
>>>> that are blindingly obviously only related to conneg. We just need to
>>>> know that we've dealt with the issue, so if it's been included or if the
>>>> decision was not to implement/address the issue, then a pointer to the
>>>> decision is all that is needed for closing. If there isn't an actual
>>>> resolution to point to, a short explanation on the closing should do it.
>>>
>>> If we find that we have agreed on the text and that text is in the UCR document,
>> why can't we close the issues irrespective of which deliverable they belong to? I
>> thought we do this exercise in order to move UCR forward...
>>>
>>> Best,
>>>
>>> Lars
>>>
>>>> For 1), where we have proliferated labels (sometimes unnecessarily),
>>>> let's see if we can un-label issues. I'll look through the early profgui
>>>> ones and remove any that don't seem relevant.
>>>>
>>>> *Action: Can someone do this for DCAT as well?
>>>> *Question: Can we remove or ignore the UCR labels in the old requirement
>>>> issues? (kc: yes)
>>>>
>>>> Peter, any other comments?
>>>>
>>>> kc
>>>>
>>>> On 2/21/19 5:52 AM, Svensson, Lars wrote:
>>>>> Hi Karen, Peter, (addressing the chairs...)
>>>>>
>>>>> No I don't have a definitive list but I think the issues Rob points to can give a
>>>> feeling of which kind of issues we're talking about.
>>>>>
>>>>> When we reviewed the open issues tagged 'profile-negotiation' (oldest first)
>> [1]
>>>> we found that many of the older issues are about discussion of use cases and
>>>> requirements where we by now probably have reached consensus on how to
>> phrase
>>>> them and that have found their way into the UCR document.
>>>>>
>>>>> The problem with those issues are that they clutter the view and make it hard
>> to
>>>> figure out what to work on (at least for me) since it's unclear exactly what action
>> is
>>>> required.
>>>>>
>>>>> Is there a procedure/protocol for closing such issues?
>>>>>
>>>>> I can see two ways forward:
>>>>> 1) we remove the labels for the deliverables (e.g. 'dcat', 'profile-guidance' etc.)
>>>> from those UCR-related issues so that they don't pop up when we search for
>> issues
>>>> relating to a specific deliverable. (Con: we lose track of which of those
>> requirements
>>>> relate to which deliverable unless that's already in the UCR document).
>>>>> 2) We close all of those issues where we have reach consensus on the text
>> _and_
>>>> that text is in the UCR document.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> [1]
>>>>
>> https://github.com/w3c/dxwg/issues?q=is%3Aissue+is%3Aopen+label%3Aprofile-
>>>> negotiation+sort%3Acreated-asc
>>>>>
>>>>> Best,
>>>>>
>>>>> Lars
>>>>>
>>>>>> From: Rob Atkinson [mailto:rob@metalinkage.com.au]
>>>>>> Sent: Wednesday, February 20, 2019 11:19 PM
>>>>>> To: Karen Coyle <kcoyle@kcoyle.net>
>>>>>> Cc: Dataset Exchange Working Group <public-dxwg-wg@w3.org>
>>>>>> Subject: Re: dxwg-ACTION-302: Request chairs to identify procedure for
>> closing
>>>>>> issues about requirement definitions and urge ucr team to consolidate and
>> close
>>>>>> such issues as appropriate.
>>>>>>
>>>>>> Even though the action is on Lars to present thus, as we're awake I can at
>> least
>>>> pass
>>>>>> on some pointers..
>>>>>>
>>>>>> #72-75
>>>>>>
>>>>>> 205, 207, 217
>>>>>>
>>>>>> etc.
>>>>>>
>>>>>> a lot of these are requirements, or older  version of requirements (possibly)
>>>>>>
>>>>>> Many (or most)  of these requirements are motivating requirements
>> addressed
>>>> by
>>>>>> the nature and FPWDs of the conneg-by-ap and profiles vocabulary - so we
>> hope
>>>> as
>>>>>> long as the UCR is up to date they can be closed?  We've marked a few as
>> due-
>>>> for-
>>>>>> closing pending this direction.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, 21 Feb 2019 at 08:33, Karen Coyle <mailto:kcoyle@kcoyle.net>
>> wrote:
>>>>>> Hi, thanks. I'm not sure exactly what is meant by "about requirement
>>>>>> definitions" - we have a number of issues that are copies of
>>>>>> requirements but that are not really about the definitions. Can you give
>>>>>> a few examples? (Obviously a definitive list would be ideal, but I won't
>>>>>> assume that you have one at hand.)
>>>>>>
>>>>>> kc
>>>>>>
>>>>>> On 2/20/19 1:00 PM, Dataset Exchange Working Group Issue Tracker wrote:
>>>>>>> dxwg-ACTION-302: Request chairs to identify procedure for closing issues
>>>> about
>>>>>> requirement definitions and urge ucr team to consolidate and close such
>> issues
>>>> as
>>>>>> appropriate.
>>>>>>>
>>>>>>> https://www.w3.org/2017/dxwg/track/actions/302
>>>>>>>
>>>>>>> Assigned to: Lars G. Svensson
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Karen Coyle
>>>>>> mailto:kcoyle@kcoyle.net http://kcoyle.net
>>>>>> m: 1-510-435-8234 (Signal)
>>>>>> skype: kcoylenet/+1-510-984-3600
>>>>
>>>> --
>>>> Karen Coyle
>>>> kcoyle@kcoyle.net http://kcoyle.net
>>>> m: 1-510-435-8234 (Signal)
>>>> skype: kcoylenet/+1-510-984-3600
>>
>> --
>> Karen Coyle
>> kcoyle@kcoyle.net http://kcoyle.net
>> m: 1-510-435-8234 (Signal)
>> skype: kcoylenet/+1-510-984-3600

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600
Received on Friday, 22 February 2019 13:30:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 April 2019 13:45:07 UTC