Minutes: W3C Process CG Telecon 11 September 2024

Summary of Resolutions:

   - RESOLVED: Merge PR#908 to update REC maintenance diagram
     https://github.com/w3c/process/pull/908

   - RESOLVED: Merge PR#911 to mark figures as non-normative
     https://github.com/w3c/process/pull/911

   - RESOLVED: For Issue #843 about procedural disagreements wrt Council,
               put something in /Guide.
     https://github.com/w3c/process/issues/843

   - RESOLVED: For Issue #825 wrt post-AC-Review substantive changes,
               adopt PR #910 with "only" moved from "may only" to "only if".
     https://github.com/w3c/process/pull/910
     https://github.com/w3c/process/issues/825

   - ACTION: florian and fantasai to draft minimal Member Submissions section.

Full minutes: https://www.w3.org/2024/09/11-w3process-minutes

And also pasted below for search...
=======================================================================


W3C – DRAFT –
(MEETING TITLE) 11 September 2024 Agenda. IRC log.
Attendees

Present
     cwilso, fantasai, florian, plh, TallTed, tantek
Regrets
     -
Chair
     plh
Scribe
     fantasai

Contents

     Administrative
     Pull Requests to Merge
         Add REC maintenance to diagram
         Explicitly mark figures as non-normative
         Deal with procedural disagreements within the Council
         Tighten the how subtantive changes are handled post AC-Review
     Issues to Discuss
         Should member submissions be removed from the Process?
     TPAC
     Summary of action items
     Summary of resolutions

Meeting minutes
Administrative

plh: Not meeting during TPAC

plh: Any topics to add?
Pull Requests to Merge
Add REC maintenance to diagram

github: w3c/process#596

PR: w3c/process#908

plh: Any objections to merge?

RESOLUTION: Merge
Explicitly mark figures as non-normative

github: Explicitly mark figures as non-normative

PR: w3c/process#911

RESOLUTION: Merge
Deal with procedural disagreements within the Council

github: w3c/process#843

florian: This has happened once. I was chair of a Council, where Council could 
not agree about what it was allowed to do.
… disagreement wasn't about the merits of the case, but whether we were 
allowed to rule on the question
… as a chair I had no way to resolve, and no one to appeal to
… if we all agree after some discussion, it's fine
… but if we can't find consensus about what we're allowed to do, then what?

florian: Proposal is to have the council vote on this, and then write it down 
as part of the decision, and AC can appeal if necessary
… could do without writing into the Process, but when it happened to me as a 
chair of the council, I failed to unlock the situation without a rule to base 
that resolution on
… luckily in that Council we found a workaround

<cwilso> -1 to Florian being a bad Council chair. :)

plh: One thing is what do we do in this case. Other is where do we document it.
… in a WG, when there's disagreement about the Process, the chairs turn to the 
Team and ask Team to interpret the process
… the Team is tasked to provide interpretation of the Process, which allows us 
to move forward when Process is not clear etc.
… if you disagree with the Team, we say raise an issue against Process
… We do this all the time; the Team interpets the Process.
… sometimes we even disagree with the Process editors, but we discuss and find 
a consensus

plh: The Team doesn't really participate in the Council. Have a Team Contact, 
though, so can ask the Team Contact to provide an interpretation. Could have a 
discussion, but can do the same.
… other solution is to have a vote to resolve the matter
… my worry is consistency among the councils

florian: Required to write it down, so at least precedence is documented

plh: Those are the two paths. I suggest instead of documenting in Process, 
document in Guidebook

<plh> fantasai: having the Team making the call makes more sense than doing a 
vote in the Council

<plh> ... will give more flexibility

<plh> ... and we should document in the guidebook

plh: Team would be having a conversation, not just making a decision.
… and will likely end up in Process or Guidebook issue, to document the 
question better

florian: I'm unconvinced that asking the Team will help
… but what if some members of the Council don't accept the Team's advice?
… However putting it in the Guide is a reasonable place to start.
… Not certain it provides enough gravitas, but might.
… if disagreements, then chair can decide what to do
… but either way, should document in the report
… But anyway, put it in the guide so it's not the chair making things up seems 
reasonable

plh: Regarding the Team, can only involve if it's about interpreting the Process.
… as it applies to operations of the Council.
… if it's about the material of the FO itself, then that's different

