Re: Can we freeze the Tracker for while?

Perhaps the wiki page is the place to prioritize the issues. We'd need 
criteria for the prioritization so that it's not just a crap shoot, 
however. I must admit that I'm not sure what our goals are at the 
moment, especially because we seem to be in "reaction mode" much of the 
time. What is our "critical path"?

I would oppose freezing the tracker. I think it's good to get the issues 
recorded as they come up, otherwise they will be forgotten. But it may 
make sense to "back burner" some issues and to tackle key ones (but more 
difficult ones, probably) before those.

kc

On 11/8/15 6:44 PM, Holger Knublauch wrote:
> Most industry-strength issue trackers have a field for priority, or
> deadlines. This would probably help.
>
> At some stage, Arnaud derived the agenda from whatever topic was getting
> most discussion during the week. My comment below was intended to remind
> us that this may lead to distractions - rabbit holes on rather small
> issues.
>
> We have tried to use the new Proposals Wiki page to drive the agenda
> process. But not enough people have contributed there yet, and the page
> is useless if people put their vote to -0.9 on the Wiki and suddenly
> change to -1 during the meeting, as happened in
>
> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-100:_sh:index
>
> I had suggested ISSUE-100 for the agenda because it looked like a quick
> thing to close - it certainly wasn't meant to cause a whole new range of
> discussion about the general role of UI design features in SHACL.
>
> Speaking about things that I think are blocked unnecessarily:
> - ISSUE-103 (I had responded to your question in email, what else is
> blocking you?)
> - ISSUE-104 (I had responded to your question on the wiki, what else is
> blocking you?)
> - ISSUE-78 (we had long ago agreed that we cannot rely on RDFS
> inferencing, so why do you keep bringing this up to block a trivial
> feature such as sh:abstract)?
>
> Topics that await counter proposals (from Arthur):
> - ISSUE-87
> - ISSUE-95
>
> Holger
>
>
> On 11/7/2015 15:52, Peter F. Patel-Schneider wrote:
>> Opening an issue is largely independent of how or when it is to
>> handled.   If
>> any working group member feels that certain issues need to be
>> addressed now
>> they are welcome to advocate that more attention be paid to these
>> issues.  If
>> any working group member feels that certain proposed issues should not be
>> opened they they are also welcome to so advocate.   I would be against a
>> general moratorium on opening issues, or even a slowdown on opening
>> issues.
>>
>>
>> Restricting the opening and resolution of issues is not going to
>> result in
>> more practical experience with and real-world feedback on SHACL.
>>
>>
>> I do believe that the working group should be spending more time on
>> fundamental issues.  Making progress on fundamental issues can require
>> considerable time, and I know that I have been spending time on what I
>> consider to be less important issues, but these have been coming up for
>> consideration mostly independently of any actions on my part.
>>
>> peter
>>
>>
>> On 11/06/2015 09:11 PM, Holger Knublauch wrote:
>>> I believe we have a sufficient number of open tickets right now that
>>> require
>>> our attention. The process should resemble a queue in which the most
>>> urgent
>>> tickets are handled with priority. The flood of recently raised
>>> issues (and
>>> non-issues) is IMHO a distraction that turns our workflow into a LIFO
>>> stack.
>>> None of ISSUES-105 onwards are urgent.
>>>
>>> While the tracker is good to record suggestions, I believe we should
>>> refrain
>>> from handling them until next year, say, until we had another F2F and
>>> the next
>>> draft has been published.
>>>
>>> What is urgently missing is practical experience and real-world
>>> feedback.
>>> While we have a reasonably good draft now, I don't believe many
>>> people have
>>> actually tried to use SHACL. To bootstrap this, we need easy to use
>>> tools, and
>>> to provide those, we need a stable syntax so that tool builders are
>>> willing to
>>> create polished environments with support for common use cases, and
>>> to write
>>> tutorials.
>>>
>>> Holger
>>>
>>>
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Monday, 9 November 2015 14:39:04 UTC