Re: Are we running out of time?

Hi Holger,

Although it feels (at least to me) like we have been onto this for a 
really long time already it's actually only been 1 year and we have 
another year and a half to go on. Our charter actually ends on 1 June 
2017. So, in reality, and in spite of the unrealistic schedule laid out in 
our charter, we still have over a year to finish our work.

At the same time it should be noted that, while it is typically easy for 
WGs to get a 6 month extension, our charter is longer than the normal 2 
years and we will therefore not as easily get any extension. With that in 
mind here is what I can say: 

We want to get to Proposed Recommendation (PR) no later than March 2017, 
so that our work is basically done. Member review then goes on for 2 
months, so a REC can be published by June 2017.
This being said, I don't think it is wise to take that long. I recommend 
aiming for the end of 2016 to get to PR, the rest of the time can then be 
dedicated to finalizing other deliverables like Primers, etc.

To get to PR, we need to exit Candidate Recommendation (CR) by having 
"enough" implementations, with a test suite and an implementation report.
To get to CR, we need to have closed all issues.

The two big unknowns are: 1) time it will take to close all issues to get 
to CR, 2) time it will take to get enough implementations to exit CR.
Typically 2 months is allocated for CR, so to get to PR at the end of 
2016, we should get to CR no later than September 2016 or so.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - 
IBM Software Group


Holger Knublauch <holger@topquadrant.com> wrote on 11/17/2015 04:58:27 AM:

