Meeting minutes
<denis> slides
Pick a scribe
scirbe+
Slideset: https://
<denis> zakim take up agendum 2
Denis: the spec-generator is an online tool to generate static HTML document out of respec/(and now)bikeshed authored documents
Denis: there has been discussions about migrating csswg.org and transfering some services away from it
… adding bikeshed support to the spec-generator rose in priority as a result
[demo of spec-generator applied to a ReSpec document]
[demo of a beta version of the spec-generator applied to a bikeshed document]
<denis> bikeshed on spec-generator
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
… when loading a URL, try to resolve relative files
tab: bikeshed does it directly
Ken: and that's how we call bikeshed
Florian: worth documenting that a tar file is a solution to multi-file siutations
Ken: tar is documented in the UI
Denis: is this on track to replace the service? is anything missing?
Tab: looks absolutely on track
FLorian: how often do you update bikeshed on the system?
Tab: from a bikeshed, please use pip to get the latest release (not github)
… Peter's tool auto-update on release IIRC
Florian: what about metadata updates?
<TabAtkins> `bikeshed update`
Denis: how often should we "bikeshed update"
TabAtkins: that can usefully be done on a regular basis
Florian: a few times a day is probably fine
Denis: we'll try to deploy this new version of spec generator by the end of the year
Tab: I think Peter uses an hourly cron bikeshed update
Dom: do we know which are the current customers of the csswg.org version?
Tab: CSS specs are built on CI directly with bikeshed
Ken: in terms of customers, there is at least pr-preview
denis: we'll follow up once we have a stable version ready
sidvishnoi: will these be two pages or a single page for respec/bikeshed?
ken: they'll be kept as two pages on the same service space
sidvishnoi: might be useful to align the UI even without merging them
tidoust: in terms of integration - pubrules checker?
denis: once we have a single tool, that will make it much easier to get that done
florian: how long lived is the URL that the document produces?
Dom: it's a paramterized URL with the target URL in the query string
ken: but note that running that URL is costly since it's doing processing
carine: metadata - is this about latest version of TR? editors draft?
<TabAtkins> Here's an example of the "CG metadata" speced/
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.
… With that said, the question is a good one.
… Do you want to keep a static version of the metadata?
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.
dom: So we should look at the lifecycle of the data and the lifecycle of the spec.
Marcos: from the respec side, we can't read local files
… ideally, having the data included in the document is preferable although we can fetch from a location
… both for performance and for easing maintenance
carine: the spec generator could scrape metadata from the doc
TabAtkins: the CG monitor is a very specialized type of data
… but we might be talking a wider set of information
dom: goal is to contextualize what readers should know to understand the status of a CG report
Tab: open to anything
Marcos: likewise, although we may want to do our own postprocessing on the data
Tab: probably a repo of data that generators can fetch data from the URL published space
<kenneth> +1 what's the authoring story of this
dom: in general, we expect the metadata to be updated automatically. We may need input from editors
… the repo would reflect what we would have learned from the editors
… if we do things right, the problem you are surfacing should be a big one
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
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
Marcos: +1
<TabAtkins> speced/
ken: I understand there are reasons to use a single big repo; how has the experience of bikeshed-boilerplate?
tab: a lesson is being careful in versioning, but nothing that I expect to be particularly troublesome
avneesh: we're already doing this for other data, e.G. MDN
Marcos: I would love it if we could take the W3C id of people to get their data
<kenneth> +1 affiliation updates in specs are a complex subject lol
Tab: in CSS, we retain older affiliations, so automating some of this would be problematic
Dom: we could revisit our privacy approach
Denis: the systeam will discuss it
dom: is the W3C id the right entry point?
Tab: would prefer a username (github or w3c)
dom: could be email address
Tab: W3C could generate files for editors metadata
[Check the W3C API doc and /users/connected/{service}/{identifier} endpoint in particular: https://
Ken: you could also iterate over the participation ends point of the W3C API to find the right person
Marcos: note that there had been pushback (e.g. from Manu?) on exposing editors data
Vivien: reminds me of tr-editors.rdf