W3C

– DRAFT –
CG Specification Communication Enhancements

12 November 2025

Attendees

Present
AndreasTai, DanielM, DanielMurphy, Darius, Denis, Dom, Ege, Francois, Ian, Manu, MattGarrish, Mike™, Tab, tidoust
Regrets
-
Chair
Dominique Hazaël-Massieux, Ian Jacobs
Scribe
dom, denis

Meeting minutes

Slideset: https://docs.google.com/presentation/d/1-96YXga4LLRDmWITdUnjjFtnRnftkS0Dk_yJKBeHBgA/edit and archived PDF copy

[Slide 2]

[Slide 3]

[Slide 4]

CG Spec Lifecycle

[Slide 5]

francois: a meta comment: is the information tracked outside of the spec? historical CGs with snapshot which can get updated? when a repo is transfered, will that point forward?

francois: the metadata is only useful if it differs from spec to spec
… how often do you expect different information?
… what incentive will there be to keep the metadata?

dom: e.g. not all specs have clear ideas for standardization

EgeKorkan: on the template in general - compared to a WG draft, there isn't enough visual difference

manu_: when there is too much boilerplate, people glaze away
… a simpler signal like a progress bar summarize the overall status might be interesting
… a bit concerned about language at the top - it feels a bit like pushing people away from the spec
… not on standards track feels it might never get there

dairusk: +1 to the progress bar even though I understand it's not a linear progress

<EgeKorkan> +1 to something crisp at the top like a progress bar

dairusk: "nor is it on the standards track" - how is this any better than a random blog post then? maybe surface some of the community support
… nerds like me will read the table and get useful info, but I'm worried about the busy senior engineer dimissing it as irrelevant
… I have comments on the metadata and how a CG would formulate an opinion
… this might related to the Chairs training

Daniel: re banner wording - there is a risk of disincentivizing interest - giving a more positive wording on what would be needed to get there

<manu_> dom: There might be something worth signalling that "this is linked to standardization discussions" -- making distinction between random idea vs. this is a CG that has done many standards -- there is more context in qualifying the standardization tracking.

@@@: not just saying what it is not, but also what is/where it goes

manu_: another thing we've found useful is how to participate, including links to the calendar for meeting participation

ian: we've focused on the "adoption" more than "participation" side

<Zakim> tidoust, you wanted to wonder about "incubation"

<Zakim> manu_, you wanted to note "Meetings:" as a ReSpec header... "how can I contribute?"

tidoust: the word "incubation" doesn't appear anywhere here; we use it internally but it might be useful to surface it

<EgeKorkan> +1 to incubation wording

tidoust: some groups may not be incubating toward standardization, that could be useful to surface as well

mike: what about a CG that want to do de-facto standards? that want to see implementation

ianj: we do want to encourage implementation, but clarify the W3C standardization status

mike: if we were to keep something, it should link to something that explains what a W3C standard is

Mike: when a WG publishes a FPWD, it can also be quite unstable
… it may itself be an incubation
… there may not be a lot of differences between what a CG and a WG may publish

<manu_> dom: Yes, not everyone cares about all of the details. Web developers want to know if this is experimental in chromium, or if webkit has already said they will implement. Not informaiton is useful for everyone, web developers trying to get clarity -- this is an important signal.

<manu_> mike: marcos did create something that shows wpt test results -- visual way, single line, -- this only works for specific class of specs that work in browser engines. This gets complicated becuase wpt doesn't track acording to specs.

<manu_> dom: WPT reflects current state -- are there signals of browser interest? This is something we'd expect to surface in guidance -- we need to make this work outside of browser world. Provide structure to make it visible in other environments. We are not tring to ignore what is happening there, we want to incorporate it in a way that is easier to understand by regular folks.

atai: +1 to Mike - a lot of people not involved in standardization won't make a difference between a standard, a spec, a CG report, a short explainer on the differences
… linked from the page would be super useful

ian: "this is not a W3C standard" may be reductionist, with additional nuance that may be useful
… to avoid discourage people

manu_: say what it is more than it is not

