Re: Can we freeze the Tracker for while?

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
>>
>>

Received on Monday, 9 November 2015 02:45:29 UTC