> From: Holger Knublauch <holger@topquadrant.com>
> To: public-data-shapes-wg@w3.org
> Date: 11/17/2015 04:58 AM
> Subject: Re: Are we running out of time?
> 
> Hi Arnaud,
> 
> could you outline a realistic time line for the remainder of the 
> duration of the WG, i.e. proposed dates for the remaining stages of 
> the publications? This would inform us to what we need to do to 
> accomplish our goals, and which process changes are required if we 
> still want to achieve them.
> 
> Thanks
> Holger
> 
> 
> On 11/13/2015 19:41, Arnaud Le Hors wrote:
> Hi Holger,
> 
> I'm not against creating formal task forces if the WG is interested 
> in doing so but I don't know that this will make much of a 
> difference. We have a small group of active participants and I 
> believe we suffer more from limited bandwidth each of them can 
> dedicate to this work than from lack of structure. (And I'm not 
> blaming anyone, I believe everyone already put a lot more time than 
> it is officially expected when joining). We've already seen that 
> putting up the Proposals wiki page alone didn't help much, for the 
> same reason.
> Anyone is free to work with whomever they want, go offline, and come
> back with proposals. This can also be done using the WG mailing list
> and wiki. But I'm happy to entertain the question and hear what 
> other WG members have to say.
> 
> When it comes to what I expect moving forward, I do think that we 
> may have to reduce the scope of work - and yes, this means, dropping
> some of our requirements. There is nothing original in that. This is
> just normal project management when it becomes obvious you can't 
> meet your deadline.
> We'd be much better off producing a Recommendation in time that is 
> limited in scope but that we can keep building on than reaching the 
> end of our charter with only a WD to show for.
> 
> With that in mind, all I meant to say is that the UI related stuff 
> seems isolated enough that it could be a possible candidate for such
> a cut. I don't expect you to like it. Nobody likes seeing 
> requirements dropped but be prepared for a lot worse if we don't 
> make enough progress.
> 
> (How alarming is that last sentence, now? ;-) I'm serious though.
> --
> Arnaud  Le Hors - Senior Technical Staff Member, Open Web 
> Technologies - IBM Software Group
> 
> 
> Holger Knublauch <holger@topquadrant.com> wrote on 11/12/2015 10:29:57 
PM:
> 
> > From: Holger Knublauch <holger@topquadrant.com>
> > To: public-data-shapes-wg@w3.org
> > Date: 11/12/2015 10:29 PM
> > Subject: Are we running out of time? (was: shapes-ISSUE-113 (SHACL 
> > and user  interfaces): [SHACL Spec])
> > 
> > Hi Arnaud,
> > 
> > I find your last sentence very alarming. It sounds like you are 
> > willing to delete already approved requirements and even rewrite the
> > original charter because we may run out of time. Your previous 
> > suggestion was a "compromise might be to define a small set of such 
> > features packaged together as an optional feature, if there is such 
> > a set we could agree on". If the recent evidence is anything to go 
> > by, then we will not be able agree on these features. Likewise, 
> > almost every proposal on the wiki page has a -1 from someone.
> > 
> > So what is next: "Sorry, we ran out of time and someone voted -1, so
> > let's delete templates, functions and other random stuff". I am very
> > worried that the outcome of this WG will be a useless language.
> > 
> > Could we please create task forces to push key issues forward and 
> > then present worked out proposals. One such task force could work on
> > the UI stuff. Another task force could look into the Turtle file and
> > template metamodel. Another topic could be the proper definition of 
> > recursion. Some of these topics require more bandwidth than group 
> > emails and weekly meetings provide.
> > 
> > If we are starting to run out of time, then I think we need to 
> > change the process. I would also like to hear how you imagine the 
> > remaining time line of the WG, i.e. when are which deliverables 
planned?
> > 
> > Thanks
> > Holger
> > 
> 
> > On 11/13/15 1:39 PM, Arnaud Le Hors wrote:
> > Holger,
> > Sorry, but I disagree with your interpretation of the situation.
> > 
> > First, saying that there is no cost to adding annotations is simply 
> > false. It takes time to agree to every single one of them. Someone 
> > has to propose it, others have to read and understand what they 
> > mean. We discuss them, argue, etc.
> > 
> > Then unless they are optional, it adds to the implementation burden.
> > It will take time to develop tests for them (and we already said we 
> > aren't even sure how we would do that), time to gather 
> > implementation reports, etc.
> > 
> > This is hardly free.
> > 
> > While I certainly agree with you that it is part of our charter, 
> > this clearly hasn't been much of our focus to date and, given the 
> > amount of time it is taking to address the validation use case which
> > nobody is interested in, I think it is reasonable for us to postpone
> > if not give up entirely on the UI stuff. I'm happy to explain that 
> > to W3M if need be.
> > --
> > Arnaud  Le Hors - Senior Technical Staff Member, Open Web 
> > Technologies - IBM Software Group
> > 
> > 
> > Holger Knublauch <holger@topquadrant.com> wrote on 11/12/2015 06:23:20 
PM:
> > 
> > > From: Holger Knublauch <holger@topquadrant.com>
> > > To: public-data-shapes-wg@w3.org
> > > Date: 11/12/2015 06:24 PM
> > > Subject: Re: shapes-ISSUE-113 (SHACL and user interfaces): [SHACL 
Spec]
> > > 
> > > On 11/13/2015 7:23, RDF Data Shapes Working Group Issue Tracker 
wrote:
> > > > shapes-ISSUE-113 (SHACL and user interfaces):  [SHACL Spec]
> > > >
> > > > http://www.w3.org/2014/data-shapes/track/issues/113
> > > >
> > > > Raised by: Peter Patel-Schneider
> > > > On product: SHACL Spec
> > > >
> > > > The WG charter includes the goal of "Human and machine 
> > > interpretation of shapes to [...] develop user interfaces."
> > > >
> > > > SHACL includes shapes and constraints.  Most constraints are 
> > > expected to be property or inverse property constraints.
> > > >
> > > > These SHACL features provide a backbone for the development of 
> > > user interfaces related to shapes.   UI tools can, for example, use 
> > > property and inverse property constraints to determine which 
> > > properties should be part of an input form to create data that 
> > > conforms to a shape.  Because shapes and contstraints are nodes in 
> > > RDF graphs they can have extra information associated with them that
> > > can be exploited by user interface tools.
> > > >
> > > >
> > > > PROPOSAL:  As the RDF Data Shapes working group does not have 
> > > sufficient expertise to create a good set of features for UI 
> > > creation it should stop at providing this backbone and let those who
> > > build user interfaces design the information needed for connecting 
> > > SHACL shapes and constraints to UI tools.   To conform with this 
> > > sentiment, sh:defaultValue will be removed from the SHACL 
vocabulary.
> > > 
> > > The assumption "As the RDF Data Shapes WG does not have sufficient 
> > > expertise..." is incorrect. Furthermore, default values are an 
approved 
> > > requirement. I'll vote -1 for this proposal and propose to close 
this 
> > > ticket without action.
> > > 
> > > Peter, you have made it clear many times that you don't think the 
> > > Charter should have included UI features. But that decision was made 

> > > long ago, so I encourage you to accept other people's view points. I 

> > > have also seen features that I personally don't like and would 
prefer to 
> > > not have to work on. However, if there is little or no cost 
involved, 
> > > then this didn't cause me to block others from getting those 
features. 
> > > In other words: If you don't need the UI features, just ignore them. 

> > > Being destructive about them is only poisoning the working climate 
in 
> > > the WG.
> > > 
> > > Holger
> > > 
> > >