Minutes: W3C Process CG Telecon 24 April 2024

Summary of Resolutions:

   * Close issue 456: W3C Glossary
     https://github.com/w3c/w3process/issues/456#issuecomment-2065824197

   * Close issue 481: Whistleblower Policy
     https://github.com/w3c/w3process/issues/481#issuecomment-2065834813

   * Close issue 582 / transfer part to AB: Representing W3C
     https://github.com/w3c/w3process/issues/582#issuecomment-2065876479

   * Adopt PR 819: Consistency of Maturity Stages wrt placement of "Draft"
     https://github.com/w3c/w3process/pull/819

   * Accept PR 857 to delete "Streamlined Publication Approval"
     https://github.com/w3c/w3process/pull/857

   * Merge PR 837 to clarify "each" in TAG appointment ratification
     https://github.com/w3c/w3process/pull/837

   * Merge PR 841 to disambiguate vote thresholds
     https://github.com/w3c/w3process/pull/841/files

   * Merge PR 842 to disambiguate vote thresholds
     https://github.com/w3c/w3process/pull/841/files

   * Close issue 838, open separate issue wrt TAG appointment
     https://github.com/w3c/w3process/pull/841/files

   * Adopt PR 850: Editorial Rewrite of Charter Approval
     https://github.com/w3c/w3process/pull/850/files

Full minutes: https://www.w3.org/2024/04/24-w3process-minutes.html

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

Contents

     Issues to Close
         Team updating Notes
         W3C Glossary
         Whistleblower Policy
         Representing the W3C
     Pull Requests to Review
         Consistency of Maturity Stages wrt placement of "Draft"
         Retire "Streamlined Publication Approval"
         Disambiguate "each" in TAG appointment ratification
         Disambiguate vote thresholds
         Editorial Rewrite of Charter Approval
     Charter Review Process
     End
     Summary of resolutions

Meeting minutes
Issues to Close
Team updating Notes

github: w3c/w3process#120 (comment)

florian: Since issue, we made some changes
… Team can do Class 1 edits (markup fixes)
… also can annotate proposed changes
… can't fold in directly, but can say that once a WG is created expect to make 
these changes, or whatever
… Issue seems to be addressed; if we want more could open a follow-up later

plh: Team can make Class 2 changes in REC that has no WG
… [quotes Process]
… but for a Note, how do we differentiate editorial vs substantive?

florian: Old definition of the classes of changes didn't help, but we updated that

plh: If we have a definition that works for NOTEs, then we should make REC and 
NOTE match
… if can make editorial edits to REC, why not NOTE
… though in practice, Team is unlikely to make any edits on its own to a REC

florian: [quotes spec]

https://www.w3.org/2023/Process-20231103/#correction-classes

florian: So your proposal is to update ability of Team to match REC

plh: or downgrade to match

plh: so far haven't needed to, unless there's a group behind it

florian: If didn't have ability to mark proposed changes, wouldn't be enough
… but given that, is it not enough?

plh: I can imagine it, but unlikely without a responsible group
… don't think we should give wildcard to Team to make substantive change to notes
… idk how to do in NOTEs

florian: we can do the same as REC amendments in NOTEs

plh: but we can leave substantive changes to another day, not much motivation atm

fantasai: if not closing issue, let's move on, lots of stuff on agenda
W3C Glossary

github: w3c/w3process#456 (comment)

florian: Not great, but it exists and AB can publish as a NOTE
… propose to close the issue, file follow-up against the AB

plh: makes sense to me
… covers only Patent Policy and Process?

florian: It has a few parts, automated pull from Process and Patent Policy
… also two manual sections, one where we link to relevant terms defined elsewhere
… not every term in W3C, but ones that are widely relevant
… and terms that are widely relevant but not defined elsewhere, can add into 
glossary
… not good enough yet, but framework is there

plh: agree to close issue
… anyone else?

<fantasai> +1

RESOLUTION: Close issue 456
Whistleblower Policy

github: w3c/w3process#481 (comment)

florian: We previously wanted to transfer issue to Board, but they already 
adopted a policy so nothing to transfer
… if their policy isn't good enough, should file issue against them

plh: +1

<fantasai> +1

<cpn> +1

RESOLUTION: Close 481
Representing the W3C

florian: Broad issue, we solved the part that fits into Process
… when Membership wants to make a collective statement, we have Statement track
… however issue also concerns with other thing, can the Team make a statement 
on behalf of W3C on smaller matters
… in a timely manner
… we haven't addressed this, but not in-scope for Process
… there's an existing policy; probably needs updating, but not in scope for 
this group
… so for us, we're done; and the rest is for someone else

plh: agreed

florian: rest should probably be addressed by CEO with advice of AB
… probably too detailed for the Board

plh: but in any case not here

<cpn> +1 to leaving to CEO + AB

<plh> +1

<fantasai> +1

RESOLUTION: Close issue / transfer part to AB
Pull Requests to Review
Consistency of Maturity Stages wrt placement of "Draft"

