Meeting minutes
P2023.1 update
plh: on the agenda, short update on P2023.1:
… call for review ended three weeks ago
… lots of conversations at TPAC on process
… we should look at new issues
… Florian suggested we look at pending issues on FOs and Council
… see if we have any P2024 issues
… I did not put on the agenda topics that are priorities for the AB
… we deferred a bunch of issues from p2023, so we should review and see what we want to un-defer for P2024
… anything else?
Process 2023.1 update
plh: it's been recommended that extraordinary delegation is used, is in vote.
… TAG election has been early notified; if we can get the FO addressed prior to TAG election starting we will increase the size of the TAG this round, otherwise it will have to wait.
Tzviya: I think we have enough votes from the potential council members to call it?
plh: yes, but members can change their votes until Oct 3.
<TallTed> most weeks for the next while, I'll have a conflict with RDF Canonicalization and Hash Working Group in this timeslot :-(
Updates from TPAC 2023?
plh: this is an open agenda item. before TPAC I identified several breakouts of interest to process peeps - incubation, chartering, ...
… anything else?
florian: I don't think we should jump into it immediately, I plan to summarize for the AB prior to proposing to the CG.
New issues (since June)
plh: new issues: some of these are editorial, I expect Florian will propose PRs if appropriate.
<plh> Github: w3c/
plh: I assume this is editorial
… will flag it as such
w3c/
… Too easy to confuse wide and horizontal review. I think one is contained in the other.
<plh> github: w3c/
tzviya: I think this is one of the confusing points of the process. People generally use the terms interchangeably even though we know they're not. We should clarify.
fantasai: I think this is largely a problem with how we have been educating people on these terms. E.g. the document on wide review is 95% on horizontal review.
… the part that's outside horizontal review gets lost because we don't talk about it, and it doesn't have formal structure.
<plh>
florian: I agree there is confusion, Elika's hypothesis on why is plausible. Maybe we should start there.
… as to Tzviya's point about simplification, I agree, but we should not talk about process simplification in general, we need to be specific. Maybe this is one of those specific points, maybe it isn't. We should be detailed.
<fantasai> w3c/
plh: I don't hear anyone saying the process is broken...
… we could decide to push this to the guidebook first? it's not clear this is an actual process issue.
florian: maybe we should start there, and if it becomes obvious there is a process problem here, we circle back
… absent a specific idea, I would start with the Guide.
plh: the proposal is to move this to the Guide.
… this will be posted there unless someone reacts within a week
<plh> Github: w3c/
plh: this is about veto by inaction
… this is not part of chartering; it's part of clarifying what happens when the Team basically makes decisions that are not recorded as Team Decisions.
… there is a thread since July on this. Elika was the last one to comment.
… this seems to be part of the chartering discussion. Is that the case?
florian: I suspect in theory it's broader than chartering, but in practice, 90% of what people care about is chartering. We should table this until we've dealt with chartering.
plh: any objection?
… moving on...
editorial issue:L w3c/
… seems like there is editorial convergence, we don't need to discuss.
florian: as long as we're converging in the issue, yes.
plh: next is w3c/
<plh> Github: w3c/
LS/CR candidates need to address wide reivew issues.
Florian: is this relevant to the WHATWG MOU?
PLH: no
cwilso: yes
plh: what worries me is Mike Champion's last request, that update requests be subject to the same requirement as transition requests.
florian: ah yes. I Don't think we want to require everything be addressed; that would make it difficult to do CR updates.
<plh>
florian: it's not clear that the team has the ability to say "you have made progress on issues that you care about, but ignored everything that others have reported, so your update request is denied"
<fantasai> +1 to florian
florian: something along those lines would be desireable.
plh: we didn not introduce a requirement to address issues during the update requests, but we did introduce requirements to at least note which issues are flagged as needs resolution.
plh: the council rules currently place TBL on the critical path for applying the unanimous short circuit. We never intended him to be on the critical path, so we should fix this in 2024. (Presuming TBL is okay with that.)
florian: I've made a specific suggestion, would like to know what TBL thinks.
plh: yes.
<fantasai> I think the alternative path would be to specifically make him an optional member of the Councils.
<fantasai> but remain a formal member of the TAG
plh: ...we will need to ensure the TAG is okay with your resolution as well.
rachel: for horizontal review process, is it automatic? I'm curiously about the whole process
<plh>
plh: look at ^^
Formal Objections and Council issues
plh: let's move on. We have 9 open issues against the Council right now.
Florian: my general idea is we need to do maintenance on the director-free part of the PRocess. there are a few things we wanted to do in the review period, which TBL declined to do; I think we should pick those up for P2024.
… we should also deal with things that we have learned through experience with Councils.
plh: at the minimum, we should flag these issues as P2024 and go through them.
… Florian, I'll ask you to start picking issues to bring to the CG discussion
… some of these are flagged as needs AB discussion
florian: some of those already have an AB decision; not sure if any of them are waiting on AB discussion.
plh: next time, let's start going through pending PRs
Process 2024: REC maintenance #589
<plh> Github: w3c/
florian: Tzviya earlier raised complex areas that are ripe for simplification. This is one of those areas. It's far from trivial to see how we can simplify at a glance; we can't just simplify the grammar or removing half the rules, because they are there for reasons.
… we don't want to make it possible to change a REC in ways that could not have originally been published as REC in the first place through the update process.
plh: over the summer, Ralph asked me to put more resources on ReSpec and Bikeshed, which should help in maintaining RECs
<plh>
plh: it's sometimes difficult to determine whether a change is substantive or editorial.
… for example, WCAG 2.1
<fantasai> https://
tzviya: I think this goes hand-in-hand with issue 700 that Wendy raised on how to determine which of the two paths to use.
… w3c/
… since there's no explicitly different name for the "living standard" version, it's very confusing.
… there needs to be some kind of guide for chairs et al to help understand how to choose between the paths.
… Wendy wrote some text about this.
plh: hopefully we're not suggesting simplifying by writing more documents.
tzviya: I'm saying as co-chair of EPUB that the experience of understanding this is... hard.
… it's not clear what maintenance vs stable rec means
florian: I think I know what you're talking about - the choice between recs that can gain new features or not
tzviya: yes.
florian: most groups should choose the type that can gain new features
tzviya: but you have the knowledge of having written the process. Chairs do not (necessarily)
<fantasai> I think we need more flow charts
tzviya: there's "the default of what the W3C has done historically" as the preferred process. It would be good to have some textual explanation.
plh: #700 feels like a guide issue, not a process issue.
florian: possibly
… we should still examine and see if we can make it simpler, as I agree it would be desirable, but I expect this to be challenging to simplify.
plh: tzviya, can you work with Wendy to get that primed?
tzviya: yes.
plh: sounds like this should be assigned to myself and Florian.
… I think this is still in P2024 issue to look into.
<plh> https://
plh: let's spend a few minutes on deferred issues.
… there are 66 of them.
… anything we want to take up?
… I presume that the AB should figure out incubation before we take on issues around CGs and BGs
florian: We should talk about the precedence issue that we were blocked on PSIG for.
<plh> Github: w3c/
elika: PSIG concluded that they recommend not defining the precedence.
<fantasai> https://
<fantasai> github: none
<fantasai> "RESOLUTION: Given what is known at this time, PSIG recommends that the Process Document not define an order of precedence, but rather address each conflict as it is found on a case-by-case-basis."
florian: I suspect we should follow their advice and close these things as no change.
plh: I didn't mean to make decisions today, so let's take a proposal that we close in two weeks.
florian: I will send this to the AB.
ACTION: florian: Forward PSIG conclusion to AB
plh: any other issues we need to pick up?
… if you see any, either change the milestone or propose to change the milestone.
… my hope is we can propose a new process to the AB by the end of March 2024.
fantasi: seems like a reasonable target.
plh: adjourned. Next meeting in two weeks, although I probably cannot be at that meeting.