13:57:17 RRSAgent has joined #webmachinelearning 13:57:21 logging to https://www.w3.org/2023/04/13-webmachinelearning-irc 13:57:21 RRSAgent, make logs Public 13:57:52 please title this meeting ("meeting: ..."), anssik 13:57:52 Meeting: WebML WG Teleconference – 13 April 2023 13:57:52 Chair: Anssi 13:57:52 Agenda: https://github.com/webmachinelearning/meetings/blob/main/telcons/2023-04-13-wg-agenda.md 13:57:52 Scribe: Anssi 13:57:52 scribeNick: anssik 13:57:52 scribe+ dom 13:57:57 ghurlbot, this is webmachinelearning/webnn 13:57:57 anssik, OK. 13:58:03 Present+ Anssi_Kostiainen 13:58:12 RRSAgent, draft minutes 13:58:13 I have made the request to generate https://www.w3.org/2023/04/13-webmachinelearning-minutes.html anssik 13:58:59 RafaelCintron has joined #webmachinelearning 13:59:34 Present+ Rafael_Cintron 14:01:44 ningxin_hu has joined #webmachinelearning 14:01:52 Present+ Ningxin_Hu 14:02:08 Present+ Zoltan_Kis 14:02:37 Present+ Rachel_Yager 14:03:55 zkis has joined #webmachinelearning 14:04:03 Rachel has joined #webmachinelearning 14:04:21 Present+ Chai_Chaoweeraprasit 14:05:06 Topic: Charter 2023-2025 W3C Advisory Committee review completed 14:05:23 anssik: Thank you for your support and comments! 14:05:32 chai has joined #webmachinelearning 14:05:49 ... We were able to fast-track the operationalization of the new charter and can now initiate discussions on WebNN v2 features. 14:06:00 -> Call for Participation: https://lists.w3.org/Archives/Public/public-webmachinelearning-wg/2023Apr/0000.html 14:06:16 anssik: CfP requires no action for existing participants. 14:06:24 -> Charter 2023-2025 https://www.w3.org/2023/04/web-machine-learning-charter.html 14:06:42 We received some review comments, the publicly shared are documented in issues and PRs: 14:06:47 -> Editorial changes https://github.com/w3c/machine-learning-charter/pull/33 14:06:55 -> Transformer use cases https://github.com/webmachinelearning/webnn/issues/375 14:07:20 -> Speech synthesis use cases https://github.com/w3c/machine-learning-charter/issues/31 14:08:02 anssik: any questions re the new charter? 14:08:05 [none] 14:09:00 Topic: WebNN - styling and structural changes, automation 14:09:15 Subtopic: Review proposed spec styling and structural changes 14:09:19 anssik: Zoltan has been working on the styling and structural changes based on the feedback from our last call. 14:09:25 ... he can share with us the latest style revamp. 14:10:02 Zoltan: on our last call we agreed we want to see all the stylistic changes in the spec first w/o algos 14:10:33 ... we wanted to add extand/collapse all UI 14:10:33 [ Zoltan sharing his latest render ] 14:12:19 Zoltan: the spec appears with collapsible algorithms and examples, they can be expanded one by one also 14:14:32 Subtopic: Discuss opportunities for automation 14:14:45 Zoltan: we checked some bikeshed features for templating 14:15:17 anssik: want to note bikeshed tool supports file-based includes and simple templating with text replacement via macros 14:15:17 14:15:17 https://speced.github.io/bikeshed/#bp-include 14:15:17 https://speced.github.io/bikeshed/#bp-new 14:16:00 Zoltan: I don't see a proper solution to automate this fully with the existing spec and build tools 14:17:21 ... this is an interesting side project, all the web specs could benefit from further automation integrated into tooling 14:17:39 ... if someone has tools for autogeneration then generated code could be used as input to write the spec steps 14:19:06 Chai: when the spec becomes this big it is harder to make changes to it, I don't have a good suggestion to this at this point 14:21:43 Zoltan: adding new ops is manageable by me, so I think other folks will be able to do the same 14:21:55 ... copy-paste and modify for the context is doable 14:23:24 Chai: I've looked at a number of PRs, I appreciate the effort put into this 14:23:49 ... I want to try to see how we can do this in a way it is efficient and how we can incorporate the good ideas brought to the spec 14:24:19 ... I'd like to categorize the general process how we change the content of the spec in the last few years, highlight how we've done this in the past and now with these editorial changes 14:25:46 ... it feels like these recent changes made editors' task a bit harder, so we should agree on consistency in content management, we'll be adding new ops in v2, we've prototyped a lot of those 14:25:56 Chai: different change categories: 14:26:50 ... 1) Stylistic, changes to stylesheets, easy to review, improve readability, easy to get it done, no normative changes 14:28:41 ... 2) Wording changes, specifically focused on wordings that someone spots and thinks is inappropriate, typically focused changes, use case changes to be more inclusive, easy to review as self-contained, but not always 14:28:56 q+ 14:30:06 ... 3) Fixing issues, changes that require editor attention, when sometimes is wrong in the spec, minor or major issue, typically documented in a GH issue with details, maybe an enhancement, e.g. an op needs an additional parameter 14:31:08 ... in this category there is a GH issue with discussion and then PR that fixes the issue, no debate in the PR on the issue, issue document the discussion and consensus 14:31:48 ... multiple issues open by multiple people, editor may look at consistency across the issues and look all together and propose the best course of action 14:32:46 ... 4) New content, add new ops, here's why with likely uber issue defining the rationale, this category is the most time consuming for the editor, need to understand the direction and keep the API consistent with the charter 14:33:16 Chai: these are the 4 categories of changes, the common characteristic is that they are all time-bound, not random 14:34:09 ... you want to make sure that the change the person works on gets checked in, so other people can contribute, with bikeshed editor is a "traffic cop" to manage contribution order to avoid conflicts 14:35:40 ... all the words that are in place in the spec have been approved in the past few years, but important is that everything is time-bound, we are not regressing, we want to keep the spec in a stable state always, we don't want it to be transient, need to make changes to do in at once and not incrementally 14:36:08 ... the spec is a shipping product that ships all the time in public 14:37:16 ... as I look of the PRs I see all these categories together, for example for datatypes in parameters I could not find a GH issue where the discussion is, not always a big time, but takes time to spot them 14:37:17 q? 14:38:04 Chai: GH issue as a context for a PR is important for this reason, it is unclear what should I expect from the PR, wording changes, are some changes debatable, do they alter the semantics of the description 14:38:34 ... these could be debated in the PR, but I'd prefer to have the discussion in GH issues 14:39:33 ... there are many pending PRs in queue, if we cannot time-bound them we put spec in a never-ending transient state 14:39:48 ... this is a time when we need to be clear on the deltas 14:41:41 ... this is not addressed by tools, it is a process issue 14:42:25 ack zkis 14:42:52 Zoltan: open PRs are evolutionary 14:43:27 ... I've restricted PRs to 1. Stylistic changes 14:43:51 q+ 14:44:38 ... does the spec need to be consistent after each commit? 14:44:47 q? 14:44:50 ack chai 14:46:16 Chai: I'd like us to write contribution guidelines for spec changes to help contributors. 14:46:48 ... we have followed practices that may not be obvious to people who start contribute to the spec midway, I can take an action to write contribution guidelines. 14:47:19 ... I want to propose, existing outstanding PRs should be backtracked and categorized as follows: 14:47:34 ... 1) Stylistic changes, atomic, the WG liked these 14:48:41 ... 2) If we feel wording changes are required, make an issue what to change 14:48:50 Present+ Daniel_LaLiberte 14:49:17 Chai: no IDL changes in this category, also atomic 14:50:02 ... 3) Algorithm additions, this is debatable, welcome debate, whether we want to make these atomic or allow these to be transient, the spec is evolving at any time, it is a living spec, but it should not be transient, not middle of big changes 14:50:16 ... other people making changes may validate that, every PR should be atomic 14:50:32 ... this is the PR category where templates or tools can help 14:51:06 ... e.g. param validation is a big part of this, this is an opportunity for automation to generate boilerplate 14:51:24 ... I propose we make 3 PRs and if there are fundamental issue 14:51:58 ... if there are new issues identified, as an example axis param that has multiple PRs back and forth, that is a legit issue as a separate issue 14:52:32 ... an open issue that explain it and have people look at the issue, most likely the editor, before making the PR, having the issue debated in issues, then make a PR 14:52:55 ... currently we see 3 PRs that could incorporate the changes now in PR queue 14:53:05 q? 14:53:44 anssik: would it be a problem if these 3 PRs are very big? 14:54:48 Chai: not if self-contained as stylistic or wording changes 14:55:53 ... I don't feel strongly on specific choice of words 14:56:10 ... I'm more concerned on content changes that are not wording changes i.e. normative changes 14:57:13 q+ 14:58:12 q? 14:58:14 ack ningxin_hu 14:58:44 ningxin_hu: I agree that style changes could be a big PR with everything in one go, the same for wording changes 14:59:03 ... for algorithm changes I prefer multiple PRs, not as one big PR, it would increase the complexity for the reviewers 15:00:02 q+ 15:00:02 ... my question is whether we can still go op per op for algorithms, but keep it atomic per op, not for the entire op set? 15:00:02 ... does that work for Chai? 15:00:38 ... our current PR for builder.constant would be one example, operand build method, we could start with that? 15:00:38 q? 15:00:38 ack chai 15:00:38 Chai: I agree with Ningxin, but here's my proposal 15:01:42 ... I think for algorithm sections it should be tool-generated, if we look at constant and clamp some inconsistencies how words are written 15:01:50 Zoltan: these PRs were done far from each other, so I still have to sync between them 15:01:51 Chai: thanks for your work Zoltan! I want to tease out these elements so we can better manage them 15:02:06 ... if we add algorithm sections only and not other changes, those can still be handled as incremental PRs 15:02:20 ... adding just algo sections, 90% is param validation with redundant words between them 15:02:27 ... this change is ideal to be tool generated 15:03:16 Zoltan: all this work has been done already, rest of the PRs are already consistent 15:03:47 Chai: we have many ops to add and new ops to add in v2 so if we invest in e.g. python script to generate boilerplate then new PRs can be generated with this script and we can make everything consistent 15:04:02 ... for future changes, we can change the script and re-generate all algorithms to keep consistency 15:04:10 RRSAgent, draft minutes 15:04:11 I have made the request to generate https://www.w3.org/2023/04/13-webmachinelearning-minutes.html anssik 15:04:22 q? 15:05:18 Zoltan: we should try to merge the open PRs because it'd multiply my work if not 15:05:40 https://github.com/webmachinelearning/meetings/blob/main/telcons/2023-04-13-wg-agenda.md 15:09:39 Zoltan: we don't need to decide on the open PRs now, we can do that on GH 15:13:25 Important to merge is https://github.com/webmachinelearning/webnn/pull/329 15:14:17 q+ 15:14:18 https://github.com/w3c/w3process/blob/main/CONTRIBUTING.md 15:14:28 ack ningxin_hu 15:14:29 I'll look at PR 329. That's the only pending PR I haven't looked at. 15:15:08 ningxin_hu: I think PR #329 is a good PR because it factors out common algorithms that can be used by other algorithms 15:15:09 https://github.com/webmachinelearning/webnn/issues/329 -> Pull Request 329 Rework the sync async algorithms based on #323 (zolkis) 15:15:54 ... Chai mentioned redundant steps can be autogenerated, this PR proposes another way defining a reusable algorithm that avoid duplication 15:16:16 ... "auto-generation vs. subroutines" 15:16:34 anssik: factoring out is a good practice 15:17:11 anssik: everyone know what are the next steps? 15:17:36 Zoltan: I'm clear now, waiting for reviews to come, will work on a big stylistic PR per feedback 15:18:14 BTW, if a PR is ready for review, please remove the WiP annotation, thanks! 15:19:57 anssik: using GH built-in draft PR status sounds good to me, thanks Dom for the proposal 15:20:14 RRSAgent, draft minutes 15:20:16 I have made the request to generate https://www.w3.org/2023/04/13-webmachinelearning-minutes.html anssik 15:37:11 scribe- dom 15:37:12 RRSAgent, draft minutes 15:37:13 I have made the request to generate https://www.w3.org/2023/04/13-webmachinelearning-minutes.html anssik 17:35:23 Zakim has left #webmachinelearning