00:30:22 RRSAgent has joined #council 00:30:26 logging to https://www.w3.org/2025/11/12-council-irc 00:30:28 RRSAgent, do not leave 00:30:28 RRSAgent, this meeting spans midnight 00:30:28 RRSAgent, make logs public 00:30:31 Meeting: CG Specification Communication Enhancements 00:30:31 Chair: Ian Jacobs, Dominique Hazaël-Massieux 00:30:31 Agenda: https://github.com/w3c/tpac2025-breakouts/issues/41 00:30:32 Zakim has joined #council 00:30:34 Zakim, clear agenda 00:30:34 agenda cleared 00:30:34 Zakim, agenda+ Pick a scribe 00:30:35 agendum 1 added 00:30:35 Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy 00:30:35 agendum 2 added 00:30:35 Zakim, agenda+ Goal of this session 00:30:36 agendum 3 added 00:30:37 Zakim, agenda+ Discussion 00:30:37 agendum 4 added 00:30:37 Zakim, agenda+ Next steps / where discussion continues 00:30:38 agendum 5 added 00:30:39 Zakim, agenda+ Adjourn / Use IRC command: Zakim, end meeting 00:30:39 agendum 6 added 00:30:40 breakout-bot has left #council 00:58:43 shawn has joined #council 01:01:40 atai has joined #council 01:02:12 EgeKorkan has joined #council 01:02:53 tidoust has joined #council 01:03:15 Slideset: https://docs.google.com/presentation/d/1-96YXga4LLRDmWITdUnjjFtnRnftkS0Dk_yJKBeHBgA/edit 01:03:22 [slide 2] 01:03:24 scribe+ 01:04:09 Present+ Francois, Darius, Manu, Ian, Ege, DanielM, Denis, Dom, Tab, AndreasTai, MattGarrish 01:04:16 [slide 3] 01:04:33 [slide 4] 01:05:15 -> https://github.com/w3c/cg-program/blob/main/proposals/spec-lifecycle.md CG Spec Lifecycle 01:05:51 manu_ has joined #council 01:07:27 Present+ DanielMurphy 01:08:47 Present+ Mike™ 01:08:53 anssik has joined #council 01:09:09 [slide 5] 01:13:09 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? 01:13:30 francois: the metadata is only useful if it differs from spec to spec 01:13:48 ... how often do you expect different information? 01:14:49 ... what incentive will there be to keep the metadata? 01:15:03 dom: e.g. not all specs have clear ideas for standardization 01:15:13 q+ 01:15:19 q+ 01:15:24 present+ 01:15:38 dairusk has joined #council 01:15:43 EgeKorkan: on the template in general - compared to a WG draft, there isn't enough visual difference 01:15:44 ack EgeKorkan 01:15:52 q+ 01:16:07 ack manu_ 01:16:27 manu_: when there is too much boilerplate, people glaze away 01:16:49 ... a simpler signal like a progress bar summarize the overall status might be interesting 01:17:43 ... a bit concerned about language at the top - it feels a bit like pushing people away from the spec 01:17:58 q+ 01:18:14 ... not on standards track feels it might never get there 01:18:18 q? 01:18:36 dairusk: +1 to the progress bar even though I understand it's not a linear progress 01:18:43 +1 to something crisp at the top like a progress bar 01:19:13 ... "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 01:19:40 ... nerds like me will read the table and get useful info, but I'm worried about the busy senior engineer dimissing it as irrelevant 01:20:20 q+ to note "Meetings:" as a ReSpec header... "how can I contribute?" 01:20:22 ... I have comments on the metadata and how a CG would formulate an opinion 01:20:47 q+ to wonder about "incubation" 01:20:53 ... this might related to the Chairs training 01:20:59 ack Daniel 01:21:02 ack dairusk 01:21:24 dariusk has joined #council 01:21:58 Daniel: re banner wording - there is a risk of disincentivizing interest - giving a more positive wording on what would be needed to get there 01:23:01 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. 01:23:26 @@@: not just saying what it is not, but also what is/where it goes 01:23:55 manu_: another thing we've found useful is how to participate, including links to the calendar for meeting participation 01:25:13 ian: we've focused on the "adoption" more than "participation" side 01:25:19 ack tidoust 01:25:19 tidoust, you wanted to wonder about "incubation" 01:25:24 ack manu_ 01:25:25 manu_, you wanted to note "Meetings:" as a ReSpec header... "how can I contribute?" 01:25:58 tidoust: the word "incubation" doesn't appear anywhere here; we use it internally but it might be useful to surface it 01:25:58 +1 to incubation wording 01:26:19 ... some groups may not be incubating toward standardization, that could be useful to surface as well 01:26:57 mike: what about a CG that want to do de-facto standards? that want to see implementation 01:27:13 ianj: we do want to encourage implementation, but clarify the W3C standardization status 01:28:07 mike: if we were to keep something, it should link to something that explains what a W3C standard is 01:28:18 Mike: when a WG publishes a FPWD, it can also be quite unstable 01:28:27 ... it may itself be an incubation 01:28:34 q+ 01:28:41 ... there may not be a lot of differences between what a CG and a WG may publish 01:30:01 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. 01:30:48 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. 01:32:04 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. 01:32:10 ack atai 01:32:41 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 01:32:51 ... linked from the page would be super useful 01:33:17 q+ 01:33:17 ian: "this is not a W3C standard" may be reductionist, with additional nuance that may be useful 01:33:22 q+ 01:33:30 ... to avoid discourage people 01:34:12 manu_: say what it is more than it is not 01:35:16 q+ 01:35:39 dom: "W3C incubation" may give a false impression 01:35:45 ack dariusk 01:35:46 [So instead of "this is a W3C incubation", it could be "this is incubation"] 01:35:47 ack manu_ 01:36:09 dariusk: "this is not a standards, here is what you can to do help" 01:36:22 EgeKorkan: "W3C incubation" = "an incubation" 01:36:31 ... any status for non-spec reports 01:36:43 Ian: no requirements have been set on those 01:36:45 q+ to specify "targetOutcome" in Respec/bikeshed? 01:37:36 DanielMurphy: may be worth aligning with other WG process improvements being discussed 01:37:42 [slide 6] 01:37:49 [slide 7] 01:38:13 [slide 8] 01:38:37 ian: we should add a link to where it has been transfared 01:39:04 [slide 9] 01:39:06 [slide 10] 01:40:10 Ian: hearing we may want more to distinguish from TR - find a trade-off with making it look like a spec 01:40:23 [slide 11] 01:40:31 [slide 12] 01:41:05 scribe+ 01:41:41 dom: some metadata are quite simple (status, etc) 01:42:05 ... for some specs, there is additional data maintained (signals for potential implementors) 01:42:16 ... we can reuse 01:42:32 ... on Monday, we had a discussion on how to integrate this with bikeshed and respec 01:42:39 ... for browser specs, we do have data 01:43:22 ... for the other specs that don't have access to similar infrastructure, Francois and I had experience with workflows to automatically open issues 01:43:58 ... I imagine we could use similar system when we detect the report has indicated interest 01:44:55 ... we can check activity and escalate this to the chairs and if we still have no response, Ian and I can look into it 01:45:36 ... we started checking with the WICG on how to bring visibility 01:46:06 ... the basic idea is to fully embrace that it's dynamic information we can surface in the spec 01:46:22 ... my expectation is that it'll force discussion in the CG 01:46:52 ... "what are your classes of product, who will be the implementors?" 01:47:06 q+ 01:47:10 Ian: we don't want to overburden editors and groups with new processes 01:47:32 ... we want to provide more support and make it easy to surface the information 01:47:32 ack e 01:47:37 ack manu_ 01:47:37 manu_, you wanted to specify "targetOutcome" in Respec/bikeshed? 01:47:44 manu: +1 for not overburning the CG 01:48:13 ... is there anything we can do to help? 01:48:30 Dom: in terms of registering report, we would be pushing the CG to adopt the IPR checker 01:48:37 ... it helps with tracking commitment 01:48:52 ... some of the signals are well aligned with updated publications 01:49:01 ... others aren't 01:49:46 ... part of what we want to do is allowing mechanisms to help get data from other sources 01:50:21 manu: in our CG, we have 3 chairs. If it requires learning more tooling, I'm afraid this can create an obstacle 01:50:40 ... we don't publish using the CG tooling until the very last stage 01:51:00 dom: to be clear, we are moving away from the publication tool 01:51:09 manu: if you provide a template, that would be ideal 01:52:30 ... I'm concerned about training 01:52:40 ack dariusk 01:53:01 dariusk: it occurred to me that CGs can sometimes feel at sea 01:53:09 ... you have to be proactive to get in touch 01:53:48 ... the audit type thing would help 01:54:15 Dom: that's exactly the kind of process we have in mind 01:54:16 csarven has joined #council 01:55:04 Ian: we sometimes hear the successful CGs don't know what are the next steps 01:55:29 ... and we want to help new groups get support 01:55:47 [slide 13] 01:56:11 Dom: there are 3 variations of kind of signals we want to give 01:56:35 ... do we have strong community support, implementors participation, and is the spec stable? 01:56:57 ... it could be binary guidance or enumeration 01:57:16 ... or just avoid any qualification and just look at the facts 01:57:18 q+ to note "community prioritization poll" vs. "implementations" 01:57:55 ... the first level of feedback is whether we want CG to provide opinions to make help readers 01:58:04 q+ 01:58:19 Ian: that's the challenge, how to communicate the progress 01:58:21 ack manu_ 01:58:21 manu_, you wanted to note "community prioritization poll" vs. "implementations" 01:58:58 manu: in the credentials CG, we put out a poll 01:59:06 ... to get feedback 01:59:31 ... and some of the specs had 11 implementations, but one of the specs that ranked really high in the group had 0 implementation 01:59:58 ... I'm concerned about how this would negatively impact the interest on the spec 02:00:19 dom: none of this will appear like this is a blocker 02:01:06 ... we see it more like an opportunity to lobby. We want to provide a framework for CG to raise interesting conversation 02:01:14 ... this is needed 02:02:41 tidoust: for the facts, it works well for the things that are being implemented 02:02:44 ... @1 02:03:08 dom: some of the metadata may not be applicable to all the CG specs 02:03:30 ... the notion of implementors is very clear in some cases but in others (vocabularies), it's a bit fuzzy 02:03:47 [slide 14] 02:03:55 Ian: we'll have the CG lunch today 02:04:13 ... we also welcome volunteers 02:04:44 RRSAgent, draft minutes 02:04:46 I have made the request to generate https://www.w3.org/2025/11/12-council-minutes.html denis 02:05:54 manu_ has joined #council 02:21:23 shawn has left #council 02:24:11 manu_ has joined #council 02:28:29 manu_ has joined #council 03:11:15 RRSAgent, bye 03:11:15 I see no action items