florian: Example is, FO against a decision. If you sustain the decision, it 
undoes the decision.
… but might not be clarity on what the decision is, or what the consequences 
of upholding vs overturning the FO means
… Council has a limited scope in what it can do

plh: Maybe Team is not seen as sufficiently neutral in some of these cases.

fantasai: I think the Team and the chair together would be sufficient for 
resolving questions about interpretations of the Process

plh: I would be OK with putting Team in the guidebook. Can make a 
recommendation to the Chair, and then it's a Chair Decision.

florian: Yes, let's just document that this is something you can decide about, 
and if you do mention it in the report

plh: Yeah, let's document this in the Guide

[dicussions about drafting Guide stuff]

RESOLUTION: Put something in the Guide
Tighten the how subtantive changes are handled post AC-Review

github: w3c/process#825

PR: w3c/process#910

florian: Practice isn't too far from this
… areas of difference are that if you increase the scope, you must go to AC
… also bring clarity about when people disagree with changes that are proposed 
after AC Review intended to resolve an objection
… most people happy with those changes, a few are not, then it's a weird situation
… people who disagree with the proposed changes can disagree without making an 
FO, and then what?
… what does that mean?
… can we overrule their non-formal objection?
… makes it clear that if you disagree, it counts as an FO, and existing 
Council gets to rule on it

TallTed: the "may only" phrasing, is usually restrictive
… to entirely clear if that's intended

florian: I intended a restriction. If you don't have consensus, you cannot adopt.

TallTed: then suggest "only if" instead of "may only"

florian: sure

plh: wfm

fantasai: wfm

[haggling over wording]

fantasai: For the second one, agree that it reads "better" in an absolute 
sence with it moved, but the reason it's pulled forward is to emphasize that 
phrase since the sentence is about this particular timing of the FO.

RESOLUTION: Accept PR with only in "may only" moved to "only if".
Issues to Discuss
Should member submissions be removed from the Process?

Github: w3c/process#648

florian: People complain that the Process is too long. Most of the text needs 
to be there, but some of it maybe can be removed.

florian: Member Submissions seem like that kind of thing.
… They don't need to be in the Process, really.
… Team could retain ability to put stuff on the W3C Website
… Putting these in the Process guarantees the right to make a Member Submission
… ~4 pages of text, seems like a lot for what it does

florian: Once upon a time, this was how you started work at W3C. But CGs 
largely make this redundant.
… One thing that makes Member Submissions interesting is that Members are 
required to say whether they would license relevant patents
… Not sure we need to keep this, suggest to delete this section.

plh: If we remove from Process, no longer guaranteed. Up to Team what they do 
about it.
… I would be ok with moving to Guide
… but would want to ask others about it

florian: We could simplify the section. Say that you can do this, Team says 
how you do it. The current formalism is very heavy
… there's a lot of formalism about it

plh: We would want to keep the formalism. We've had situations [missed]
… if it moves into Guide, becomes responsibility of the Team

plh: Member Submissions is a Member right, so unsure.

TallTed: my experience of Member Submissions is that historically they were a 
way to skip a level of incubation and proceed directly to a WG.
… not so much being used as a turf declaration, although that is an aspect of it
… Member Submission becomes a tacit admission that this is a valid way to 
handle a thing, rather than just spitballing
… I don't know that they're completely useful today given CG
… but also not sure they're entirely useless

ACTION: plh to ask around about removing Member Submissions

florian: The maintenance cost isn't very high. Mainly changed only by e.g. 
introduction of the Council
… but there's the cost on the readers, makes Process longer

fantasai: What if we move most of the formalism to Guide, and just keep the 
minimal bits in the Process
… like the patent commitments, and which decisions can be objected to, etc.

florian: Note that Member Submissions are mentioned in the Patent Policy

cwilso: I'm in favor of just dropping Member Submissions as a thing.
… don't seem to add anything over what you can do in a CG
… and despite the text saying that publication implies no endorsement, 
probably is taken that way

