Minutes: W3C Process CG Telecon 11 March 2026

Summary of Resolutions and actions:

    • Merge pull request 1021
    • Close issue 714
    • Mark issue 712 as Proposed to Close

Full minutes: 
 https://www.w3.org/2026/03/11-w3process-minutes.html

And also pasted below for search.

Ian

====
Present: Brent Zundel (Chair), Ding Wei, Florian Rivoal, François Daoust, Ian Jacobs (Scribe), Ted Thibodeau

1. [6]PRs
   1. [7]w3c/process#1021
   2. [8]w3c/process#1129
   3. [9]w3c/process#937
2. [10]Issues
   1. [11]w3c/process#700
   2. [12]w3c/process#714
   3. [13]w3c/process#712
   4. [14]w3c/process#727

Meeting minutes

PRs

<brent> [16]https://github.com/w3c/process/pulls

[16] https://github.com/w3c/process/pulls

[17]w3c/process#1021

[17] https://github.com/w3c/process/pull/1021

<brent> Github: [18]w3c/process#1021

[18] https://github.com/w3c/process/pull/1021

Brent: I believe 1021 is ready to merge
… following lots of discussion

Florian: Last pending comment from @chrisn appears to have been
addressed.

Ian: +1 to the text

Florian: +1

(No objections)

RESOLUTION: Merge pull request 1021

[19]w3c/process#1129

[19] https://github.com/w3c/process/pull/1129

<brent> Github: [20]w3c/process#1129

[20] https://github.com/w3c/process/pull/1129

Florian: Last time I said I would combine comments into a
canonical text (done) and sent to PSIG (done). Now we await
PSIG replies so let's leave open.

[21]w3c/process#937

[21] https://github.com/w3c/process/pull/937

<brent> Github: [22]w3c/process#937

[22] https://github.com/w3c/process/pull/937

Florian: I'm still awaiting data from the Team.

Issues

<brent> [23]https://github.com/w3c/process/
issues?q=is%3Aissue%20state%3Aopen%20sort%3Aupdated-asc

[23] https://github.com/w3c/process/issues?q=is:issue state:open sort:updated-asc

[24]w3c/process#700

[24] https://github.com/w3c/process/issues/700

<brent> Github: [25]w3c/process#700

[25] https://github.com/w3c/process/issues/700

Florian: Yes, revisions are complicated. I have some ideas for
simplification. One is easy, one complex.
… the easy one is to drop the distinction between Recs that can
have new features once published and those that can't once
published.
… the different scenarios create terminology explosion, so the
simplification is to say "All Recs can have new features once
published" but that would break old problems.
… but my suspicion is that, in practice, people don't rely on
the historical promise.
… people who refer to dated versions will be ok since we don't
update dated versions in place.

Brent: This is part of the AB's active discussion on process
refactoring
… my inclination is to label this to indicate that this is a
topic of active discussion.

Florian: Issue 700 is a general issue on "complicated process"
but I think there may be a specific issue as well. We can label
both as pending AB feedback.

Brent: I am ok with "pending AB feedback" but also "topic
simplification"

Ian: How is the AB handling this (e.g., principles, use cases,
etc.)?

Brent: We had a conversation at our face-to-face.

Florian: The related issue is [26]#938
… I have a proposal for how to make it less confusing.

[26] https://github.com/w3c/process/issues/938

Ian: It would be great to identify promises/guarantees and work
from there.

Florian: +1 to that comment. I think we can make some changes
that "don't change promises" and create less friction.

Ian: It would be great to articulate guarantees and then have a
strategic discussion of adjusting the dials (e.g., to get more
streamlined approach)

Brent: That is approximately how we are proceeding.
… and when discussed, the conversations are in the AB's minutes
… I hesitate doing a PR before the AB has made progress.

[27]w3c/process#714

[27] https://github.com/w3c/process/issues/714

<brent> Github: [28]w3c/process#714

[28] https://github.com/w3c/process/issues/714

Florian: There was not agreement on the 714 thread to make a
change.

Proposed: Close issue 714

(No objections)

RESOLUTION: Close issue 714

[29]w3c/process#712