dom: "W3C incubation" may give a false impression

<tidoust> [So instead of "this is a W3C incubation", it could be "this is incubation"]

dariusk: "this is not a standards, here is what you can to do help"

EgeKorkan: "W3C incubation" = "an incubation"
… any status for non-spec reports

Ian: no requirements have been set on those

DanielMurphy: may be worth aligning with other WG process improvements being discussed

[Slide 6]

[Slide 7]

[Slide 8]

ian: we should add a link to where it has been transfared

[Slide 9]

[Slide 10]

Ian: hearing we may want more to distinguish from TR - find a trade-off with making it look like a spec

[Slide 11]

[Slide 12]

dom: some metadata are quite simple (status, etc)
… for some specs, there is additional data maintained (signals for potential implementors)
… we can reuse
… on Monday, we had a discussion on how to integrate this with bikeshed and respec
… for browser specs, we do have data
… for the other specs that don't have access to similar infrastructure, Francois and I had experience with workflows to automatically open issues
… I imagine we could use similar system when we detect the report has indicated interest
… we can check activity and escalate this to the chairs and if we still have no response, Ian and I can look into it
… we started checking with the WICG on how to bring visibility
… the basic idea is to fully embrace that it's dynamic information we can surface in the spec
… my expectation is that it'll force discussion in the CG
… "what are your classes of product, who will be the implementors?"

Ian: we don't want to overburden editors and groups with new processes
… we want to provide more support and make it easy to surface the information

<Zakim> manu_, you wanted to specify "targetOutcome" in Respec/bikeshed?

manu: +1 for not overburning the CG
… is there anything we can do to help?

Dom: in terms of registering report, we would be pushing the CG to adopt the IPR checker
… it helps with tracking commitment
… some of the signals are well aligned with updated publications
… others aren't
… part of what we want to do is allowing mechanisms to help get data from other sources

manu: in our CG, we have 3 chairs. If it requires learning more tooling, I'm afraid this can create an obstacle
… we don't publish using the CG tooling until the very last stage

dom: to be clear, we are moving away from the publication tool

manu: if you provide a template, that would be ideal
… I'm concerned about training

dariusk: it occurred to me that CGs can sometimes feel at sea
… you have to be proactive to get in touch
… the audit type thing would help

Dom: that's exactly the kind of process we have in mind

Ian: we sometimes hear the successful CGs don't know what are the next steps
… and we want to help new groups get support

[Slide 13]

Dom: there are 3 variations of kind of signals we want to give
… do we have strong community support, implementors participation, and is the spec stable?
… it could be binary guidance or enumeration
… or just avoid any qualification and just look at the facts
… the first level of feedback is whether we want CG to provide opinions to make help readers

Ian: that's the challenge, how to communicate the progress

<Zakim> manu_, you wanted to note "community prioritization poll" vs. "implementations"

manu: in the credentials CG, we put out a poll
… to get feedback
… and some of the specs had 11 implementations, but one of the specs that ranked really high in the group had 0 implementation
… I'm concerned about how this would negatively impact the interest on the spec

dom: none of this will appear like this is a blocker
… we see it more like an opportunity to lobby. We want to provide a framework for CG to raise interesting conversation
… this is needed

tidoust: for the facts, it works well for the things that are being implemented
… @1

dom: some of the metadata may not be applicable to all the CG specs
… the notion of implementors is very clear in some cases but in others (vocabularies), it's a bit fuzzy

[Slide 14]

Ian: we'll have the CG lunch today
… we also welcome volunteers

Minutes manually created (not a transcript), formatted by scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC).

Diagnostics

Maybe present: @@@, atai, dairusk, Daniel, dariusk, EgeKorkan, ianj, manu_, mike

All speakers: @@@, atai, dairusk, Daniel, DanielMurphy, dariusk, dom, EgeKorkan, francois, ian, ianj, manu, manu_, mike, tidoust

Active on IRC: atai, breakout-bot, dairusk, Daniel, dariusk, denis, dom, EgeKorkan, manu_, tidoust