tantek: I have actually some experience with this
… when Social Web WG formed, there were a number of submissions by 
organizations offering in theme of "please base on this work / be compatible 
with this work"
… these submissions were all offered royalty-free
… none of those organizations participated in the WG
… the effect the submissions had was a whole bunch of IP that those 
submissions covered were given to the WG
… E.g. OpenSocial was submitted, it was huge across many companies
… idk if it impacted specs, but it gave people some level of confidence and 
less fear that the stuff we were designing / speccing would overlap with 
existing IP
… idk if that's worth keeping the whole section of Process, but that was a 
positive use of Member Submissions
… idk how often it occurs, but having Members who aren't interested in 
participating in WG but want to enable them to build on their work, it's useful

<plh> fantasai: we don't have to remove Member submissions. we could narrow it 
down to what really needs to be there and push the rest in the Guidebook

florian: so we keep that it exists, patent policy applies, any disagreements 
get kicked to council

<tantek> +1 fantasai, florian

plh: ok with me

plh: Sometimes easier to do a Member Submission than spin up / join CG
… for the purpose of providing IP

<tantek> +1 plh agreed, it was easier for these orgs to do the Member 
Submissions than join the IG/WG (and get review for that)

florian: OK, so we have an action item to replace the text with something 
minimal and push the rest to Guidebook

ACTION: florian and fantasai to create minimal Member Submissions section and 
push non-critical text to Guide

<plh> https://github.com/w3c/Guide/blob/main/process/member-submissions.html
TPAC

plh: No meetings scheduled for ProcessCG
… and no proposal for breakout so far. Could make one if you want.
… two breakouts relevant to us

Simplifying the Updatable REC Process

Registries for W3C Specifications

florian: Wrt simplifying updatable REC process, 3 buckets
… 1. not actually about Process. About improving tooling or practices
… 2. let's simplify steps in the Process, without changing end result
… e.g. like removing PR stage
… still have same requirements, just the path is a little different
… I think there's some amount of process we could make here
… but different from "look at how simple things could be if didn't need 
consensus" or "look how simple could be if we didn't need implementation 
experience"
… which would change what a REC is
… 3. simplifications we could make if we change properties of a REC, e.g. 
don't need consensus / horizontal review / patent protection / implementation 
experience
… no reason we can't explore that space, but don't disguise that as procedural 
adjustments

<plh> Simplifying the Updatable REC Process

plh: Thread on Chairs list about Charter Refinement Phase

Proposed W3C Process Change: Charter Refinement Phase

plh: we're going to trial this for CSSWG and ???

plh: Also [missed], which like CSS is huge, and new WG

<Zakim> tantek, you wanted to suggest if someone wants to discuss "How to make 
living standards work at W3C" since no one has gotten this right yet AFAIK

tantek: wrt TPAC ideas, could ask how to do living standards at W3C. Have yet 
to see it done in a way that works. E.g. charters try to do this, but have 
nonsense exit conditions, etc.

plh: see breakout about updateable REC

florian: There are a few small-scale successful applications. don't know about 
any large ones.

plh: agree we still need to prove we can do it successfully; that's what this 
session is about

tantek: simplifying process would be really boring

fantasai: breakout is about making updatable REC more workable, not about 
redesigning the Process

plh: I think we need to still learn from our current Process, and try to make 
it work

<TallTed> I'm very interested in the topic of living/evergreen standards 
and/or updatable recs. But must jump to next call.

plh: if we can't, then we can go back to drawing board

Meeting closed.
Summary of action items

     plh to ask around about removing Member Submissions
     florian and fantasai to create minimal Member Submissions section and 
push non-critical text to Guide

Summary of resolutions

     Merge
     Merge
     Put something in the Guide
     Accept PR with only in "may only" moved to "only if".

Minutes manually created (not a transcript), formatted by scribe.perl version 
229 (Thu Jul 25 08:38:54 2024 UTC).
Diagnostics

Succeeded: s/RESOLED/RESOLVED/

Succeeded: s/but [missed]/but when it happened to me as a chair of the 
council, I failed to unlock the situation without a rule to base that 
resolution on

Succeeded: s/Team says how you do it./Team says how you do it. The current 
formalism is very heavy

Maybe present: PR

All speakers: cwilso, fantasai, florian, plh, PR, TallTed, tantek

Active on IRC: cwilso, fantasai, florian, plh, TallTed, tantek

Received on Tuesday, 22 October 2024 22:48:52 UTC