Minutes: W3C Process CG Telecon 11 June 2025

Summary of Resolutions:

   - RESOLVED: Merge PR #1067 to drop <dfn> aliases
     https://github.com/w3c/process/pull/1067

   - RESOLVED: Merge PR #1068 to rename Team Contact to Staff Contact
     https://github.com/w3c/process/pull/1068

   - ACTION: Make a PR for transitioning to REC from CRD
     https://github.com/w3c/process/issues/1063

   - RESOLVED: Merge #1041 to clarify multi-point multi-FO Councils
               with suggestions from fantasai
     https://github.com/w3c/process/issues/1041

   - RESOLVED: Merge #1046 to clarify timing of convening Council
     https://github.com/w3c/process/pull/1046

   - RESOLVED: Merge #1069 to explain Council confidentiality requirement
               dropping parenthetical
     https://github.com/w3c/process/pull/1069

   - RESOLVED: With the pending PRs merged as decided here, the
     Process CG believes Process 2025 is ready for AC Review
     barring any further issues filed before the end of the
     review period.

Full minutes: https://www.w3.org/2025/06/11-w3process-minutes.html
And also pasted below for search...
=======================================================================



W3C – DRAFT –
(MEETING TITLE) 11 June 2025 IRC log.
Attendees

Present
     brent, cwilso, fantasai, florian, hdv, Ian, plh, TallTed
Regrets
     -
Chair
     -
Scribe
     fantasai, florian

Contents

     Overview
     New Issues to Triage
         Inconsistent terms for "Note"
         Use "Staff Contact" instead of "Team Contact"
         Republishing a CR Snapshot for AC Review
     Pull Requests to Review
     Multi-point Multi-FO Councils
         Clarify timing of Council being convened
         Explaining Council Confidentiality Requirement
         Give the Chair suspension powers for emergencies
     Shipping the Process
     Summary of action items
     Summary of resolutions

Meeting minutes
Overview

plh: In the home stretch of Process 2025, review period closes on 16th

plh: Some comments from asking Team to look into deploying

plh: [reviews how Process CG works, welcomes new members of AB]
New Issues to Triage
Inconsistent terms for "Note"

github: w3c/process#1064

florian: Issue claims we have inconsistent terms for Note
… used to have different types of notes depending on who issued
… collapsed to Group Note
… and used Bikeshed linking abilities to anchor all of the more specific terms 
to the same <dfn>
… Side-effect is that Bikeshed lists all these terms in the index of terminology
… which exposes terms we aren't using
… But it seems very unlikely anyone is using auto-linking to these terms
… So the PR simply drops these aliases, so they are no longer in the index

plh: In Process 2020 TR templates, I stopped calling "Working Group Note" vs 
"Interest Group Note" and went to "Group Note"

plh: Any objections to merge PR 1067?

w3c/process#1067

RESOLUTION: Merge 1067 to drop aliases from <dfn> for group note
Use "Staff Contact" instead of "Team Contact"

plh: I'm not aware of anyone objecting to this. I circulated to the Team, no 
one seems to really care

github: Use "Staff Contact" instead of "Team Contact"

florian: I've made a PR that mostly does this, but /Guide has lots of 
references to Team Contact
… so the PR changes internal usage and the official <dfn>, but includes the 
term "Team Contact" as a alias

w3c/process#1068

ACTION: Plh to update Guidebook

plh: Any objections?

Ian: Because Team is Staff and Fellows, does this imply that Fellow can't be a 
Team Contact?

plh: Fellow can be a Staff Contact

florian: I think broad perception is that Team and Staff is interchangeable, 
and doesn't matter if contractors or employees etc.

fantasai: Fellow is a bit different from hired by W3C

plh: Process doesn't care, Team is whoever we say it is

plh: Objections to merge?

RESOLUTION: Merge 1068 to rename Team Contact to Staff Contact
Republishing a CR Snapshot for AC Review

github: w3c/process#1063