[29] https://github.com/w3c/process/issues/712

<brent> Github: [30]w3c/process#712

[30] https://github.com/w3c/process/issues/712

Florian: Statements are being used. @mnot think that the checks
can be abused and there's a risk of overstating the level of
community endorsement.

Ian: Can someone characterize why Recs may be ok and Statements
less so?

Florian: I think the thinking is that there are more occasions
on the Rec track (in practice) for feedback
… see issue 712 for more detail.

Brent: Have concerns been validated through the processes
leading to some Statements (e.g., Vision)
… I did not have the sense that it was pushed through without
review.

Brent: What action might we take?

Ian: When we proposed a Sustainable Web WG, there was pushback
against guidelines on the Rec track.
… I pointed out that there was a path.
… Through statements, which would seem a good fit for an IG
deliverable, with enough opportunities for wide review and
feedback.
… There is value that the boarder community has a chance to
review documents before they become Statements.
… You could say that the TAG and AB bodies only get internal
review as part of the Process, and we should add an explicit
call for review from the rest of the community.

Florian: I believe that is already what the Process requires,
but I believe that Mark is not confident that the verification
that this has happened are sufficient

Ian: What are the signals that wide review was sought, say for
the Vision Statement?

Florian: Blog posts, communication at various events, feedback
on a public repository.
… Was it enough? We can argue about that. I would say yes.
… A possible step forward is that no one else seems to be
complaining about Statements. Maybe we could give people a last
opportunity to weigh in, and close the issue afterwards.

Ian: We don't have a way to easily reach all members of the
community. Should we do that on occasion? IETF seems to be
doing this once in a while. Could be used to seek feedback on
specific proposals.
… We have opportunities for the community to gather around.
TPAC. Breakout Days. Can we think of a community wide approach
to do some of this?

florian: We have a way to reach to *anybody*, but only those
who opt into it see the announcements.

Ian: Yes, public-review-announce.

[31]https://lists.w3.org/Archives/Public/
public-review-announce/

[31] https://lists.w3.org/Archives/Public/public-review-announce/

brent: My inclination is to say that this is a good question if
a Statement comes through that has not been sufficiently been
vetted. People can formally object to the publication in any
case. It doesn't feel that there's anything for us to be doing
here.
… My suggestion is that we propose to close this. Everyone who
has commented on the issue will see the proposal and today's
minutes, and may provide additional feedback.

Ian: I do note that the statements went through
public-review-announce mechanism.

PROPOSED: Mark issue 712 as Proposed to Close

Florian: I don't think Statements are fit for purpose *when a
very timely response is required* (e.g., call for review of
CRA; but for the purpose where they have been used in practice,
I think they are fit for Purpose.

[32]w3c/process#727

[32] https://github.com/w3c/process/issues/727

RESOLUTION: Mark issue 712 as Proposed to Close

<brent> Github: [33]w3c/process#727

[33] https://github.com/w3c/process/issues/727

Florian: I think the requirements are against the most recent
working draft (not the FPWD) but also if that's the case, then
it's not a useful requirement.
… there are tradeoffs here as well: more documentation is
onerous to produce, but presumed to inform reviewers

Florian: The priority of constituencies is important to
consider here.

Brent: I think I agree with the assertion that the issue
mischaracterizes the process. I do think that change logs are
important to reviewers. Perhaps there's something to look at
here more closely about the two points to consider when
creating a change log.

Florian: Many changes happen between CR and FPWD and I can
imagine diff is not helpful.

Brent: in the IETF, every internet draft goes through a series
of changes and at some point the editors decide to publish a
new version. With every new published version there is an
expectation that major changes will be captured in a change
log.

(No action on this issue at this meeting)

Florian: The appropriate thing might be to require it since
FPWD and observe that it pointing to the GitHub log is probably
sufficient.

Brent: I may not care about change log pre CR

Florian: class 4 changes may be useful for IPR reasons.
 --
Ian Jacobs <ij@w3.org>
https://www.w3.org/People/Jacobs/
Tel: +1 917 450 8783

Received on Wednesday, 11 March 2026 16:45:14 UTC