Meeting minutes
Agenda Review
<kaz> Agenda for today
Koster: we will start with the use cases discussion
… if others join, we can start the other topics
Minutes
<kaz> Oct-9
Koster: any correction?
… no comments for October 9
<kaz> Oct-10
Koster: any correction for october 10?
… no comments. So both minutes are approved
Use Cases
Koster: we want to work on TD use cases in the TD call
… we did good progress in the uc call
… now we want to take it further
… for small use cases or feature requests, we think that a small paragraph will be needed in any case
Feature Request terminology
wot-usecases Issue 304 - Define "Feature Request" terminology
Ege: The links that are provided by mccool, there is a request from W3C for us to note if we have satisfied requirements
Koster: ok that makes sense
Kaz: I have provided this kind of information in the last UC calls. What the W3C Process requires us to provide is the fact and proof that the draft spec meets the requirements for the spec, and to extract requirements, we need to define use cases clearly.
… we need to agree on the definition of three terms: use case, requirement and feature request
Koster: so we should have a list of requirements
Koster: there were opinions about saying that we should require use cases when the TD expressivity increases
… so document reorganization would not need it
Ege: first of all, we need a list of requirements when we go for CR transition. Not really about each change
… we are not clearly documenting them
Kaz: we have requirements for previous 1.0 and 1.1 documents also issues as well
… so the requirements at that time were described by github issues
… we can reuse the existing information
Koster: can we just state the new requirements for the td 2.0 or do we need to list all the requirements from before as well?
Kaz: using the draft terms from mccool, the implementation report have the list of features
Ege: we cannot do this discussion without examples. We can take the examples from Daniel and Jan to dissect them into use case, requirement and feature
… otherwise we need 5h per week to do discussions for TD topics and WG level use case discussions
Kaz: We should not go into details
… issue 304 can be discussed later. We can discuss TD use cases
… if we have time, we should discuss our proposals, to which mccool said are "feature requests". We should define these
Daniel and Jan's Submission
<kaz> wot-thing-description Issue 2039 - Using the New Use Case Template and Gathering Experience
Koster: is the one from Daniel a big or small feature request?
… this definitely adds something to the TD
Daniel: there is a way to implement this without changing the TD spec by just adding a new action affordance
Koster: whether it changes or not, it is easy to talk about it
… there is of course a discussion to be made about design of the feature
Koster: still I don't see a crips definition of large or small. it is probably understood once we start analyse it
Kaz: we can decide based on informative or normative changes
… any normative change should have a reasoning behind, but the description can be short enough.
… large or small is difficult to say since they do not have any weight
Ege: I think normative or informative should not be important. All features are normative in the end
… this specific submission: modeling as an action would not be a good design
… I think that if it is easy to discuss it, it can be "small" use case submission. The requirement should be clear
Koster: if we can put some github labels, that would be a good step
Cristiano: it is becoming clear that it is difficult to define a small or large use case
… it will be a confusion for the submitter as well
… why not approach it dynamically? We can discuss and if there is no quick consensus, we can ask them for a long use case submission
Cristiano: this specific one is clear for us
… sometimes you realize that a user story is not enough when you are writing
… we can overrule to submitter and ask for more information
Kaz: I think there is no big difference between my point and cris and ege's point
… such submissions like from jan and daniel are normative and should still have a description
Ege: all feature changes need a description. I think we are all aligned on that
Koster: we bring out the big template if it cannot be solved easily
Ege: How about having three categories. textual changes, refactoring and feature change
Koster: it would be good to note these down
Ege: I like the proposal from jan: "editorial", "clarfication", and "new feature"
Kaz: I think that is a good starting point
<kaz> [adjourned]