plh: We are simplifying the Process by removing Proposed Recommendation
… WG doesn't need to republish as PR
… This was a purely Member thing, not clear what it means to public
… So run AC Review on Snapshot, ok
… But a lot of groups are on auto-publish, fixing stuff gets published into 
CRD automatically
… then we are requiring a CR Snapshot and a call for exclusions which is 
essentially empty of substantive changes
… [missed]

florian: 2 ways to deal with, and not sure which way to go
… Problem is that CR Drafts could contain things other than editorial changes
… and because they're on autopublish and without Team Verification, when a CRD 
exists, we don't know a priori what's in it

<Ian> (The proposal says "as long as no substantive changes were made since 
the last CR Snapshot.")

florian: starting from a CRD is dangerous, because could include substantive 
changes
… First way to deal with this is to pretend problem doesn't exist
… Run AC Review on CR Snapshot, indicate on the side we'll fix typos etc, 
don't worry, then fold them in after AC Review
… Or apply those fixes during REC, which is allowed
… But this is not very elegant
… Alternative is that you can run from a CR Draft, but with extra condition: 
Team MUST verify that there are no substantive changes from the last CR Snapshot
… So it might be simpler to be able to run CR Draft, but need extra round of 
verification.

brent: Probably a bad idea, but another option would be to allow for a CR 
Snapshot to be done with the review of substantive changes
… and if no substantive changes then that review is cut short
… so change to CR Snapshot process

plh: It's a bad idea, because messes with Patent Policy.
… less than 60-day review for patent policy

fantasai: I am pretty sure we cannot change the 60 day window, it's part of 
the Patent policy

fantasai: the issue is not getting to CRS, the reviews to get there are 
controlled by the Team, they could wave those that aren't needed

fantasai: The problem would be what happens after you get to CRS: the patent 
review cannot be skipped, even if it isn't needed

plh: But Process prevents us from closing AC review less than 10 days after 
the the close of the exclusion period

florian: If people are in agreement, I can make a PR. Should I just merge it...?

plh: We'll have a call next week as well, actually.

florian: So I will allow AC Review on CRD as long as Team Verifies no changes.

plh: we used to have a sentence requiring disclosure of whether features can 
be added at REC
… we removed that requirement, but didn't replace with anything

florian: I think we did. You have to have that sentence before REC.

plh: So when starting AC Review, then need to ask if want to add new features 
or not
… WG might say yes, sure, then we republish CRD

florian: Just need to add in CRD before REC

fantasai: You need to add before AC Review

plh: And run on that draft

florian: Let me check for where that is in the Process

florian: If we agree, I'll make the PR for CRD checking and check for that 
sentence.
Pull Requests to Review

plh: Can we make those changes after wide review, or not? Do we need more 
review now?
… if need more review, let's not make those changes and just ship P2025

florian: Largely I agree with you, but I think the 2nd one is tiny enough to 
be safe to include. Third I wouldn't include, but if we find wording we like 
we can give AB and they can decide
… for the multi-point Councils, it's effectively editorial. But emphasis 
change. But I wouldn't block on any of it

fantasai: I would really like to take the first one

plh: ok, let's reivew each one and also decide whether to incldue for P2025
Multi-point Multi-FO Councils

github: w3c/process#1041

PR: w3c/process#1045

florian: Council is written to batch FOs into a single Council, but there is 
some careless phrasing that implies there's a single FO
… so goal is to clarify this
… We discussed last time and the phrasing kinda-sorta worked, but not 
entirely, so fantasai revised the PR

florian: Council decides whether to uphold or overturn the decision, but 
cwilso noted that some of the tweaks reduced emphasis that every point in 
every FO must be considered
… so new wording highlights this by calling it out explicitly

https://github.com/w3c/process/pull/1045#discussion_r2136925848
… the other thing is that the words we used, "confirm" or "overturn", and 
"confirm" felt like it had a bit of incubment bias
… shouldn't assume that it was a good decision, should look at it
… so switched to "uphold"
… if we like these changes we can modify PR and merge

florian: Updated PR would be to merge fantasai's change, and s/confirm/uphold/g

https://github.com/w3c/process/pull/1045/files

cwilso: I'm ok with this

plh: It sounds to me that no disagreement about this general direction, so I'd 
be comfortable merging this PR and including as part of AC Review
… I would be surprised if someone says that wasn't an expectation, especially 
since we've been acting that way

plh: Any objection to merging this PR with the two suggestions?

RESOLUTION: Merge 1045 with suggestions from fantasai
Clarify timing of Council being convened

github: w3c/process#1046

florian: Some confusion about when the Council is convened. Dismissal and 
renunciation was implied before selecting a chair, but this wasn't every explicit.
… so this makes it explicit that this is all required before convening Council
… no confusion that you could convene before running dismissal/renunciation

plh: Does this make the council dependent on the Team Report?

florian: That text was already there

plh: I thought we fixed that

florian: there's another section (next paragraph) that allows council to start 
without Team report

plh: Any other opinions on this? I think this is ok for AC Review.

fantasai: This is totally editorial, and I am in favor of merging

TallTed: I would put subsequent after dismissal and renunciation

florian: I think it's permissible to run chair selection while running 
dismissal and renunciation, but need to actually finish the selection by the end.

florian: I'm ok either way, up to you and Ted

cwilso: I'd prefer without, implies serialization

fantasai: I agree with Chris. The point of this section is not about the order 
of things, just that they all need to be done

plh: I'm fine with the suggestion from Ted

fantasai: I'm hearing hesitation from fantasai and cwilso

cwilso: What is it intended to add?
… to me it says "don't start chair selection until renunciation and dismissal 
concludes", and I don't think we want that. You can't complete, but can start.

plh: How about we merge without Ted's suggestion?

cwilso: sure

plh: Any objections?

RESOLUTION: Merge 1046

fantasai: I wanted to add another PR that's editorial
Explaining Council Confidentiality Requirement

github: w3c/process#1069

fantasai: there was some discussion and confusion about why councils need to 
be confidentials

fantasai: the deliberations are confidential to that council and the team 
contact, not more broadly, not to past/future other councils

plh: I'm worried we'll open Pandora's box with this

fantasai: that was deliberate when the process was designed, but some people 
have asked question, so I thought adding a Note to explain would be helpful

florian: There were two reasons, one was sensitive information. Another was 
protection from retaliation, to be able to speak their mind.
… That's true regardless of whether you receive information in confidence.
… I agree that what the note says is right, i.e. is what was intended when we 
created the Process
… Whether it's useful to say it is a different question.

Ian: I see that we have a /Guide entry for nature of Council deliberations. 
That seems like a good place to put an informative note.

plh: Yes, Process is too long. Can we reduce it. If we explain every line in 
Process, will be super long. Prefer to put into Guidebook

fantasai: There are two audiences for this note: one is people who are 
generally curious

<Ian> fantasai: There are two audiences for this note: (1) curious people (2) 
future Process Doc editors

fantasai: others is future people who are going to be maintaining the process

plh: could say that about any other line in the process

fantasai: having the note in place in the process is intended to give pause to 
any future AB/Process CG who would be tempted to take an axe to this for the 
sake of simplicity

fantasai: most of the other lines are easier to understand why they're there

plh: What do other people think?

florian: I agree with what the note says. Don't have a strong view on where. I 
hear fantasai's point.

florian: I'm mildly in favor

cwilso: Yeah, I'm mildly in favor

florian: I strongly agree with the message, and mildly agree it's the right 
place to put it

brent: Mildly in favor, but agree with Tzviya's suggestion to remove the 
parenthetical

<hdv> +1

fantasai: I was debating whether to have it or not, and added because easier 
to review that quesiton that way :)