github: w3c/w3process#779 (comment)

florian: We narrowed to 2 options, and took a poll. 8 in favor of adopting, 1 
in favor of doing nothing
… ChrisN, do you object to adopting? Preference seems clearly the other way 
around.

cpn: Mildly dislike. "Note Draft" reads awkwardly, and I'm OK with the word 
being in different places. But won't object.

florian: I think 8-1 and no objection means we do it

plh: unsure what it means for our publication system

florian: We're not changing many of them
… and not adopting just yet
… if it's a major challenge for systeam can reopen

plh: ok, lets agree to adopt, and I'll fyi to webmaster

RESOLUTION: Adopt PR 819

w3c/w3process#819
Retire "Streamlined Publication Approval"

github: w3c/w3process#856

w3c/w3process#857

florian: When we did Process 2020, we tried to make some transition requests 
easier because at the time it took a long time
… we introduced a stricter path in the Process, that doesn't require the 
Director's decision
… but nobody used this

fantasai: also we streamlined getting manual approval a lot

florian: overall REC track is long and complicated, this chapter doesn't help 
much and just confuses people
… suggestion is to delete

<fantasai> +1

<cpn> +1

plh: +1

RESOLUTION: Accept PR 857 to delete "Streamlined Publication Approval"
Disambiguate "each" in TAG appointment ratification

github: w3c/w3process#836

w3c/w3process#837

florian: Clarified that original intent was AB and TAG separately ratify
… we wanted to clarify in the Process to avoid confusion on that point
… there's also some other questions about TAG appointments, but to answer 
narrow question of clarifying this original intent
… this phrasing seems to work, so let's merge it and keep discussing the rest 
separately

plh: sgtm

<fantasai> +1

plh: objections?

<cpn> +1

RESOLUTION: Merge PR 837 to clarify "each"
Disambiguate vote thresholds

github: w3c/w3process#838

https://github.com/w3c/w3process/pull/841/files

https://github.com/w3c/w3process/pull/842/files

florian: Process discusses various votes, passing by majority or supermajority
… identified 4 ambiguities
… I landed the first one based on previous call
… 2nd one is about TAG, come back to it later
… 3rd and 4th we agreed on what we mean, and I made 2 PRs to address
… 3rd about Council dismissal, 4th about Council decision votes

<fantasai> +1

plh: objections to 841?

RESOLUTION: Merge PR 841

florian: [introduces 842]

plh: objections to merge?

RESOLUTION: Merge PR 842

florian: With these merged, the only thing remaining is about the TAG. I 
suggest we spin out into a separate issue and close.
… that conversation is complicated, better in a separate plae

plh: +1

<fantasai> +1

<TallTed> +1

RESOLUTION: Close issue 838, open separate issue wrt TAG appointment
Editorial Rewrite of Charter Approval

github: w3c/w3process#850

florian: As fantasai and I were working on revision of Charter 
development/review, we found the existing section to be poorly written
… so this is just to rewrite editorially to make easier to read and follow

/github.com/w3c/w3process/pull/842/files///github.com/w3c/w3process/pull/850/files

plh: There are some changes to active charter that don't require AC review

florian: That's still there, just moved it
… original text mixed these up a lot, so we made subsections

fantasai: This is probably easier to review ith the text side by side rather 
than diff view, because we basically rewrote it

[use the gear icon to get split view, instead of unified]

POLL: Approve change?

<fantasai> +1

<plh> +1

<florian_irc> +1

<TallTed> +1

<cpn> +1

<joshco> abstain

RESOLUTION: Adopt PR 850
Charter Review Process

github: w3c/w3process#580

https://github.com/w3c/w3process/pull/851/files

florian: We've been discussing several months
… currently it's informal, but this formalizes it
… creates a formally identified phase (calling "charter refinement" currently)
… to start it, is a Team Decision -- so can object
… and has a Facilitator (Chair) to drive progress
… progress requires wide review, addressing issues, etc.
… and then decision to take to AC Review
… if anyone files an FO prior to AC Review, we group that objection with the 
AC Review FOs, so the Council can address everything together
… (this is something we learned from experience)

plh: Looking at "Advance Notice" requirement, a few things not comfortable
… 1st is to identify location of charter draft which must be public
… means we can't do anything if we're thinking about this, but don't have 
draft yet

florian: We're using the term 'Advance Notice" for the start of this new 
phase. But if we want an earlier notice... we can have two different words
… which one is called 'Advance Review Notes' ... probably it's this one 
because can't "review" if nothing to "review"
… but making a notice "we're thinking about a charter, come talk to us" is 
also fine

plh: Today we have two phases
… 1. We're working on a charter, should tell AC about it
… 2. We have a draft, and asking ppl to review it
… horizontal review, etc.
… which one is it?

florian: in between. You might not have a completed draft, but you have something
… you could have a mostly blank draft, but probably premature

