06:39:49 <RRSAgent> RRSAgent has joined #pub
06:39:53 <RRSAgent> logging to https://www.w3.org/2025/11/10-pub-irc
06:39:53 <tidoust> RRSAgent, do not leave
06:39:53 <tidoust> RRSAgent, this meeting spans midnight
06:39:53 <tidoust> RRSAgent, make logs public
06:39:54 <tidoust> Meeting: Publication tooling
06:39:54 <tidoust> Chair: Denis Ah-Kang
06:39:54 <tidoust> Agenda: https://github.com/w3c/tpac2025-breakouts/issues/85
06:39:54 <Zakim> Zakim has joined #pub
06:39:54 <tidoust> Zakim, clear agenda
06:39:54 <tidoust> Zakim, agenda+ Pick a scribe
06:39:54 <tidoust> Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy
06:39:54 <Zakim> agenda cleared
06:39:54 <tidoust> Zakim, agenda+ Goal of this session
06:39:54 <tidoust> Zakim, agenda+ Discussion
06:39:54 <tidoust> Zakim, agenda+ Next steps / where discussion continues
06:39:54 <Zakim> agendum 1 added
06:39:54 <Zakim> agendum 2 added
06:39:54 <Zakim> agendum 3 added
06:39:55 <Zakim> agendum 4 added
06:39:55 <Zakim> agendum 5 added
06:39:55 <tidoust> Zakim, agenda+ Adjourn / Use IRC command: Zakim, end meeting
06:39:56 <Zakim> agendum 6 added
07:55:46 <dom> dom has joined #pub
07:56:32 <kenneth> kenneth has joined #pub
08:00:31 <denis> -> https://www.w3.org/Talks/2025/dak-publication-tools/ slides
08:01:57 <denis> zakim, take up agendum 1
08:01:57 <Zakim> agendum 1 -- Pick a scribe -- taken up [from tidoust]
08:02:00 <dom> scirbe+
08:02:04 <dom> scribe+
08:02:24 <dom> Slideset: https://www.w3.org/Talks/2025/dak-publication-tools/
08:03:00 <dom> Present+ Denis, Vivien, FLorian, Carine, Tab, Marcos, Karl, Jean-Gui, Francois
08:03:08 <kenneth> present+
08:03:14 <snek> snek has joined #pub
08:03:18 <TabAtkins> TabAtkins has joined #pub
08:03:32 <denis> zakim take up agendum 2
08:03:44 <dom> Present+ MichaelFicara, Mikhail
08:03:50 <m-alkalbani> m-alkalbani has joined #pub
08:03:59 <snek> snek has joined #pub
08:04:09 <nicolo-ribaudo> nicolo-ribaudo has joined #pub
08:04:50 <dom> [slide 2]
08:05:08 <michaelficarra> michaelficarra has joined #pub
08:05:20 <dom> Denis: the spec-generator is an online tool to generate static HTML document out of respec/(and now)bikeshed authored documents
08:05:26 <dom> [slide 3]
08:06:33 <dom> Denis: there has been discussions about migrating csswg.org and transfering some services away from it
08:06:43 <dom> ... adding bikeshed support to the spec-generator rose in priority as a result
08:07:19 <dom> [demo of spec-generator applied to a ReSpec document]
08:08:39 <dom> [demo of a beta version of the spec-generator applied to a bikeshed document]
08:09:16 <dom> [slide 4]
08:09:24 <florian> florian has joined #pub
08:09:38 <florian> q+
08:10:28 <denis> -> https://labs.w3.org/bikeshed-spec-generator/ bikeshed on spec-generator
08:10:54 <dom> [slide 5]
08:12:47 <denis> ack florian
08:13:26 <dom> Florian: looks great; one of the things the legacy service doesn't support: a bikeshed document is typically a single file, but sometimes comes with includes
08:13:43 <dom> ... when loading a URL, try to resolve relative files
08:13:51 <sidvishnoi> sidvishnoi has joined #pub
08:14:03 <dom> tab: bikeshed does it directly
08:14:20 <dom> Ken: and that's how we call bikeshed
08:14:54 <dom> Florian: worth documenting that a tar file is a solution to multi-file siutations
08:15:01 <dom> Ken: tar is documented in the UI
08:15:18 <dom> Denis: is this on track to replace the service? is anything missing?
08:15:33 <dom> Tab: looks absolutely on track
08:15:54 <dom> FLorian: how often do you update bikeshed on the system?
08:16:08 <dom> Tab: from a bikeshed, please use pip to get the latest release (not github)
08:16:23 <dom> ... Peter's tool auto-update on release IIRC
08:16:24 <kenneth> q+
08:16:31 <kenneth> q-
08:16:36 <dom> Florian: what about metadata updates?
08:16:41 <TabAtkins> `bikeshed update`
08:16:47 <kenneth> q+
08:17:08 <dom> Denis: how often should we "bikeshed update"
08:17:25 <dom> TabAtkins: that can usefully be done on a regular basis
08:17:34 <dom> Florian: a few times a day is probably fine
08:18:00 <michaelficarra> michaelficarra has joined #pub
08:18:09 <dom> Denis: we'll try to deploy this new version of spec generator by the end of the year
08:18:18 <kenneth> ack me
08:19:07 <dom> Tab: I think Peter uses an hourly cron bikeshed update
08:19:25 <dom> Dom: do we know which are the current customers of the csswg.org version?
08:19:34 <dom> Tab: CSS specs are built on CI directly with bikeshed
08:19:45 <dom> Ken: in terms of customers, there is at least pr-preview
08:20:02 <sidvishnoi> q+
08:20:08 <simone> simone has left #pub
08:20:12 <dom> denis: we'll follow up once we have a stable version ready
08:20:14 <denis> q?
08:20:16 <dom> ack sidvishnoi
08:20:17 <denis> ack sidvishnoi
08:20:45 <dom> sidvishnoi: will these be two pages or a single page for respec/bikeshed?
08:20:55 <tidoust> q+
08:20:59 <dom> ken: they'll be kept as two pages on the same service space
08:21:20 <florian> q+
08:21:35 <dom> sidvishnoi: might be useful to align the UI even without merging them
08:21:36 <denis> ack tidoust
08:21:51 <dom> tidoust: in terms of integration - pubrules checker?
08:22:08 <denis> ack florian
08:22:10 <dom> denis: once we have a single tool, that will make it much easier to get that done
08:23:09 <dom> florian: how long lived is the URL that the document produces?
08:23:34 <dom> Dom: it's a paramterized URL with the target URL in the query string
08:23:51 <dom> ken: but note that running that URL is costly since it's doing processing
08:24:07 <michaelficarra> michaelficarra has joined #pub
08:24:15 <dom> RRSAgent, draft minutes
08:24:16 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/10-pub-minutes.html dom
08:24:31 <dom> [slide 6]
08:27:48 <dom> carine: metadata - is this about latest version of TR? editors draft?
08:29:33 <TabAtkins> Here's an example of the "CG metadata" https://github.com/speced/bikeshed/pull/3119
08:30:42 <tidoust> scribe+
08:31:01 <tidoust> dom: [provides context in the CG lifecycle]. My hope is that this pattern is not specific in the CG report and that it may be useful for other cases.
08:31:13 <tidoust> ... With that said, the question is a good one.
08:31:16 <florian> q?
08:31:25 <tidoust> ... Do you want to keep a static version of the metadata?
08:32:07 <tidoust> florian: There are contexts where you want to know who the editors were, and contexts where you want to know who the editors now are.
08:32:42 <tidoust> dom: So we should look at the lifecycle of the data and the lifecycle of the spec.
08:32:44 <dom> Marcos: from the respec side, we can read local files
08:33:02 <dom> ... ideally, having the data included in the document is preferable although we can fetch from a location
08:33:27 <dom> ... both for performance and for easing maintenance
08:33:37 <dom> s/can read/can't read
08:33:42 <TabAtkins> q+
08:33:43 <tidoust> q+
08:35:29 <dom> carine: the spec generator could scrape metadata from the doc
08:35:50 <dom> TabAtkins: the CG monitor is a very specialized type of data
08:36:00 <dom> ... but we might be talking a wider set of information
08:36:59 <denis> ack TabAtkins
08:38:20 <dom> dom: goal is to contextualize what readers should know to understand the status of a CG report
08:38:27 <dom> Tab: open to anything
08:38:58 <dom> Marcos: likewise, although we may want to do our own postprocessing on the data
08:39:14 <dom> Tab: probably a repo of data that generators can fetch data from the URL published space
08:39:23 <denis> ack tidoust
08:40:11 <kenneth> +1 what's the authoring story of this
08:40:16 <denis> scribe+
08:40:41 <florian> florian has left #pub
08:40:45 <denis> dom: in general, we expect the metadata to be updated automatically. We may need input from editors
08:40:57 <denis> ... the repo would reflect what we would have learned from the editors
08:41:11 <denis> ... if we do things right, the problem you are surfacing should be a big one
08:41:16 <kenneth> q+
08:41:19 <dom> tidoust: is the expectation that editors would have to use a different metadata system? in particular, for bikeshed which isn't using JSON as a format
08:43:17 <dom> Tab: part of what we want to optimize is making sure to keep the life of editors, esp in the case of CG report editors
08:43:17 <denis> ack kenneth
08:43:21 <dom> Marcos: +1
08:44:05 <TabAtkins> https://github.com/speced/bikeshed/pull/3119
08:44:55 <denis> q?
08:46:49 <kenneth> q+
08:46:54 <denis> ack kenneth
08:47:49 <dom> ken: are there reasons to use a single big repo? how has the experience of bikeshed-boilerplate?
08:48:29 <dom> tab: a lesson is being careful in versioning, but nothing that I expect to be particularly troublesome
08:48:43 <kenneth> s/are there reasons to use a single big repo?/I understand there are reasons to use a single big repo;/
08:48:46 <dom> avneesh: we're already doing this for other data, e.G. MDN
08:49:33 <dom> Marcos: I would love it if we could take the W3C id of people to get their data
08:51:24 <kenneth> +1 affiliation updates in specs are a complex subject lol
08:51:42 <dom> Tab: in CSS, we retain older affiliations, so automating some of this would be problematic
08:52:22 <dom> Dom: we could revisit our privacy approach
08:52:56 <dom> Denis: the systeam will discuss it
08:54:57 <dom> dom: is the W3C id the right entry point?
08:55:06 <dom> Tab: would prefer a username (github or w3c)
08:55:11 <dom> dom: could be email address
08:58:35 <dom> Tab: W3C could generate files for editors metadata
08:58:52 <tidoust> [Check the W3C API doc and /users/connected/{service}/{identifier} endpoint in particular: https://api.w3.org/doc ]
08:59:52 <dom> Ken: you could also iterate over the participation ends point of the W3C API to find the right person
09:01:20 <dom> Marcos: note that there had been pushback (e.g. from Manu?) on exposing editors data
09:02:01 <dom> Vivien: reminds me of tr-editors.rdf
09:02:42 <tidoust> RRSAgent, draft minutes
09:02:43 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/10-pub-minutes.html tidoust
13:41:38 <tidoust> RRSAgent, bye
13:41:38 <RRSAgent> I see no action items