<TallTed> +1 add the note minus the parenthetical ... tho I don't know that it 
achieves the stated goal

plh: Objections to merge the note without the parenthetical?

RESOLUTION: Merge 1069 without parenthetical.
Give the Chair suspension powers for emergencies

github: Give the Chair suspension powers for emergencies

github: w3c/process#1051

fantasai: I think this PR needs a bit of work, so it's probably not going to 
be done today

fantasai: but what it's trying to do is to give chairs explicit power to 
suspend people in emergency cases

fantasai: The hangup is trying to find the right wording

fantasai: there was a suggestion to refer to the Code of Conduct

fantasai: but it doesn't cover *all* problematic situations

fantasai: nigel had a suggestion

plh: I like the direction, but I don't think it's ready to merge

cwilso: I still object to the Chair's ability to kick people out for "well 
established" but not written rule. There's too much room for abuse

cwilso: Chairs shouldn't have the ability to kick people out for "that's not 
how we do things"

cwilso: But I'm in favor of adding this ability to the Process

<cwilso> as long as the "well established" is documented and expected, not 
possibly arbitrary.

Ian: Sorry, only noticed this PR this morning. My quick skim of the Code of 
Conduct is that this is taken into account, section 4 empowers chairs to take 
action they deem necessary
… why does Process document need to duplicate
… things like safety and sustained interruption are covered in CoC
… If there are other things, shouldn't have unacceptable defined in Process
… Make Code definitive place for this

