12:56:25 RRSAgent has joined #wot-td 12:56:29 logging to https://www.w3.org/2024/10/31-wot-td-irc 12:56:34 meeting: WoT-WG - TD-TF - Slot 2 12:57:14 agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#October_30-31%2C_2024 12:57:25 present+ Kaz_Ashimura 12:57:30 rrsagent, make log public 12:57:35 rrsagent, draft minutes 12:57:36 I have made the request to generate https://www.w3.org/2024/10/31-wot-td-minutes.html kaz 12:59:47 JKRhb has joined #wot-td 12:59:55 present+ Jan_Romann 13:01:05 present+ Michael_McCool 13:02:07 present+ Ege_Korkan 13:02:23 Mizushima has joined #wot-td 13:02:26 present+ Michael_Koster 13:03:13 present+ Kunihiko_Toumura 13:03:17 rrsagent, draft minutes 13:03:19 I have made the request to generate https://www.w3.org/2024/10/31-wot-td-minutes.html kaz 13:05:06 chair: Ege 13:05:55 McCool has joined #wot-td 13:05:59 scribenick: JKRhb 13:06:05 topic: Agenda Review 13:06:10 present+ Tomoaki_Mizushima 13:06:24 ek: Today, we will mostly work on the use cases coming frmo the TD 13:06:30 i|Today|-> https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#October_30-31%2C_2024 agenda for today| 13:06:38 ... but first we are going to take a look at the minutes from last week, Thursday 13:06:47 topic: Minutes Review 13:06:48 -> https://www.w3.org/2024/10/24-wot-td-minutes.html Oct-24 13:07:07 ek: Wasn't there, but I talked to Michael Koster and Kaz, will scroll over them, let me know if you notice anything 13:07:15 ... (scrolls through the minutes) 13:07:17 q? 13:07:39 ... okay, I don't see anything, so I assume that there are no remarks regarding the minutes and that they are approved 13:07:46 Minutes are approved 13:07:56 topic: TD 13:08:17 ek: I think we agree that all changes no matter the size should have an explanation 13:08:30 ... be it issues, meeting minutes, or documentation 13:08:41 ... do other people have different opinions? 13:09:02 ek: I am just saying that changes should have a description 13:09:13 mm: I think we are still bundling together use cases and user stories 13:09:23 ... I think we should seperate the two more clearly 13:09:30 ... fine to submit new use cases 13:09:47 ... no need to do a one-to-one mapping, just to be clear 13:10:02 ... have prepared a template that we can take a look at 13:10:15 mjk has joined #wot-td 13:10:15 ek: But you agree that any changes need a textual description? 13:10:23 q+ 13:10:51 mm: Agree, need to be grounded in some kind of user story, explaining the connection and who wants it, i.e. the stakeholder 13:11:08 proposal: all changes to the TD specification MUST be grounded by a textual description on why the change was needed 13:11:13 ... user story should be summarized in one sentence, but the template allows for more detail if necessary 13:11:35 ... to explain technical details, but that should probably rather go into a technical description of a work item 13:11:38 q? 13:11:44 ek: Just posted a proposal in the IRC 13:11:53 mm: I agree with the proprosal 13:12:06 kaz: Personally agree with you two, Michael and Ege 13:12:08 q+ 13:12:21 ... I think there is not much differences between your approaches 13:12:46 ... I think Ege is looking at the matter more from a bottom-up view, while Michael has a top-down view 13:12:58 ... therefore, we need to clarify use cases and user stories 13:13:08 mm: I think Ege is more about documentation 13:13:14 ... giving a reason 13:13:18 q- 13:13:21 ... instead of top-down or bottom-up 13:13:41 ... can do the documentation in various ways, need to agree on how to do it 13:13:54 ek: Are there any objections to the proposal above then? 13:14:05 proposal: all changes to the TD specification MUST be grounded by a textual description on why the change was needed 13:14:36 rrsagent, draft minutes 13:14:37 I have made the request to generate https://www.w3.org/2024/10/31-wot-td-minutes.html kaz 13:14:45 i|objections|... I agree that the proposal is just a high-level view| 13:15:06 Resolution: all changes to the TD specification MUST be grounded by a textual description on why the change was needed 13:15:16 ek: If there are no objections, then I would turn it into a resolution 13:15:26 The resolution is accepted 13:15:40 i/I think we agree/subtopic: Basic consensus/ 13:15:48 subtopic: Work Items 13:15:49 rrsagent, draft minutes 13:15:50 I have made the request to generate https://www.w3.org/2024/10/31-wot-td-minutes.html kaz 13:16:50 ek: I think the reusable connections work item is a good example for how we want to approach work items in general 13:16:59 ... (shows the current markdown document) 13:17:37 ... all of the work items should have a similar documentation and rationale, detailing what is "annoying" the developers 13:18:06 ... I discussed with Kaz and MJK that this is enough from the W3C Process point of view 13:18:21 s/subtopic: Work Items/subtopic: Necessary Description for Work Items/ 13:18:27 mm: I think this is excellent work, also explaining some requirements 13:18:50 i|i|I think the reusa|-> https://github.com/w3c/wot-thing-description/blob/main/planning/work-items/usability-and-design.md#reusable-connections Work Items| 13:18:56 rrsagent, draft minutes 13:18:57 I have made the request to generate https://www.w3.org/2024/10/31-wot-td-minutes.html kaz 13:19:03 ... I think we need to make the connection back to the end user scenario 13:19:16 ek: True, currently this is more written from the developer's point of view 13:19:37 mm: I think that is fine, we just need to put the end user's point of view on top of that 13:19:39 s/connections Work Items/connections Work Items document - "Reusable Connections" as an example work item/ 13:19:41 rrsagent, draft minutes 13:19:43 I have made the request to generate https://www.w3.org/2024/10/31-wot-td-minutes.html kaz 13:20:12 q+ 13:20:24 ek: Is already covered to a certain degree and already possible with the current TD version. But currently have a reverse process that maps new issues to the work item 13:20:42 mm: I think generally, an issue should identify a problem 13:20:59 ... bundling issues together to a work item is fine 13:21:33 q? 13:21:33 ... my suggestion would be deferring the documentation of the existing features and focus on new features 13:21:43 ack m 13:22:08 q+ 13:22:18 kaz: I think for that purpose the problem statement here should not only include the problem statement from the developer's viewpoint but also the end user's 13:22:43 ... could be added as a subsection 13:23:01 mm: I would rather put that into a different document in order not blow things up 13:23:13 kaz: Maybe you misunderstood me 13:23:20 ... don't think this is an actual template 13:23:29 Mizushima has joined #wot-td 13:24:02 ... it is more like a general description of work items and since you mentioned that user stories need to mentioned, I thought we should maybe put it here 13:24:28 mm: I would rather not do that and keep user stories separate, in a separate .md item and then link to them 13:24:48 kaz: I am okay with that, I was not focusing on the acutal Markdown files 13:25:29 ... I am not saying that we should put everything into one file, I am rather talking about what information needs to be put into a work item 13:25:59 mm: There is a feature request, which is talking about what is needed and why, that could include a use case and a user story 13:26:27 kaz: Maybe before diving into the details about work items, we might want to think about the format for user stories 13:26:39 mm: We also need to think about the internal process 13:27:13 ... also need to cover that, for now we can just use a template for PRs (?) 13:27:40 ... I would propose that user stories and feature requests become individual files that can be submitted via PRs 13:27:58 ... in general, I try to avoid adding new use cases, as we have enough already 13:28:15 ... I am talking about the general process 13:28:27 ... my suggestion is not making it more complicated than necessary 13:28:45 ... explain it in the README somewhere, provide a template for PRs 13:29:07 kaz: I am okay with the original approach, but also with discussing work items later 13:29:27 ek: The current Markdown file is already very verbose 13:29:45 luca_barbato has joined #wot-td 13:29:53 ... readers cannot trace back features to use cases really well at the moment 13:30:03 ... is also not demanded by the W3C process 13:30:06 s/I am okay with the original approach, but also with discussing work items later/I'm OK with either approach, (1) Ege's approach starting with the work items here or (2) McCool's approach once thinking about the process instead./ 13:31:07 i|The current|-> https://github.com/w3c/wot-thing-description/blob/main/planning/work-items/usability-and-design.md Work usability-and-design.md| 13:31:10 rrsagent, draft minutes 13:31:12 I have made the request to generate https://www.w3.org/2024/10/31-wot-td-minutes.html kaz 13:31:18 ... Web of Things is more about developers, not that much about end users, the developers are the ones that care about the end users 13:31:22 mm: We need to provide the context 13:31:39 ek: That is a good way to approach it 13:31:55 q+ 13:32:07 q- 13:32:14 ... going back user stories, having a single sentence summary for the user story would be nice, also for putting it into the TD spec 13:32:33 mm: My intention is to collect user stories and put them into the use cases and requirements document 13:32:44 s/process instead./process instead. Ege, how do you want to handle it?/ 13:32:45 ... or rather the user stories and requirements document 13:32:46 rrsagent, draft minutes 13:32:47 I have made the request to generate https://www.w3.org/2024/10/31-wot-td-minutes.html kaz 13:32:59 ... for linking back to them from the individual specifications 13:33:09 ... want to extract and publish them eventually 13:33:27 ... my reason to put them into separate files is to be able to link to them 13:33:45 q? 13:33:49 present+ Cristiano_Aguzzi, Jan_Romann 13:33:53 ... but also to put them into a document and have them as a publicly visible motivation 13:33:58 ack m 13:34:00 rrsagent, draft minutes 13:34:01 I have made the request to generate https://www.w3.org/2024/10/31-wot-td-minutes.html kaz 13:34:08 ... is fine to put them with the rest, but eventually we should break them out 13:34:26 ek: I always think about the developer 13:34:38 ... let's take "observable" as an example 13:34:57 ... would like to provide a way to link back to the "backstory" 13:35:20 mm: At the end, we have assertions, to which we can link from user stories 13:35:49 ... would be fine to link to the assertions from the work items, not necessary to link the other way around 13:36:00 ek: Agree with that 13:36:07 mm: For that we need stable links 13:36:21 ... linking into the other direction might complicate things 13:36:36 ... with the assertion ID, you can search the work items for it 13:36:52 q+ 13:36:58 ... not as easier as a hyperlink, but it will still be connected 13:37:15 kaz: The mapping between user story and feature is useful, totally agree 13:37:31 cris has joined #wot-td 13:37:35 q+ 13:37:37 ... but my the W3C Process point of view, we also need a link from the requirements to the work items 13:37:41 q- 13:37:44 s/my/from/ 13:38:24 mm: If you have user stories separately and work items separately, then we can link from both to each other 13:38:43 q? 13:38:52 ... to me a user story that says that it needs reusable connections is good enough 13:39:19 kaz: @@@ 13:39:53 mm: The user stories connect the uses cases and the work items 13:40:05 ... and then we can link between them 13:40:18 ... do not need bidirectional linking, can just search 13:40:23 ... but we need stable links 13:40:31 s/@@@/as another high-level discussion, I think everybody here is OK with clarifying the mapping among (1) Use stories, (2) Requirements, (3) Work Items and (4) Features within specs/ 13:40:56 q? 13:40:58 ... trouble with linking everything into a MD file is that changing the title might break the link, prefer linking to files instead 13:41:12 s/linking everything/putting everything/ 13:41:18 ca: Just wondering 13:41:25 ... I am okay with not putting the back link 13:41:29 q+ 13:41:35 s/Use stories/User Stories/ 13:41:37 ... but wondering why we cannot make it handy for them 13:41:56 ... wondering why we cannot just put a back link there 13:42:08 mm: My rationale is that it requires a lot of maintenance 13:42:24 ... can always just put everything into a note and then link to that 13:42:27 q+ 13:42:38 ... but it does not have that much benefit, while causing us a lot of work 13:42:58 ca: Got it, in the CG we were asked about that, so I was just wondering 13:43:11 ack c 13:43:15 mm: Something we can do is putting it into the implementation report eventually 13:43:16 ack m 13:43:57 kaz: I can understand what Michael McCool means and I am generally also okay with that. Potentially we could also think about using some additional tooling for that 13:44:22 ... however, we should probably rather focus on the content and what should be linked first 13:44:34 q- 13:44:40 mm: I am fine if Ege would provide the tooling necessary 13:44:50 q+ 13:44:54 s/tooling necessary/necessary tooling/ 13:45:00 s/Potentially/However, potentially/ 13:45:17 ek: I am a bit lost at the moment what is needed from the W3C Process point of view 13:45:31 s/tooling for that/tooling for that if cross-reference linking would be really useful./ 13:45:44 mm: You are dealing an excellent job, Ege, we just need to provide one sentence that links everything together 13:45:55 rrsagent, draft minutes 13:45:56 I have made the request to generate https://www.w3.org/2024/10/31-wot-td-minutes.html kaz 13:46:05 ... we just need to have an "elevator pitch" for each feature 13:46:27 ek: Let's go to your proposal from last time in the minutes 13:46:35 ... have you updated your minutes, yet? 13:46:46 mm: I did, there is also a PR in the use cases repo 13:46:48 q+ 13:47:04 s/your minutes/your presentation/ 13:47:25 mm: The template now contains Who, What, Why, and optional Details 13:47:33 s/in the minutes/in your presentation/ 13:47:36 rrsagent, draft minutes 13:47:37 I have made the request to generate https://www.w3.org/2024/10/31-wot-td-minutes.html kaz 13:47:43 s/optional Details/optional details/ 13:48:11 ... so, for example, a "What" would be reusable connections 13:48:28 ek: (Starts filing out the template for the work item) 13:49:07 ek: So the "Why" could be to support connection-oriented protocol or cases without the usage of default terms 13:49:07 q? 13:49:13 ack m 13:49:17 mm: Could also be split into two user stories 13:49:28 ... might be a better way to strucutre it and make things easier 13:49:51 ... I would also say "to support connection-oriented protocols like MQTT and WebSockets" 13:50:05 ek: Or rather "to better describe" 13:50:07 mm: Sure 13:50:40 ... the "What" part for the second user story would be the same 13:51:22 ... maybe we also need to identify sub problems 13:51:55 ... the "Who" for the first user story would be something like a "deployer of devices with connection-oriented protocols" 13:52:00 ... can be exm 13:52:11 s/can be exm/can be expanded upon later/ 13:52:26 ek: The second one could be the person that is making the TDs 13:52:37 mm: So you see, the two user stories have different targets 13:53:00 ... for problems, you could also have headers for the subcategories which you could link to 13:53:35 ... so the second user story is also about avoiding redundancy 13:53:44 q? 13:53:45 ... I think from this work, we learned something 13:54:01 ... that there are sub-problems and there are actually different user categories 13:54:19 ek: I think the user stories will help us writing the problems 13:54:38 mm: Will also help us linking giving a reason for our features 13:54:46 ... could also be only single sentences 13:55:13 ... use cases can then also be linked later, like greehouse or webthings 13:55:34 ek: Kind of reveals, that the use cases are kind of irrelevant for standardization 13:55:49 mm: But it is still in your head, you just need to write it down 13:56:17 ... could also come from the other direction, I want to build a greenhouse, but I don't know that I could use Web of Things for that 13:56:28 ... so this direction is also useful for this kind of people 13:56:38 kaz: I am okay with the list and this looks good 13:56:52 ... just wanted to give some more explanation of the W3C Process 13:57:19 ... at the transition stage, we need to link all the features to requirements 13:57:41 ... having use cases would be useful for ourselves to understand the rquirements, so this approach is good 13:58:05 ... my only question is whether we really want to turn the answers to the questions into single sentences 13:58:18 mm: We don't have to, but it forces you to be concise 13:58:43 kaz: I think it would be nice to have more questions, like "how", but maybe that could be added later 13:59:12 mm: We could add something like "When", for example, but usually it is only "Who", "What", and "Why" 13:59:27 ... that is the usual style 13:59:45 ... can also be more than one sentence, but it should not be more than one line in general 13:59:50 topic: AOB 13:59:56 ek: Any other business? 13:59:58 s/later/later (=not within this "user stories" template, but at the later stage)/ 14:00:01 rrsagent, draft minutes 14:00:03 I have made the request to generate https://www.w3.org/2024/10/31-wot-td-minutes.html kaz 14:00:09 [adjourned] 14:00:54 |i|adjourned|... not hearing anything, so we can adjourn the call| 14:01:00 rrsagend, draft minutes 14:01:30 s/rrsagend, draft minutes// 14:01:33 rrsagent, draft minutes 14:01:35 I have made the request to generate https://www.w3.org/2024/10/31-wot-td-minutes.html JKRhb 14:01:41 s/whether we really want to turn the answers to the questions into single sentences/whether we really want to turn the descriptions into consolidated single sentences or not/ 14:01:41 rrsagent, draft minutes 14:01:42 I have made the request to generate https://www.w3.org/2024/10/31-wot-td-minutes.html kaz 14:05:11 s/I think it would be nice to have more questions, like "how"/I personally think the current style having "Who", "What" and "Why" is nicer and clearer. In addition, we might want to have some more questions like "How" and "When"./ 14:06:04 rrsagent, draft minutes 14:06:05 I have made the request to generate https://www.w3.org/2024/10/31-wot-td-minutes.html kaz 14:06:35 s/.,/,/ 14:06:42 s/stage)/stage)./ 14:06:43 rrsagent, draft minutes 14:06:45 I have made the request to generate https://www.w3.org/2024/10/31-wot-td-minutes.html kaz 14:07:47 i|[adjourned]|... not hearing anything, so we can adjourn the call| 14:07:50 rrsagent, draft minutes 14:07:51 I have made the request to generate https://www.w3.org/2024/10/31-wot-td-minutes.html kaz 16:00:19 Zakim has left #wot-td