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/
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?
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
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/
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/
PR: w3c/
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://
… 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://
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/
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/
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/
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/
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.