plh: Give 1 minute and then switch to next topic due to time

florian: Reason why is that Code of Conduct only talked about behavior that is 
acceptable or unacceptable. Tiptoing wrt discipline.
… What clearly establishes disciplinary power is the Process, which gives that 
power to the CEO
… CEO can delegate, but this directly gives Chair suspension power
… Clearly needs more time to discuss

<Ian> Ian: We should not have "unacceptable behavior" in two places. And the 
Code of Conduct gives Chairs powers.

fantasai: Says chairs can ask to leave, but they could refuse...
Shipping the Process

florian: I'll do a PR by next week for the issue we need one, and merge the 
ones we agreed
… Besides that, if we get no further comments, are we ready for AC Review?

<Ian> Ian: If the Code of Conduct needs to be strengthened, let's strengthen 
it there instead of having text in 2 places

plh: Next AB meeting is next week... if they don't meet maybe we ask them for 
a CFC.

<plh> w3c/modern-tooling#112

plh: I've started to track the things we need to update
… Ian is already generating PR for the guidebook, charter refinement phase.

florian: Can we record an agreement that we think this is done, other than the 
pending PRs that we decided to day?
… that this group should start AC review?

plh: I'm OK with that.

PROPOSED: With the pending PRs merged as decided here, the Process CG believes 
Process 2025 is ready for AC Review, barring any further issues filed before 
the end of the review period.

<fantasai> +1

<florian> +1

<brent> +1

<plh> +1

<cwilso> +1

plh: Congrats everyone for bringing the Process all the way here.

RESOLUTION: With the pending PRs merged as decided here, the Process CG 
believes Process 2025 is ready for AC Review, barring any further issues filed 
before the end of the review period.

florian: Do we need a Disposition of Comments?

plh: Not hearing anything.

florian: I'll just make sure the labels are well-applied.

[discussion of who will draft the announcement]

plh: I'd like to start the AC review by the 24th of June then.
… then AC Review would end 22nd of July

florian: Important thing is to start. :)

Meeting closed.
Summary of action items

     Plh to update Guidebook

Summary of resolutions

     Merge 1067 to drop aliases from <dfn> for group note
     Merge 1068 to rename Team Contact to Staff Contact
     Merge 1045 with suggestions from fantasai
     Merge 1046
     Merge 1069 without parenthetical.
     With the pending PRs merged as decided here, the Process CG believes 
Process 2025 is ready for AC Review, barring any further issues filed before 
the end of the review period.

Minutes manually created (not a transcript), formatted by scribe.perl version 
244 (Thu Feb 27 01:23:09 2025 UTC).
Diagnostics

Succeeded: i/plh/scribenick: fantasai

Succeeded: s/I would put "and" between dismissal and renunciation/I would put 
subsequent after dismissal and renunciation/

Succeeded: s/without/without, implies serialization/

Succeeded: i/plh: It's a bad idea/scribe+ florian

Maybe present: PR

All speakers: brent, cwilso, fantasai, florian, Ian, plh, PR, TallTed

Active on IRC: brent, cwilso, fantasai, florian, hdv, Ian, plh, TallTed

Received on Monday, 16 June 2025 07:12:19 UTC