06:43:36 <RRSAgent> RRSAgent has joined #spec-maintenance
06:43:40 <RRSAgent> logging to https://www.w3.org/2023/09/13-spec-maintenance-irc
06:43:44 <Ian> RRSAgent, do not leave
06:43:44 <Ian> RRSAgent, make logs public
06:43:46 <Ian> Meeting: Tracking spec maintenance
06:43:48 <Ian> Chair: Jeffrey Yasskin
06:43:50 <Ian> Agenda: https://github.com/jyasskin/spec-maintenance/blob/main/meetings/tpac-2023-agenda.md
06:43:52 <Ian> Slideset: https://jyasskin.github.io/spec-maintenance/meetings/tpac-2023-slides.html
06:43:54 <Ian> clear agenda
06:43:56 <Ian> agenda+ Pick a scribe
06:43:58 <Ian> agenda+ Reminders: code of conduct, health policies, recorded session policy
06:44:00 <Ian> agenda+ Goal of this session
06:44:02 <Ian> agenda+ Discussion
06:44:04 <Ian> agenda+ Next steps / where discussion continues
06:44:08 <Ian> Ian has left #spec-maintenance
07:01:13 <Ian> Ian has joined #spec-maintenance
07:01:20 <Ian> Ian has left #spec-maintenance
07:12:58 <Ian> Ian has joined #spec-maintenance
07:13:00 <Ian> Ian has left #spec-maintenance
10:17:36 <fantasai> fantasai has joined #spec-maintenance
10:19:38 <fantasai> Scribenick: fantasai
10:22:01 <jyasskin> jyasskin has joined #spec-maintenance
10:22:01 <astearns> astearns has joined #spec-maintenance
10:22:01 <hober> hober has joined #spec-maintenance
10:22:01 <hober> present+
10:22:44 <fantasai> jyasskin: Preface: I haven't done all the homework to get this right
10:22:44 <plh> plh has joined #spec-maintenance
10:22:44 <florian> florian has joined #spec-maintenance
10:22:44 <fantasai> jyasskin: Basic problem I'm hoping to adress
10:22:44 <fantasai> ... is we work on specs, and then editors move on to other things
10:22:44 <fantasai> ... but then issues come up, or osmeone starts implementing
10:22:44 <fantasai> ... and editor doesn't notice
10:22:51 <fantasai> ... even if we notice, don't always have allocation to respond
10:22:59 <fantasai> [slide 3]
10:23:22 <fantasai> jyasskin: [presents numbers]
10:23:22 <fantasai> ... e.g. mean time to update is 2 years
10:23:26 <fantasai> ... mean issue age is 3 years
10:23:32 <fantasai> ... what do we need in order to address this?
10:23:34 <fantasai> [slide 4]
10:24:50 <fantasai> [slide 5]
10:24:50 <fantasai> jyasskin: We need to triage, distinguish by priority
10:24:50 <fantasai> ... unblock implementers
10:24:50 <astearns> slides: https://jyasskin.github.io/spec-maintenance/meetings/tpac-2023-slides.html
10:24:50 <fantasai> [slide 6]
10:24:50 <fantasai> jyasskin: need to report problems
10:24:54 <fantasai> ... chrome team has internal tools
10:25:04 <fantasai> ... chrome bugs, pretty graphs of which teams are doing well or poorly about managing bugs
10:25:13 <fantasai> ... so I'd like to integrate specs with that system
10:25:18 <fantasai> ... I'm guessing other orgs have similar systems
10:25:28 <fantasai> ... also if we have a public description of "this spec is having trouble"
10:25:41 <fantasai> ... maybe someone will volunteer from community rather than just browser vendors
10:25:44 <fantasai> [slide 7]
10:25:48 <fantasai> jyasskin: People have built some tools
10:26:26 <fantasai> ... foolip built a tool called "spec Reactions"
10:26:26 <caribou> caribou has joined #spec-maintenance
10:26:26 <fantasai> ... shows how many ppl have reacted across browser specs, baed on recent or total
10:26:26 <fantasai> ... to help prioritize action
10:27:00 <fantasai> ... W3C also has a list of recommended labels
10:27:00 <fantasai> ... mostly about horizontal review, but also bug vs enhancement, help wanted, etc.
10:27:00 <fantasai> [slide 8]
10:27:06 <fantasai> jyasskin: What did I miss? I want this to work for whole community, not just my company
10:27:16 <jyasskin> https://docs.google.com/document/d/1sVuuxIawZdPaT5Fbc_9nM6k7rC0nnf0N_khdM7tyqNs/edit#heading=h.3t624fypqsd3
10:27:23 <plh> q+
10:27:31 <fantasai> jyasskin: Open floor for discussion
10:27:38 <fantasai> plh: Thanks for organizing this session
10:27:44 <fantasai> ... spec maintenance has been discussed for many years
10:27:52 <fantasai> ... tried to solve, but mostly failed, so glad you're picking up
10:28:33 <fantasai> ... big +1, we have many repos, so if we want to help triage the first thing is
10:28:33 <fantasai> ... we need to tell repos what to do to help triage
10:28:33 <fantasai> ... you mentioned list of labels on github.io, glad you're aware of it
10:28:33 <fantasai> ... big +1 to sending PR to update
10:28:33 <fantasai> ... but there also needs outreach effort
10:28:41 <fantasai> plh: What I do find is that training is a constant effort
10:28:53 <fantasai> ... haven't talked about horizontal review in awhile, and new people don't know what they mean and misuse them
10:29:13 <fantasai> plh: For the problem itself, if an editor is not responsive, talk to Team
10:29:20 <fantasai> ... then, idk who is Team
10:29:38 <jyasskin> q+ about teams
10:29:38 <fantasai> ... consider SVG. Who is Team? Not only is editor unresponsive, we don't have an editor, don't have a WG
10:29:49 <fantasai> ... Maybe "good first spec to maintain"? But SVG isnot a good example for that
10:29:49 <jyasskin> q+ jyasskin to answer about teams
10:29:52 <jyasskin> q- about
10:29:54 <jyasskin> q- teams
10:29:57 <jyasskin> ack plh
10:29:58 <fantasai> ... but how can we attract editors to maintain abandoned specs?
10:30:12 <jyasskin> ack jyasskin
10:30:12 <Zakim> jyasskin, you wanted to answer about teams
10:30:30 <fantasai> jyasskin: Wrt Team, Chrome as a team that's tasked with maintaining implementation of any particular feaure
10:30:32 <xueyuan> xueyuan has joined #spec-maintenance
10:30:34 <fantasai> ... not sure who that is for SVG
10:30:42 <npm> npm has joined #spec-maintenance
10:30:42 <fantasai> ... we think that the Team should be maintaining spec also
10:31:24 <fantasai> ... I was thinking is that, we could link from repo to Google team responsible for that feautre
10:31:24 <fantasai> ... maybe put in W3C metadata
10:31:24 <fantasai> hober: Chrome metadata in W3C metadata?
10:31:29 <fantasai> jyasskin: Each company to put implementer metadata
10:31:39 <fantasai> ... e.g. for Chrome, here's the ID for the responsible team. For Safari, same thing
10:31:50 <fantasai> plh: W3C data doesn't work for WHATWG
10:31:58 <fantasai> jyasskin: We should have one schema for this
10:32:05 <fantasai> plh: maye not call it w3c.json in the first place
10:32:11 <fantasai> s/maye/maybe/
10:32:16 <fantasai> ... but I welcome more data into those files
10:33:00 <fantasai> ??: when you have a spec, whose responsibility is it ultimately to triage the GH issues?
10:33:00 <plh> q?
10:33:00 <astearns> s/??/nicolas/
10:33:00 <fantasai> ... is it all the participants in teh group, or the editor?
10:34:03 <fantasai> hober: depends on the group. E.g. in ??? editors are expected to triage their issues, but other groups it's different
10:34:03 <hober> s/???/the WHATWG/
10:34:03 <fantasai> nicolas: If no-one thinks they're responsible, then won't get done
10:34:03 <jyasskin> q?
10:34:03 <plh> --> https://w3c.github.io/w3c.json.html W3C.json documentation
10:34:03 <fantasai> jyasskin: I think saying editor is good default. If editor is not responsive, then can go to implementer teams and ask for new editor
10:34:03 <florian> q+
10:34:09 <fantasai> hober: Chairs have responsibility of appointing editors at W3C
10:34:16 <fantasai> ... implies chairs should notice if editors are unresponsive
10:34:18 <plh> --> https://w3c.github.io/validate-repos/report.html Report on W3C Working Group repositories
10:34:24 <fantasai> ... I think presumption of current process is chairs wil notice
10:34:27 <fantasai> ... in practice they don't
10:34:45 <fantasai> ... in particular, for CGs etc., there isn't necessarily that expectation at all
10:34:48 <fantasai> ... I trust Alan in CSS, to notice if a spec is abandond
10:34:53 <fantasai> astearns: I was nodding when you said this actually
10:34:58 <fantasai> jyasskin: chairs need help finding editors
10:34:59 <fantasai> astearns: yes we do!
10:35:12 <fantasai> hober: plh, you asked earlier, how can we attract editors for abandoned specs
10:35:22 <fantasai> ... and as we just learned, everyone agrees it's hard
10:35:24 <fantasai> astearns: I like idea of implementing team registries
10:35:43 <fantasai> ... because that's a narrower group of people I can go to and say "something needs to be done, let's figure out who's the victim"
10:35:48 <fantasai> ... much harder than going through WG
10:35:52 <hober> q+
10:35:57 <plh> ack florian
10:36:04 <fantasai> florian: I'm wondering how this might tie into fact that at certain publication points
10:36:10 <fantasai> ... people are expected to produce a disposition of comments
10:36:17 <fantasai> ... to say which comments received, which addressed
10:36:21 <fantasai> ... that is infrequent, so not sufficient
10:36:29 <jyasskin> q+ jyasskin to talk about spec lifecycles
10:36:38 <fantasai> ... but sometimes this will require editor to notice where they didn't do the job
10:36:51 <fantasai> ... but many years in between DoCs, so not idea
10:37:00 <fantasai> ... idk if we have a strong expectation, practice varies by WG and editor
10:37:06 <fantasai> ... but maybe we can try to tie two together
10:37:50 <plh> ack hober
10:37:50 <fantasai> ... the more we track what's happening, easier to report when you have gone through the issues
10:37:50 <fantasai> hober: wrt finding editors, there are some things we can do
10:37:50 <fantasai> ... I really like direction you're going, jyasskin
10:37:52 <fantasai> ... but no matter what we do, it is going to always be challenging to find editors
10:37:56 <florian> s/so not idea/so not sufficient/
10:38:03 <fantasai> ... general economic incentives of the world are that engineers don't have much time
10:38:22 <fantasai> ... if have to choose between fix bugs (and get metrics improved) or to fix some spec (and not have bosses notice and give raise)
10:38:40 <fantasai> ... I don't know if, as an industry, we have a good story for rewarding this work, recognizing and elevating it
10:38:48 <fantasai> ... I would love ideas how to change that, but outside of that
10:38:54 <fantasai> ... I don't know what to do to attract people to it
10:38:57 <plh> ack jyasskin
10:38:57 <Zakim> jyasskin, you wanted to talk about spec lifecycles
10:39:15 <fantasai> jyasskin: On florian's comment, transitions on REC track happens much later than this problem
10:39:18 <fantasai> ... a lot of this happens in CGs
10:39:26 <fantasai> ... a lot of that is Chrome's fault
10:39:34 <florian> q+
10:39:34 <fantasai> ... but within WG, it's too late for this problem
10:39:51 <fantasai> ... but reporting bit, scanning and saying which issues are out of SLO
10:39:56 <fantasai> ... my attempt to fix economics
10:40:04 <fantasai> ... to show managers if people doing a good job
10:40:17 <fantasai> ... if we can show the metrics, our management systems can reward people for making the number go down
10:40:26 <fantasai> ... we need management to buy into idea that these bugs are as valuable as implementation bugs
10:40:34 <fantasai> ... but if they could see it, then they could reward ppl for improving it
10:40:35 <plh> ack florian
10:40:46 <florian> AB issue on appreciating standards work: https://github.com/w3c/AB-memberonly/issues/53
10:40:49 <fantasai> florian: I want to mention that AB has longstanding issue, without an answer, about appreciating/recognizing/elevating standards work
10:40:58 <fantasai> ... if we can find good ways to make that happen, that's a known gap
10:41:16 <fantasai> plh: I'm very supportive of this work, expanding our tooling
10:41:22 <fantasai> ... doesn't just have to be in W3C
10:41:28 <fantasai> ... e.g. our horizontal tooling works with WHATWG as well
10:41:38 <fantasai> ... our horizontal groups work with WHATWG specs as well
10:41:46 <fantasai> ... so supportive of adding info
10:41:54 <fantasai> ... E.g. in specs, you find link between the spec and WPT!
10:41:57 <caribou> q+
10:42:03 <fantasai> ... maybe the link should not point to team, but within the spec
10:42:13 <fantasai> ... my principle is put the info close as possible to the people who can move it
10:42:25 <fantasai> ... one of problems with W3C is only Team can edit website
10:42:34 <fantasai> ... so that's why w3c.json were created in GH, so that ppl in GH can edit those files
10:43:19 <plh> ack caribou
10:43:31 <fantasai> caribou: wondering about tooling etc.
10:43:40 <fantasai> ... if nobody actively maintaining something because editor went away
10:43:45 <fantasai> ... adding more tooling is not going to solve the problem
10:43:52 <fantasai> ... ok to add tooling to help continue work
10:44:02 <fantasai> ... but problem to tackle here is to find a way to avoid editors dropping work
10:44:14 <fantasai> ... if they are already absent tooling won't solve
10:44:38 <fantasai> ... maybe we need some kind of rescue task force to help those cases
10:44:41 <plh> q+ to mention service workers
10:44:59 <fantasai> ... OK as well to drop some specs, if they are not progressing
10:45:20 <fantasai> ... currently we have no way to signal specs that are no longer very active
10:45:36 <fantasai> ... in some cases not limited to one WG, specs can have interest in several WGs, so maybe find ppl from outside join WG and fix it
10:45:40 <fantasai> ... or taking over
10:46:04 <fantasai> [audio cut]
10:46:35 <plh> ack plh
10:46:35 <Zakim> plh, you wanted to mention service workers
10:46:45 <fantasai> plh: One thing I wanted to mention, another spec which may become unfortunate case
10:46:51 <fantasai> ... is service worker core spec, nobody is maintaining it
10:46:56 <fantasai> ... or pushing it to a more stable state
10:47:08 <fantasai> ... actually a breakout on that, we don't even have a WG chair
10:47:18 <jyasskin> q+ to talk about finding new editors
10:47:21 <fantasai> ... but there is interst in new stuff! But nobody interested in core spec
10:47:32 <fantasai> jyasskin: On finding new editors, Google has an internal policy
10:47:34 <caribou> I was suggesting something like a "spec rescue" guideline or procedure to decide how to fix a stalled spec (find new people, stop work, or punt to other group)
10:47:39 <fantasai> ... that implementation teams are responsible for their specs also
10:47:54 <fantasai> ... for service workers, we'll have to discuss with director if he's planning to follow that policy
10:48:07 <fantasai> ... but W3C, and ppl looking for maintainer, that's a route they can take that hasn't been visible before
10:48:12 <fantasai> ... Tess, would that work for Safari?
10:48:24 <fantasai> ... if there was a Safari editor that left Safari and not active
10:48:25 <astearns> agrees with caribou that "spec rescue" guidelines for chairs (and the team) would be good to have written down
10:48:32 <fantasai> ... is it appropriate to come to you or some team to ask for an editor?
10:48:35 <fantasai> hober: yes
10:48:39 <fantasai> jyasskin: that's the next thing to try then
10:48:46 <fantasai> ... we've been assuming editors to volunteer from the community
10:48:48 <npm> q+
10:48:54 <fantasai> ... but we can ask the rich corporations to provide an editor
10:48:58 <plh> ack jyasskin
10:48:58 <Zakim> jyasskin, you wanted to talk about finding new editors
10:49:20 <plh> ack npm --init
10:49:20 <jyasskin> q-
10:49:31 <fantasai> ???: Is it fair to say if there's an implementer, if Google or Apple is an implementer, it's OK to ask for an editor/maintainer of the spec?
10:49:34 <plh> ack npm
10:49:41 <jyasskin> s/???/npm/
10:49:43 <fantasai> ... that seems reasonable if you're implementing something, you should do some basic maintenance
10:49:51 <fantasai> ... but don't know if that's often the case
10:49:52 <florian> q+
10:49:59 <fantasai> myles: usually not the case
10:50:06 <fantasai> npm: Something to look at, implementers why don't you edit
10:50:29 <fantasai> ... giving specific people ... once they have formal responsibility, easier for that person to say "manager, I am formally responsible for that, give me credit for it"
10:50:36 <fantasai> ... at least at Google we give credit for spec work
10:50:42 <fantasai> ... though more for getting things to ship
10:50:46 <fantasai> ... maintenance is much less rewarded
10:50:50 <fantasai> ... we need to improve on that
10:50:59 <fantasai> ... that can be a route towards having better incentives
10:51:12 <plh> ack florian
10:51:44 <fantasai> florian: if noticing and assigning editors is solution, it works where there's interest and resource
10:51:53 <fantasai> ... but also we have interest but no resource
10:52:02 <fantasai> ... in some WGs we have invited experts who have ability to do work
10:52:06 <fantasai> ... they just might not have time
10:52:11 <fantasai> ... so maybe we can make a match
10:52:25 <fantasai> ... While pinging to a well-resourced corp to provide editor
10:52:32 <fantasai> ... might not need to be your own personnel
10:52:36 <fantasai> jyasskin: contractors exist
10:52:43 <fantasai> jyasskin: OK, talked about finding new editors
10:52:51 <fantasai> ... I sketched the sorts of labels i think we need in the Google doc
10:52:55 <jyasskin> q+ to https://docs.google.com/document/d/1sVuuxIawZdPaT5Fbc_9nM6k7rC0nnf0N_khdM7tyqNs/edit#heading=h.k9bqpmce10qt
10:53:21 <fantasai> ... how do pppl feel about these labels?
10:53:25 <astearns> q+
10:53:39 <plh> ack jyasskin
10:53:39 <Zakim> jyasskin, you wanted to https://docs.google.com/document/d/1sVuuxIawZdPaT5Fbc_9nM6k7rC0nnf0N_khdM7tyqNs/edit#heading=h.k9bqpmce10qt
10:53:40 <jyasskin> q-
10:53:48 <fantasai> scribe+ jyasskin
10:53:50 <plh> ack fantasai
10:54:03 <jyasskin> fantasai: blocks-implementation is useful, but I haven't seen it before.
10:54:25 <jyasskin> ... CSSWG has several types of needs-feedback depending on what's needed. commenter-response. needs-data. needs-proposed-text
10:54:34 <jyasskin> ... Don't know how many we need to make standardized.
10:54:36 <hober> q+
10:54:38 <florian> q+
10:54:40 <marek> marek has joined #spec-maintenance
10:54:44 <plh> ack astearns
10:55:35 <fantasai> astearns: implementer priority would be helpful, but issues being implementer or not don't want to prioritize like that. All issues are valid
10:56:20 <jyasskin> fantasai: most issues in the CSSWG aren't immediately blocking an implementer. Lots are clear problems that will prevent people form getting it right. If someone's actively implementing and runs into something that needs fixing, it makes sense to prioritize those.
10:56:30 <fantasai> s/If/But if/
10:56:36 <fantasai> astearns: [didn't hear]
10:56:53 <plh> ack hober
10:56:55 <fantasai> ... would be helpful to get implementer feedback on what they prioritize
10:57:05 <fantasai> ... but want other than implementers to be able to communicate priorities, too
10:57:13 <fantasai> hober: One of the most interesting sets of labels are blocking labels
10:57:20 <fantasai> ... so I can tell, this issue is stuck until something happens
10:57:39 <plh> present+
10:57:44 <fantasai> ... I woudl like to suggest that should be clear from the label
10:58:03 <fantasai> ... who are we blocked on? what are we blocked on?
10:58:15 <fantasai> CSSWG labels -> https://github.com/w3c/csswg-drafts/labels
10:58:17 <RRSAgent> I'm logging.  Sorry, nothing found for 'who is present'
10:58:29 <fantasai> ... blocking CR or blocking implementations from advancing or...
10:58:34 <plh> ack florian
10:58:49 <fantasai> florian: Issues from anybody can be important
10:58:55 <fantasai> ... but implementer issues have more time-sensitivity
10:59:05 <fantasai> ... e.g. if we miss window of opportunity, they will ship something else, and it will be harder to do something about it
10:59:22 <fantasai> ... also if team is focused on this area, it's an opportunity for rapid progress if we schedule it right
10:59:35 <fantasai> ... not at the expense of recognizing that anyone's issue can be imprtant
10:59:40 <astearns> implementer actions create time-sensitivity, but that can make non-implementer issues more important too
10:59:48 <fantasai> jyasskin: My thought was that the priorities would not care about if implementations
10:59:51 <plh> ack fantasai
10:59:54 <fantasai> ... but impelmenters can boost SLO by marking
11:00:12 <jyasskin> fantasai: General prioritization I'd leave to implementation teams. If they need issues addressed, talk to the chairs.
11:00:26 <jyasskin> ... chairs in CSSWG are very responsive. Just need to say what the implementers are.
11:00:27 <jyasskin> q+
11:00:44 <plh> q+
11:00:45 <jyasskin> ... Might have different opinions on the generic pile of issues. Different WGs might want to develop their own priorities.
11:01:01 <jyasskin> fantasai: Can't necessarily standardize, except for "this is blocking an implementer"
11:01:04 <plh> ack jyasskin
11:01:06 <florian> q+
11:01:20 <fantasai> jyasskin: CSSWG is unusually functional at W3C, doesn't mean other groups don't need
11:01:31 <fantasai> ... maybe the CSSWG wouldn't adopt some pieces of system, or wouldn't feed into tooling
11:01:42 <fantasai> ... but because CSSWG gets things done, they don't need this as much
11:01:50 <plh> ack plh
11:01:51 <fantasai> ... we could still propose this for CGs and less functional WGs
11:02:00 <fantasai> plh: My experience with new things and propagation across groups
11:02:14 <fantasai> ... we need to have this successful in one group first
11:02:23 <fantasai> ... e.g. horizontal tooling was based on experience of i18nWG
11:02:24 <jyasskin> q+
11:02:37 <jyasskin> q+ to offer pilot groups
11:02:40 <fantasai> ... I took their tools and applied it to the all the HRGs ... TAG is still a bit fuzzy
11:02:46 <fantasai> ... groups each have their own culture
11:02:58 <fantasai> ... if something works well in CSSWG, and want other groups to adopt
11:03:12 <fantasai> ... if not adopting, maybe didn't know it was possible
11:03:17 <plh> ack florian
11:03:26 <fantasai> florian: We've been speaking about triage in terms of priorities
11:03:35 <fantasai> ... but e.g. in CSSWG, we have a lot of specs
11:03:41 <fantasai> ... part of triage is assigning issue to spec
11:03:49 <fantasai> ... that probably doesn't occur in WG with 2-3 specs
11:04:00 <fantasai> hober: CSS uses a mono-repo which causes this problem
11:04:05 <fantasai> plh: very few groups do this
11:04:12 <fantasai> ... model is usually one spec per repo
11:04:32 <plh> ack jyasskin
11:04:32 <Zakim> jyasskin, you wanted to offer pilot groups
11:04:33 <fantasai> florian: there are upsides and downsides, that's one downside
11:04:40 <fantasai> jyasskin: You mentioned groups to try out
11:04:51 <fantasai> ... initial plan for doing this was that I would figure something out and try it in a Google CG
11:05:09 <fantasai> ... realized I shoudl bring to community so that we can adopt as community, but we can pilot on a Google editing group
11:05:18 <fantasai> plh: grassroots efforts work etter
11:05:22 <fantasai> s/etter/better/
11:05:33 <fantasai> ... e.g. wpt
11:05:35 <plh> q?
11:06:02 <astearns> q+
11:06:08 <fantasai> plh: Another group to reach out to is spec-prod
11:06:19 <fantasai> -> https://lists.w3.org/Archives/Public/spec-prod/
11:06:25 <fantasai> fantasai: or chairs@
11:06:28 <plh> ack astearns
11:06:33 <fantasai> -> https://lists.w3.org/Archives/Member/chairs/
11:06:48 <fantasai> jyasskin: WICG, PATC, etc.
11:06:59 <fantasai> astearns: agree working out in a group
11:07:34 <fantasai> ... I suspect WICG needs more than others
11:07:34 <plh> q?
11:07:34 <fantasai> ... I'd like to be informed on progress
11:07:43 <fantasai> ... e.g. I didn't know spec-reactions tool existed
11:07:48 <fantasai> jyasskin: hasn't been publicized yet
11:08:20 <fantasai> jyasskin: I think we're done! Thanks everyone for contributing
11:08:30 <fantasai> ... I'll announce and discuss on spec-prod
11:26:05 <caribou> RRSAgent, draft minutes
11:26:07 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/13-spec-maintenance-minutes.html caribou
11:27:09 <caribou> caribou has left #spec-maintenance