Meeting minutes
Propose to Close
<Brent> https://
Brent: let's see if anyone left a comment after these were marked 'propose to close'
… 1033, no comments
… 414, no comments
… 409, has comments, from florian & TallTed
TallTed: every group type that exists should be covered in the process.
… i don't have any particular thought about what to say about them. sketch in my comment: "these group types aren't discussed more here, because they're defined elsewhere. we may define them here in the future"
Brent: another option, we could incorporate the BG/CG process document by reference
… maybe someone knows the historical context
plh: CGs were created so anyone coming to us with an idea can quickly form a community around it without going through any kind of vetting process.
… very minimialist; some have resisted adding it to the process because it could become more heavyweight over time
… Ian and Dom are working on revising this
… any attempts at making CGs more complicated would face resistance
… that's why it's not in the process doc today
<Brent> w3c/
Brent: i don't think we should add anything to this process that isn't in the CG process
<Brent> Github: w3c/
plh: maybe we could say "if you have a new idea, go make/join a CG"
… BGs aren't used as much these days
tidoust: the process introduction mentions BGs and CGs
… it may be worth having something about incubation in general
… i wouldn't want the process to start describing how CGs operate
w3c/process#328
Brent: i don't think anyone here wants to make anything more complex
… 328, no comments
… after this call, we're going to close 1033, 414, and 328
plh: re: 328, tooling should create an issue in the AB-memberonly repo whenever a charter goes out for review
… haven't fixed it because the AB hasn't left many comments
… if the AB wants to reconsider that, just let me know
Brent: okay
… opening an issue on the AB github repository probably wouldn't result in action; our work more isn't very github-centric
Agenda+
Brent: anybody at any time can add 'agenda+' to any issue or PR
<Brent> Github: w3c/
Brent: only thing we have on agenda+ is issue 442
… "Need a Policy for Submission Requests"
… any comments?
… was proposed to transfer this issue at some point
plh: was raised during AC review of the process doc in 2020
… this issue was raised before member submissions got simplified
… they're rare, so fantasai suggested we could move this to the guide
… the team can reject a submission because it's harmful to the web
… issue raised in 2020 was that the team held this power exclusively
… but these days we've published principles as statements
… the team is bound by those
… so i don't think there's any action needed here
Brent: okay, let's add 'propose to close' to this one
<plh>
Brent: and we'll close after the call
plh: i don't believe the team has rejected any member submissions in quite some time. this is a hypothetical concern.
Issue Triage
<Brent> https://
Brent: LRU order for triage
… is there something for this group to do? if so, do we have the info we need? if not, should this be transferred elsewhere or closed?
w3c/process#1007
<Brent> Github: w3c/
raised on March 26th
… single comment, from something cwilso raised elsewhere
… many references to this from other discussions
… 3 merged PRs related to this
… maybe we can close
plh: i don't think we have such a thing in the process
hober: it's part of the AB/TAG discipline work
Brent: all of the related issues were merged into a single branch
… my suggestion is that it's already labeled with the branch, so it's already triaged
hober: that works for me
w3c/process#553
<Brent> Github:
<Brent> Github: w3c/
Brent: raised in 2021; no comments since then
… no activity since
… is this still an issue?
plh: this hasn't crossed my radar much
… no group came to me to say this was unclear
… that said, the issue is useful
… some iteration is possible here
… maybe resulting in changes to the Guide
… hopefully no process changes would be required
hober: so should we transfer this to the guide?
plh: not yet
… alan's numbered list in the issue should be added to the guidance for moving things to cr snapshot
Brent: that's a good idea
plh: it could go into the "transition guidance" document
… which no one reads :(
… ylafon and i try to catch these sorts of things
… i've assigned the issue to myself
Brent: okay, let's transfer the issue
… done
w3c/process#554
<Brent> Github: w3c/
Brent: raised by mnot 4 years ago
… editorial suggestion
… conversation died down 4 years ago
… sounds in line with the refactoring we want to do anyway
… also happy to close; we may not need to track it
hober: i'd prefer to keep it open
Brent: i could create a 'refactoring' label
hober: okay!
plh: previous editor chose to keep the current organization, so this is unlikely to change until new editor in place
w3c/process#589
<Brent> Github: w3c/
Brent: raised by manu
… says the "revising a recommendation" process is painful
… this is true
plh: indeed
Brent: this is in line with the kind of feedback we're looking to gather at tpac
hober: let's add your new label to it
plh: should this be marked as a priority item?
Brent: we're waiting on the AB to tell us what our priorities are
… the triage point is that it's possible this is useful, so we should keep it open
plh: this is a hot issue. devices & sensors and webapps are going back and forth on this re: their joint deliverables
w3c/process#561
<Brent> Github: w3c/
Brent: should the process CG exist?
… florian and i have been doing some triage. anything that says "needs ab feedback", we think about if we should transfer it
… that label was added 4 years ago
… has that feedback even been received
hober: okay to transfer this to the AB
Brent: it's the AB's decision to make anyway
… let's transfer it
… will transfer it to AB-public if that's okay
plh: sounds good to me
… thinking on this has evolved since the label got added
… +1 to transferring it
w3c/process#555
<Brent> Github: w3c/
Brent: editorial issue raised by mnot back in 2021
plh: did we change this in the recent process?
tidoust: the sentence is still there
plh: it's still an issue
… we should at least drop the second half of the sentence
Brent: okay, let's keep it open
plh: we have the vision, so it should be easy to update the text
w3c/process#604
<Brent> Github: w3c/
Brent: raised by cwilso in 2022 from a suggestion from tantek
… lively conversation back then
… a couple of years later, thought was that we need feedback from the AB
… should we close, transfer, or leave it open?
hober: i think the underlying problem is real. we should transfer it to the AB
plh: not sure transfering is the best approach
… in practice, this hasn't been an issue
… no one's used an AC appeal in a long time
… if it gets moved to the AB, it'll stay open
… i guess i don't mind parking the issue with the AB
Brent: any objections to transferring?
… hearing none, transferred
w3c/process#597
<Brent> Github: w3c/
hober: i'm quite sympathetic to the issue as raised
Brent: sounds like it should remain open
… is the registries guidance in the process sufficient
<plh> hober: not sure if the issue should be transferred to the AB as part of overall
hober: this issue is a symptom of the larger AB issue re: interoperabilty
… dunno if we should transfer or keep open ourselves
plh: also a registry issue in fedid
… how many requirements should be put on registries
… we shouldn't be surprised if registry issues come back to us
hober: maybe we need a "3 Is" label for this one
plh: agreed
Brent: we'll create a new label and keep this issue
… the VCWG hasn't created a registry
… i'm happy that the work was able to continue and successfully result in 2.0
w3c/process#625
<Brent> Github: w3c/
<plh> hober: reminded of the difficulties around resolving objections in HTML. their interpretation of weakest was not a measure of forcefulness, it was a measure of harm.
<plh> ... I'm inclined to say it's an issue, and update the text
Brent: next meeting was scheduled for duing tpac, so we won't be meeting then
plh: there will be a chairs' breakfast thursday morning at tpac
… we will encourage them to give feedback on the process