Meeting minutes
Repository: webmachinelearning/webnn
Charter 2023-2025 W3C Advisory Committee review completed
anssik: Thank you for your support and comments!
… We were able to fast-track the operationalization of the new charter and can now initiate discussions on WebNN v2 features.
anssik: CfP requires no action for existing participants.
We received some review comments, the publicly shared are documented in issues and PRs:
anssik: any questions re the new charter?
[none]
WebNN - styling and structural changes, automation
Review proposed spec styling and structural changes
anssik: Zoltan has been working on the styling and structural changes based on the feedback from our last call.
… he can share with us the latest style revamp.
Zoltan: on our last call we agreed we want to see all the stylistic changes in the spec first w/o algos
… we wanted to add extand/collapse all UI
[ Zoltan sharing his latest render ]
Zoltan: the spec appears with collapsible algorithms and examples, they can be expanded one by one also
Discuss opportunities for automation
Zoltan: we checked some bikeshed features for templating
anssik: want to note bikeshed tool supports file-based includes and simple templating with text replacement via macros
https://
https://
Zoltan: I don't see a proper solution to automate this fully with the existing spec and build tools
… this is an interesting side project, all the web specs could benefit from further automation integrated into tooling
… if someone has tools for autogeneration then generated code could be used as input to write the spec steps
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
Zoltan: adding new ops is manageable by me, so I think other folks will be able to do the same
… copy-paste and modify for the context is doable
Chai: I've looked at a number of PRs, I appreciate the effort put into this
… 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
… 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
… 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
Chai: different change categories:
… 1) Stylistic, changes to stylesheets, easy to review, improve readability, easy to get it done, no normative changes
… 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
… 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
… 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
… 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
… 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
Chai: these are the 4 categories of changes, the common characteristic is that they are all time-bound, not random
… 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
… 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
… the spec is a shipping product that ships all the time in public
… 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
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
… these could be debated in the PR, but I'd prefer to have the discussion in GH issues
… there are many pending PRs in queue, if we cannot time-bound them we put spec in a never-ending transient state
… this is a time when we need to be clear on the deltas
… this is not addressed by tools, it is a process issue
Zoltan: open PRs are evolutionary
… I've restricted PRs to 1. Stylistic changes
… does the spec need to be consistent after each commit?
Chai: I'd like us to write contribution guidelines for spec changes to help contributors.
… 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.
… I want to propose, existing outstanding PRs should be backtracked and categorized as follows:
… 1) Stylistic changes, atomic, the WG liked these
… 2) If we feel wording changes are required, make an issue what to change
Chai: no IDL changes in this category, also atomic
… 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
… other people making changes may validate that, every PR should be atomic
… this is the PR category where templates or tools can help
… e.g. param validation is a big part of this, this is an opportunity for automation to generate boilerplate
… I propose we make 3 PRs and if there are fundamental issue
… 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
… 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
… currently we see 3 PRs that could incorporate the changes now in PR queue
anssik: would it be a problem if these 3 PRs are very big?
Chai: not if self-contained as stylistic or wording changes
… I don't feel strongly on specific choice of words
… I'm more concerned on content changes that are not wording changes i.e. normative changes
ningxin_hu: I agree that style changes could be a big PR with everything in one go, the same for wording changes
… for algorithm changes I prefer multiple PRs, not as one big PR, it would increase the complexity for the reviewers
… 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?
… does that work for Chai?
… our current PR for builder.constant would be one example, operand build method, we could start with that?
Chai: I agree with Ningxin, but here's my proposal
… I think for algorithm sections it should be tool-generated, if we look at constant and clamp some inconsistencies how words are written
Zoltan: these PRs were done far from each other, so I still have to sync between them
Chai: thanks for your work Zoltan! I want to tease out these elements so we can better manage them
… if we add algorithm sections only and not other changes, those can still be handled as incremental PRs
… adding just algo sections, 90% is param validation with redundant words between them
… this change is ideal to be tool generated
Zoltan: all this work has been done already, rest of the PRs are already consistent
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
… for future changes, we can change the script and re-generate all algorithms to keep consistency
Zoltan: we should try to merge the open PRs because it'd multiply my work if not
https://
Zoltan: we don't need to decide on the open PRs now, we can do that on GH
Important to merge is webmachinelearning/
https://
<chai> I'll look at PR 329. That's the only pending PR I haven't looked at.
ningxin_hu: I think PR #329 is a good PR because it factors out common algorithms that can be used by other algorithms
<ghurlbot> Pull Request 329 Rework the sync async algorithms based on #323 (zolkis)
ningxin_hu: Chai mentioned redundant steps can be autogenerated, this PR proposes another way defining a reusable algorithm that avoid duplication
… "auto-generation vs. subroutines"
anssik: factoring out is a good practice
anssik: everyone know what are the next steps?
Zoltan: I'm clear now, waiting for reviews to come, will work on a big stylistic PR per feedback
<ningxin_hu> BTW, if a PR is ready for review, please remove the WiP annotation, thanks!
anssik: using GH built-in draft PR status sounds good to me, thanks Dom for the proposal