Re: Can we freeze the Tracker for while?

There is no reason to freeze tracker. This would only artificially give a 
sense of having reached some kind of plateau in issue discovery only to 
get a surge when we eventually reopen it.

If anyone feels an issue that was raised is a non-issue they should say so 
when the proposal to open it is put before the group. This is why we go 
through this two step process: raised+open.

When it comes to prioritizing, my putting an issue on the agenda depends 
on a mix of parameters including the chance of being able to close it, 
active discussion on the mailing list, and now the votes on the Proposals 
wiki page. There is no perfect recipe for this and I always welcome input 
from the group. If anyone feels an issue is worth discussing sooner rather 
than later they should just let me know.

If we want to formally put some issues on the "back burner", tracker 
provides a way to mark issues as postponed. We've done that with one 
issue. We could use this mechanism more frequently to separate the not so 
important issues from the rest.

I hope the upcoming virtual F2F meeting on December 16-18 will provide us 
with more time to tackle some of the bigger issues.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - 
IBM Software Group


Karen Coyle <kcoyle@kcoyle.net> wrote on 11/09/2015 06:38:29 AM:

> From: Karen Coyle <kcoyle@kcoyle.net>
> To: public-data-shapes-wg@w3.org
> Date: 11/09/2015 06:39 AM
> Subject: 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
>