plh: had an AC meeting session on identity, trying to evaluate whether to look 
into it
… sent advance notice about working on a charter
… and some of us spent some time working on a draft
… then went around asking for comments
… hoping to start AC Review in May

florian: I think at the end of these two days, you would have sent the Advance 
Review Notice saying "we have a thing, want ppl to work with us to make it ready"

<florian_irc> fantasai: the point of this notice to to provide more structure

<florian_irc> fantasai: if we're in a hazy phase where we don't really need 
formal feedback because there's no controversy, or because you don't yet know 
what you're doing, it's too early

<florian_irc> fantasai: but if you have put a draft together, or if you're 
having trouble putting a draft together because of controversy…

<florian_irc> fantasai: then having this phase with formal helps, thanks to 
formal chairing

plh: I like that, but the proposal removes requirement on Team to tell AC that 
they're working on a charter
… we often can send draft, but some cases where we know the WG is talking 
about a charter and basically send a signal to AC to say, there are 
conversations happening over there
… not sure that's a good thing or bad thing

cpn: Another benefit in this earlier review
… when charters get to AC Review, you have a community very invested in the 
charter
… if objections from AC, better to bring up earlier
… so in general supportive of any effort to bring concerns earlier
… in addition to other benefits described

cpn: wrt your concerns of Advance Notice, anything stopping from doing both 
things?
… you can send an early notification that working on a charter, and another 
that it's time for wider review

plh: nothing stopping us other than maybe concern about too many emails to AC
… a little uncomfortable about removing requirement on staff about this early 
notification

florian_irc: Not removing requirement on Team to communicate, just shifts timing
… if Team is wondering whether it should try to write a draft, want to ask 
feedback, send a notice
… but if you already know, then just start it and announce the draft
… if you anticipate that what you draft will be controversial, make a draft 
with lots of "fill in the blank" and send the notice earlier to ask for help

cpn: I think I'd prefer to keep the requirement for earlier advance notice
… even if that means multiple notifications
… uncomfortable about later in the phase only

<florian_irc> fantasai: I don't have a strong feeling either way on the 
earlier notice

<florian_irc> fantasai: we can keep that req if people want it

<florian_irc> fantasai: if that's too much traffic, we can set up a separate 
mailing list that people can subscribe to

<florian_irc> fantasai: we can also kick that question to the AB or AC

plh: I don't have strong feelings either, want to hear from AC
… if early notice and advance notice coincide because we receive a charter 
that's fairly complete, can merge into one

florian_irc: if we go this way, I suggest we amend PR to include both
… that way we can have stable names for them
… and then include a provision that says if they happen at the same time, can 
send one mail

plh: corner case, Verifiable Credentials has been discussing their charter
… only change is, reason they do rechartering because can't extend more than 6 
months
… and that requires an AC Review
… so nothing much changed, and here in this advance review notice, expected 
duration for phase is 28 days
… so basically before 28 days of AC review, force 28 days of pre-review
… most cases it's fine, but some cases where nothing changed in the charter
… corner case, idk if we care enough

florian_irc: 6-month limit, is that good practice or basis in the Process?

plh: might be good practice, maybe W3M committed to AC
… AC didn't like e.g. 2-year extensions

florian_irc: should this be in the Process?
… we could say charter extension is by Team Decision, but longer than six 
months requires AC Review
… [missed]

fantasai: How about just if it's under the Team Decision scope of minor 
decisions, then Team MAY request AC Review (and then doesn't require the 
28-day wide review phase)

florian_irc: could do that, and if later want to forbid Team from e.g. longer 
extensions then can request a separate change

fantasai: At Time

florian_irc: ok, I'll make adjustments and we'll come back to it
End

Meeting closed.
Summary of resolutions

     Close issue 456
     Close 481
     Close issue / transfer part to AB
     Adopt PR 819
     Accept PR 857 to delete "Streamlined Publication Approval"
     Merge PR 837 to clarify "each"
     Merge PR 841
     Merge PR 842
     Close issue 838, open separate issue wrt TAG appointment
     Adopt PR 850

Minutes manually created (not a transcript), formatted by scribe.perl version 
221 (Fri Jul 21 14:01:30 2023 UTC).
Diagnostics

Succeeded: s/github: Consistency of Maturity Stages wrt placement of "Draft"//

Warning: ‘s/-> https://github.com/w3c/w3process/pull/842/files//’ interpreted 
as replacing ‘-> https:’ by ‘/github.com/w3c/w3process/pull/842/files/’

Succeeded: s/-> https://github.com/w3c/w3process/pull/842/files//

Succeeded: s|-> https://github.com/w3c/w3process/pull/842/files||

Maybe present: cpn, fantasai, florian, florian_irc, plh, POLL

All speakers: cpn, fantasai, florian, florian_irc, plh, POLL

Active on IRC: cpn, fantasai, florian_irc, joshco, plh, TallTed

Received on Tuesday, 7 May 2024 05:30:50 UTC