13:02:22 RRSAgent has joined #wot-td 13:02:26 logging to https://www.w3.org/2024/10/17-wot-td-irc 13:02:28 meeting: WoT-WG - TD-TF - Slot 2 13:02:34 chair: Ege 13:02:53 present+ Kaz_Ashimura, Michael_Koster, Ege_Korkan, Jan_Romann, Kunihiko_Toumura 13:03:24 agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#October_16-17%2C_2024 13:04:14 q+ 13:04:36 q- 13:07:12 scribeick: EgeKorkan 13:07:26 scribenick: EgeKorkan 13:07:33 s/scribeick: EgeKorkan// 13:07:38 rrsagent, make log public 13:07:43 rrsagent, draft minutes 13:07:44 I have made the request to generate https://www.w3.org/2024/10/17-wot-td-minutes.html JKRhb 13:07:55 chair: Koster 13:08:02 topic: Agenda Review 13:08:14 -> https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#October_16-17%2C_2024 Agenda for today 13:08:23 mk: we will start with the use cases discussion 13:08:28 q? 13:08:29 ... if others join, we can start the other topics 13:08:45 topic: Minutes 13:08:54 -> https://www.w3.org/2024/10/09-wot-td-minutes.html Oct-9 13:09:35 mk: any correction? 13:10:10 ... no comments for October 9 13:10:53 ... any correction for october 10? 13:11:03 ... no comments. So both minutes are approved 13:11:30 topic: Use Cases 13:11:51 i|any corr|-> https://www.w3.org/2024/10/10-wot-td-minutes.html Oct-10| 13:12:02 rrsagent, draft minutes 13:12:03 I have made the request to generate https://www.w3.org/2024/10/17-wot-td-minutes.html kaz 13:12:11 present+ Daniel_Peintner 13:12:15 mk: we want to work on TD use cases in the TD call 13:12:23 ... we did good progress in the uc call 13:12:29 ... now we want to take it further 13:13:37 ... for small use cases or feature requests, we think that a small paragraph will be needed in any case 13:13:42 q? 13:14:09 dape has joined #wot-td 13:14:17 https://github.com/w3c/wot-usecases/issues/304 13:15:36 i|304|subtopic: Feature Request terminology| 13:16:00 s|https://github.com/w3c/wot-usecases/issues/304|-> https://github.com/w3c/wot-usecases/issues/304 wot-usecases Issue 304 - Define "Feature Request" terminology| 13:16:05 rrsagent, draft minuts 13:16:05 I'm logging. I don't understand 'draft minuts', kaz. Try /msg RRSAgent help 13:16:37 rrsagent, draft minutes 13:16:38 I have made the request to generate https://www.w3.org/2024/10/17-wot-td-minutes.html kaz 13:16:44 q+ 13:17:42 ek: The links that are provided by mccool, there is a request from W3C for us to note if we have satisfied requirements 13:17:52 mk: ok that makes sense 13:19:36 q? 13:19:43 kaz: I have provided this kind of information in the last UC calls 13:19:44 ack k 13:19:57 ... we need to agree on the definition of three terms: use case, requirement and feature request 13:20:48 s/UC calls/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./ 13:21:16 mk: so we should have a list of requirements 13:21:18 q+ 13:23:02 mk: there were opinions about saying that we should require use cases when the TD expressivity increases 13:23:17 ... so document reorganization would not need it 13:24:38 rrsagent, draft minutes 13:24:39 I have made the request to generate https://www.w3.org/2024/10/17-wot-td-minutes.html kaz 13:26:04 q? 13:26:07 ack e 13:27:16 ek: first of all, we need a list of requirements when we go for CR transition. Not really about each change 13:28:14 ... we are not clearly documenting them 13:28:28 kaz: we have requirements for previous 1.0 and 1.1 documents also issues as well 13:28:44 ... so the requirements at that time were described by github issues 13:29:18 ... we can reuse the existing information 13:30:13 mk: 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? 13:31:46 s/requirements for the spec./requirements for the spec, and to extract requirements, we need to define use cases clearly./ 13:31:49 rrsagent, draft minutes 13:31:51 I have made the request to generate https://www.w3.org/2024/10/17-wot-td-minutes.html kaz 13:32:13 kaz: using the draft terms from mccool, the implementation report have the list of features 13:32:53 q+ 13:33:49 ek: 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 13:34:17 ack k 13:34:19 ... otherwise we need 5h per week to do discussions for TD topics and WG level use case discussions 13:34:26 kaz: We should not go into details 13:36:34 ... issue 304 can be discussed later. We can discuss TD use cases 13:36:54 cris has joined #wot-td 13:36:57 ... if we have time, we should discuss our proposals, to which mccool said are feature requests. We should define these 13:37:23 s/feature requests/"feature requests"/ 13:38:05 q+ 13:38:44 ack dape 13:38:57 subtopic: Daniel and Jan's Submission 13:39:28 mk: is the one from Daniel a big or small feature request? 13:39:52 ... this definitely adds something to the TD 13:40:12 q+ 13:40:27 present+ Cristiano_Aguzzi 13:41:10 i|is the one|-> https://github.com/w3c/wot-thing-description/issues/2039 wot-thing-description Issue 2039 - Using the New Use Case Template and Gathering Experience| 13:41:17 rrsagent, draft minutes 13:41:18 I have made the request to generate https://www.w3.org/2024/10/17-wot-td-minutes.html kaz 13:43:01 dp: there is a way to implement this without changing the TD spec by just adding a new action affordance 13:43:16 ack dape 13:43:39 mk: whether it changes or not, it is easy to talk about it 13:43:54 q+ 13:43:58 ... there is of course a discussion to be made about design of the feature 13:44:02 q? 13:44:13 q? 13:44:20 q+ 13:44:47 q+ 13:45:45 mk: still I don't see a crips definition of large or small. it is probably understood once we start analyse it 13:46:51 kaz: we can decide based on informative or normative changes 13:47:00 ... any normative change should have a reasoning behind 13:47:46 ... large or small is difficult to say since they do not have any weight 13:51:43 ek: I think normative or informative should not be important. All features are normative in the end 13:52:00 ... this specific submission: modeling as an action would not be a good design 13:52:18 ... I think that if it is easy to discuss about it, it can be "small" use case submission. The requirement should be clear 13:52:32 mk: if we can put some github labels, that would be a good step 13:53:16 ca: it is becoming clear that it is difficult to define a small or large use case 13:53:21 q+ 13:53:27 ... it will be a confusion for the submitter as well 13:53:49 s/discuss about/discuss/ 13:54:03 ... 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 13:54:15 q: 13:54:20 q? 13:54:23 ... this specific one is clear for us 13:54:24 ack e 13:54:26 ack c 13:54:45 ... sometimes you realize that a user story is not enough when you are writing 13:54:51 s/behind/behind, but the description can be short enough./ 13:54:59 ... we can overrule to submitter and ask for more information 13:55:35 kaz: I think there is no big difference between my point and cris and ege's point 13:56:26 ... such submissions like from jan and daniel are normative and should still have a description 13:58:06 ek: all feature changes need a description. I think we are all aligned on that 13:58:53 mk: we bring out the big template if it cannot be solved easily 14:01:15 ack k 14:01:29 ek: How about having three categories. textual changes, refactoring and feature change 14:01:44 mk: it would be good to note these down 14:01:54 q+ 14:02:23 q+ 14:02:30 ek: I like the proposal from jan: "editorial", "clarfication", and "new feature" 14:02:34 ack m 14:02:42 ack k 14:02:43 kaz: I think it is a good starting point 14:03:00 s/it is/that is/ 14:03:37 JKRhb has left #wot-td 14:03:40 [adjourned] 14:03:45 rrsagent, draft minutes 14:03:46 I have made the request to generate https://www.w3.org/2024/10/17-wot-td-minutes.html kaz 16:04:55 Zakim has left #wot-td