Meeting minutes
Introductions and announcements
Re-chartering status: https://w3c.github.io/lws-wg-charter/
acoburn: Our first charter ended last week. We are currently in an administrative extension that runs until mid Janruary, giving us time to complete the next formal charter.
… In a recharter, there is a refinement of the charter - then a vote by all W3C AC reps on the new charter
… We need a minimum of 5% of all AC reps in favour
… Please contact AC reps you know to ask them to vote
… We also need to avoid formal objections
… To avoid formal objections, we should keep as close to the original charter which was already approved by the AC
… The refinement period has just started. It runs a minimum of 4 weeks.
… Following that will be the 4 week voting period. TPAC happens to occur during that period.
<acoburn> w3c/
acoburn: the above is a link to the formal charter. pchampin generated this by taking the existing charter and using automated tooling to update it - including with deliverables already completed.
… note that it is technically out of scope of this working group to work on this charter - though I expect everyone here to be interested in it.
… Other updates to the charter include noting that use-cases have now been developed, and that the thread model document is under development
<Zakim> elf-pavlik, you wanted to ask if publishing first implementation reports would be useful as a proof of WG progress
acoburn: please open PRs to modify the charter as required
elf-pavlik: There are 3 open source and 3 closed source implementations that I know of. Should we mention this in the charter or develop an implementation report which is referenced in the charter to show progress.
acoburn: Evidencing implementations is a plus. We should already have enough in a charter for it to pass. An implementation report would be a welcome addition.
elf-pavlik: So should the test suite task force prioritise developing an implementation report?
acoburn: Implementation reports are already on the agenda for later. Lets discuss then.
Discussion: TPAC agenda Issue#176
<jeremycaine> unfortunately I cannot join TPAC in-person
acoburn: TPAC is in 5 weeks, the final week of October. I will be there in person. Remote attendance is available. LWS has slots on Tuesday October 27 afternoon, and Thursday October 29 all day - Dublin time.
<elf-pavlik> I will join remotely, already registered, my application to W3C travel fund didn't make the cut
acoburn: we should have an agenda in advance of the session
<acoburn> w3c/
<gb> Issue 176 TPAC 2026 Agenda (by acoburn) [needs-discussion]
acoburn: the issue linked above is a draft of the agenda. Please add other topics there as you see fit.
… we should focus on what needs to happen between TPAC and LWS going into CR status
… This is also relevant to the re-charter. I suggest we want to go to CR status ~1 month after the new charter starts and Rec status after ~1 year.
<Zakim> elf-pavlik, you wanted to recomment not rushing CR without mostly complete impl reports
elf-pavlik: Cutting a CR and then implementing is an outdated W3C process. CR also ties our hands on how much we can change the spec. I would therefore suggest we do not rush going to CR; and try and get good implementation coverage and implementation reports first.
<elf-pavlik> I think we need to aim for a sweet spot with both dynamics in mind
acoburn: Generally the W3C process wants 1 year between CR and TR. CR is that point where we say to the world that we would like to invite people to create implementation. It is important that we broadcast that implementation request. We want to make sure not to push CR out too far that it jepodises us going into TR.
jeremycaine: If you are an implementor, do you know how to do both authentication & authorization?
acoburn: Authentication is covered. For authorisation we have access requests & grants defined. Authorisation is a moving target so we don't want to get detailed in the specification and box us into a corner as it could be outdated by the time we get to REC. All we talk about in the spec is how an Authorization server interacts, not a specific
… access control language. At the moment the access control language is an implementation decision.
jeremycaine: Does the charter need tightening to explain that?
acoburn: Open a PR if you think it does. Note that a charter doesn't need to be particularly detailed - that is what the spec is for.
<Zakim> elf-pavlik, you wanted to suggest that test suite and impl reports should clarify a lot of those questions
elf-pavlik: The test suite can also help unearth where gaps in the spec are - and where it lacks clarity.
Discussion: managing implementation reports PR#171
acoburn: We have an open pull request for tracking implementations.
… we have not clearly defined how we plan to manage implementation reports
… the current PR is just a markdown file listing high level details
… Can we get 171 merged and improve from there?
elf-pavlik: This is a first draft. I don't expect it to last long in this form.
… we can make it more granular, e.g., a matrix of which implementations support which requirements
… in time
jeswr: agree, let's get this nudged forward and then we can build out a more detailed report
acoburn: jeswr can you please make sure this gets merged
Discussion: moving resources between containers PR#237
jeswr: yes
<Zakim> elf-pavlik, you wanted to offer tl;dr of my feedback
laurens: There is feedback from elf-pavlik and @termontwouter that I have not yet addressed on 237
… There has been little feedback from others, please feedback ASAP if you have suggestions.
elf-pavlik: We need to tightly couple the normative requirements; i.e. if you advertise that you support moving, you MUST implement it.
laurens: Yes. I think we will need some refining and fine-tuning here.
<Zakim> acoburn, you wanted to ask if laurens has particular questions for the group to help move forward
laurens: I will have another go in the next couple of days
… My main question to the working group is whether the group requests
… changes to the current mechanism that is proposed and whether there
… are alternatives you would like explored
… if not I will bring this PR to reviewable status this week
acoburn: There are not many major features we have not yet added
Discussion: automated changelogs PR#243
acoburn: this is an important one to clarify before we go to CR status
acoburn: jeswr opened two editorial pull requests in the last week
… 243 is about adding a changelog.
jeswr: last meeting's discussion including having a changelog to help implementers
… this PR includes a diff of the spec using tooling presented by pchampin
… along with generative AI to be reviewed by editors
… question for the group: is a changelog needed, since the implementers seem to be in or close to the WG
<Zakim> gibsonf, you wanted to ask about LLM use
gibsonf: LLMs will potentially make a mess of things because they hallucinate
acoburn: Editor review can mitigate issues related to hallucination.
<gibsonf1> git diff is a good way to see changes
<Zakim> elf-pavlik, you wanted to mention that hopefully we'll be making a lot of changes to spec based on impl feedback
acoburn: To the "is it needed question" I think it is too early; and not overly useful since the implementors
… are in this group
elf-pavlik: I hope we will be making a lot of changes to the spec based on
… implementors feedback.
… For that reason I think it is good for implementors to track.
… The easier it is to track them and follow them. The better.
jeswr: two comments -- for Fred's comment, there will be an editor in the loop to address hallucinations
… to the question of "is it needed", I suggest that we wait until there is a flood of feedback
… once we start getting feedback that will be helpful
<elf-pavlik> SGTM
jeswr: the natural starting point would be when we reach CR status
acoburn: Having the starting point at CR status would be great.
Discussion: topic-based notifications PR#242
jeswr: idea from elf-pavlik -- different parts of spec have different experts
… those experts can be notified when there are relevant changes
acoburn: For this repository I just turn on watch so I get alerted to everything
… I do not find that to be overwhelming
… as a chair that is approrpiate for me
… the question is whether there is anyone in the group that
… finds watching overwhelming and would benefit from this
<Zakim> elf-pavlik, you wanted to tie it to experience from issue triage
elf-pavlik: I proposed this during issue triage. Notifications is one part of the problem.
… The second is about ownership in resolving issues.
… as some issues have been open for a long time
… and some are just open ended discussions
elf-pavlik: My end goal here is to make sure that
… people are comitted to moving issues forward
jeswr: code owners wasn't implemented since not everyone has write access to repo
… we could automate creating assignees for issues and PRs
elf-pavlik: Yes that sounds good alongside an issue template
… that lets someone specify the topic that an issue pertains to
acoburn: In other non-W3C repos I have seen a bot ping different users
… saying "this touches this extension of the codebase - X should look at it"
… if useful we could do that.
jeswr: I'll look into setting up the bot style approach
… and time-box as it is not high priority
Implementation Feedback
acoburn: We aim for this to be a recurring topic to give time
… for implementors to give feedback to the group
… is there anyone who would like to give feedback today?
… There seems to be no feedback for today.