- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 13 May 2026 18:44:38 -0500
- To: public-w3process@w3.org
Summary of Resolutions and actions: • Resolution: Merge pull request 1151 * Action: Ian to work with Brent on a framing narrative to ground a series of GitHub issues to initiate brainstorming. Full minutes: https://www.w3.org/2026/05/13-w3process-minutes.html And also pasted below for search. Ian === [2]Agenda. [3]IRC log. [2] https://lists.w3.org/Archives/Public/public-w3process/2026May/0000.html [3] https://www.w3.org/2026/05/13-w3process-irc Attendees Present: Brent Zundel, François Daoust (tidoust), Theresa O'Connor (hober), Ian Jacobs Regrets: Florian, TallTed Chair: Brent Zundel Scribe: Ian, tidoust Contents 1. [4]Agenda+ things 1.1. [5]w3c/process#1151 2. [6]WG Adjustments Issue generation party 3. [7]Next steps 4. [8]Summary of action items 5. [9]Summary of resolutions Meeting minutes Agenda+ things [10]w3c/process#1151 [10] https://github.com/w3c/process/pull/1151 <brent> Github: [11]w3c/process#1151 [11] https://github.com/w3c/process/pull/1151 <Ian> +1 to the proposed change in 1151 Brent: +1 to the change [No objections to merging this] RESOLUTION: Merge pull request [12]#1151 [12] https://github.com/w3c/process/issues/1151 WG Adjustments Issue generation party Brent: The AC discussed process; the AB continued the conversation … at a high level, the AB supports changes and for the Process CG to write some proposals Brent: "Let many issues bloom" was my sense of the AB's persepctive Brent: The main pain points to address: … - rechartering … - timelines and relationship to horizontal review … - maintenance Ian: I'm curious if IPR boundaries of groups have come up as a pain point to address. Like 9 deliverables in this group, but 2 of them I'm not happy with. Brent: It has come up as a consideration, but not as a pain point. Tess: The AB has not identified that consideration as a priority pain point. Brent: ideas welcome! Tess: One common refrain from Kobe discussions - a lot of WGs view the timelines for deliverables to be fiction … smaller number of groups valued timelines as a forcing function … in AB discussion, we discussed other relevant dates related to a charter that are not surfaced (e.g., work is happening to meet an externally determined time frame, e.g., regulation) … or another SDO wants to refer to a W3C doc Ian: Here are some of what a charter accomplishes: … * IPR scope … * Resource allocation … * Project management … * Operations (decision making, meetings, etc.) Ian: And here are the sorts of "tools" people have mentioned previously for decoupling those goals from charters / rechartering: … * Persistent groups (CSS) … * Lower staff resources for mature groups … * Dashboards and operational efficiencies … * Super groups Ian: Could some of these things be captured differently, in a way that would be more persistent and not tightly coupled to rechartering for example? hober: This is exactly the kind of list we're hoping to make and open a bunch of issues that will lead to brainstorming hober: Regarding IPR scope...can we get away with not listing deliverables in charters? … in particular when the IPR scope is clear … we have an idea that scope and list of deliverables are orthogonal but they are not as separate as we may think. … CSS transitions and animations is an interesting case; prior to these, CSS had no "temporal" component … it would have been reasonable at the time to consider such features as "out of scope" for CSS … we didn't change the wording of the CSS scope when we added those deliverables. There are just differences in scope interpretations Ian: How will companies deal with large groups without lists of deliverables? Hober: We would need to get crisper on scope, and likely have explicitly an "out of scope" section to satisfy concerns explicitly. brent: I think your example is an argument for (rather than against) separating scope and deliverables. Most companies care more about the deliverables more than the scope. … I'm going to push back on the resource/staffing aspect of this. I don't think people on the team look at end dates in practice to reallocate staff. … I think people are not, in practice, thinking about charter end dates seriously in terms of staff reallocation … Another point (as we talk about "super groups" for example): I don't think there should be special rules for some groups v. other groups. tidoust: CSS WG is pretty easy to recharter since the scope doesn't really change and we have tools to regenerate deliverables list. … whereas the non-super-groups are the ones where rechartering is more complex. … regarding staff allocation, I agree with Brent we don't look at the future. We find a way to make it work. hober: The way that the team contact is listed is serving multiple functions. (1) names someone (2) fractional FTE...that helps with knowing whom to contact, knowing who is accountable. I think the fractional FTE is more internal to the team, even if a bit useful to Membership … but we don't pay close attention to how the team chooses to allocate its time … I personally think the primary thing that's important to a Member is accountability … regarding supergroup discussions: we should not enshrine a difference between types of groups (agreeing with Brent on that point) … we need to acknowledge that there are patterns, however. … some groups are long-lived and amorphous (e.g., css, web apps) … some groups have debates around deliverables...we see different types of groups and situations, but we should not enshrine rule differences. … I would hope we can "apply some of the exceptions" to everyone … or we should take them away across the board Ian: Another topic of interest "hanging around at CR" should not be perceived as a bug. Tess: In recent meetings we talked about requirements to advance from CR to REC would be outside the group's responsibility; the ecosystem around the group does the work and we observe interop … the trick to doing that at W3C would be shifting how / when horz reviews happens brent: Regarding the parallels with the IETF: … - if we think of a Rec at W3C as a things that's reached a fixed point, won't change without pain, and there has been some wide review.....at the IETF an RFC meets those qualifications … - whereas a CR can change relatively easily Next steps Brent: I was going to open an issue to consider removing charter end dates. Ian: Can we first write a short "projet" that explains what we want to accomplish (e.g., based on our discussion today) in order to to ground a future set of issues? Hober: We also need to clearly indicate to people when brainstorming is happening and that our goal is to surface pros and cons Hober: But not sure we need an explainer first. Hober: What I would commit to is that we are earnestly considering a set of pros/cons … it's good to know where the third rails lie … one thing that I like about groups when rechartering is kicking out members and making them think explicitly about rejoining tidoust: Good comments. We've been focusing on the content of the charters. Removing end date removes rechartering issue. But if we don't remove it, we should also look at simplifying the rechartering friction <Zakim> brent, you wanted to say maybe an email to the AC would be enough? and to say maybe it's membership in the group that expires, rather than the group itself brent: I think a framing communication via email to the AC could suffice Hober: +1 brent: Another topic is IEs. … what if it's not groups that expire but membership in groups that expires? Ian: Many useful things captured here. Maybe in the end, an email would be the right thing to do. But I still think it would be useful to set the stage: what do charters and chartering accomplish today? what are perceived pros and cons of how those goals are accomplished? Would decoupling enable us to address some concerns? Then we could share that document and get feedback for a short period, and then raise issues, linking back to the document. That approach would give more context than a big bucket of issues on their own. hober: Regarding membership in groups expiring .... interesting idea. But there's a coupling between the moment when the list of deliverables changes and the membership renewing its IPR commitment. If we decouple kicking out members from IPR considerations, we might create more busywork for members … if the scope of a group changes infrequently, but we kick members out, say, every 2 years, then 2 of the 3 times you are kicked out it's just forcing you to push a button, which may be more annoying. … right now, being kicked out is a signal that something important has happened (IPR scope changed) … so maybe the coupling is IPR scope changes / kick out. That's a valuable coupling but may be smaller granularity than the whole charter changing … in a world where WG responsibility is to get to CR...we might end up with a new stable place where we recharter groups for shorter periods then spin them down, but we'd need a new way to do maintenance. hober: We need to be clear about what we're committing to ... and then come up with structures that best serve that ACTION: Ian to work with Brent on a framing narrative to ground a series of GitHub issues to initiate brainstorming. Summary of action items 1. [13]Ian to work with Brent on a framing narrative to ground a series of GitHub issues to initiate brainstorming. Summary of resolutions 1. [14]Merge pull request #1151 Minutes manually created (not a transcript), formatted by [15]scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC). [15] https://w3c.github.io/scribe2/scribedoc.html -- Ian Jacobs <ij@w3.org> https://www.w3.org/People/Jacobs/ Tel: +1 917 450 8783
Received on Wednesday, 13 May 2026 23:44:53 UTC