changed 10 months ago  
Linked with GitHub

W3C Solid Community Group: Weekly

Present

Announcements

Meeting Guidelines

  • W3C Solid Community Group Calendar.
  • W3C Solid Community Group Meeting Guidelines.
  • No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
  • Join queue to talk.
  • Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.

Participation and Code of Conduct

Scribes

  • Virginia Balseiro

Introductions

  • Willem: Work with TNO in the Netherlands. Currently exploring Solid. Getting up to speed with what it can do / future plans, build knowledge and actively participate.

Topics

  • SC: May only join briefly. Leaving some comments for FYI.

CG Charter Reports

URL: https://github.com/solid/specification/issues/587

  • SC: I have the CG-DRAFT ready but decided not to PR yet. Traveling today. I will do it this week in a calmer moment/space. More details will be in the PR, but quick FYI for now:
  • SC: CG-DRAFT conforms to CG Report Requirements.
  • SC: It also conforms to / be compatible with some of the W3C publication rules (without interfering with CG Report Requirements), so it should be even workable (First Public) Working Draft or later if/when we get there. I've already went through this publication process with specs in WGs.
  • SC: CG-DRAFT can be published at https://solidproject.org/TR/protocol , with a link to "This version" for the specific snapshot (i.e., Version 0.11.0, e.g., https://solidproject.org/TR/2024/{YYYYMMDD}-protocol).
  • SC: Once we get passed that publication, we can look into releasing CG-FINAL. I'd still like to encourage the Group to communicate with implementation experience, e.g., who is implementing or does not want to implement N3 Patch, ditto IRIs,…, which can be used to make another CG-DRAFT and/or towards the CG-FINAL.
  • SC: As for the Editor's Draft at https://solidproject.org/ED/protocol , that's also being updated to better clarify (e.g., in copyright, Status of this Document) that it is not a CG report and of course continue to not imply that W3C is endorsing it. The document will live on as is, and we can cut CG-DRAFT/FINAL(s) from it.
  • SC: Lastly, I will PR with some of the other documents listed under https://solidproject.org/TR/ along these lines.
  • IJ: We have the goal to ??? and avoid confusion with other documents. Two models. Model 1: any specification produced by a CG is subject to requirements for CG reports. A subclass is considered "not yet adopted" by the CG.. I see the use of ED, that might not be the best label. Benefit: IPR/authorship/ownership is clearly the CG and its participants. Model 2: these aren't CG reports until approved by the CG. Prior to that there areno markings/styling indicating that it's a CG report. Priot to that they should not be referred to as published CG reports. No W3C branding, just documents that will eventually be submitted.
  • eP: Is the intention all current drafts are CG drafts? We have work item process that people can start repos but once moved to Solid org they become community drafts. In WG there is WD and ??? We could have something similar. there are impleentations following the draft at different levels/versions.
  • IJ: Within CG reports there are two statuses: draft and final. Final is for improving patent policy coverage. If you have other labels you will have to educate the comunity on those. I have a slight preference for all being CG drafts until declared final. If these are all works of the CG they should be CG reports as opposed to external work.
  • TBL: Solid GH org follows the Solid process. TR contains documents that are not necessarily ??? If we don't have the 'final' flag ???
  • IJ: I'd rather not entertain the proposal to map CG process to Solid Team? process. I don't want to change Solid process, just find a way to label it within the CG process. FINAL is optional, not required. Status within the CG system can be comunicated.
  • eP: I think it is sufficent to have everything use the template. We can use semantic versioning and some kind of tag releases. About FINAL: keeping in mind there's a WG proposed, we plan to submit some of the CG drafts, not all. Some will continue to be within CG. Those should be tagged as FINAL? And when is it a good time in coordination with the WG?
  • IJ: The two can be decoupled. If the charter is being reviewed, it should set expectations as to which deliverables will be picked up. The transfer happens whenever both parties are ready. FINAL is advised but not required.
  • TBL: Is it FINAL when the WG picks it up?
  • IJ: When it hits the WG the policy is that every participant maes a full commitment over the text of the spec. Anyone in the WG that was also in the CG, it's not that relevant because they don't need to make the same commitment. It is relevant when someone has been in the CG but hasn't made commitment over the full text and doesn't join the WG..
  • TBL: You mean contributed IP?
  • IJ: If you have been a signifcant contributor ??? those who have contributed a lot to the spec but not joined the WG ??? At any time you can ask those people to make a final comitment.
  • TBL: If you label something as FINAL can it not be changed?
  • IJ: You can continue to edit drafts. The purpose is for IPR but doesn't need to signal it is "done".
  • eP: By joining the CG one makes the contribution agreement. For FINAL is there a step?
  • IJ: If you're a chair there's a button to publish documents. When you push you have option to publish a draft. Second button for final specs. Those specs need to be at least mirrored on w3.org. That is announced to CG, automatic email calling for commitments and all participants can go and record their final spec commitments.
  • eP: The drafts we think are fitting for WG, if we mark them as final, and then the WG doesn't pick all of them, should CG cotinue working as FINAL or move back?
  • IJ: You'll have a snapshot of a document labeled as final and you can also have in your system a draft that you're working on.
  • VB: summarizes SC's update
  • TBL: ???
  • PAC: Solid Protocol is listed. We list dependencies that are important for it. Some are condiitonal to progress and maturity ut will posssibly be adopted.
  • TBL: All to do with Solid protocol, no client to client specs.
  • PAC: Right.
  • eP: Responding to SC: he mentioned thinking to equivalent WD-ED, he proposed having WD > CG-DRAFT and ED just be not a CG-DRAFT.
  • IJ: there's a risk of terminology confusion. I'd avoid using the terms WD and so forth. /TR already brings reactions of what it is claiming.
  • PAC: As an example, in ??? we use ED which is not generally considered part of W3C terminology for living documents automatically published on GH, and CG-DRAFT.. which aligns to Solid CG current practice. That's what eP was suggesting.
  • IJ: An ED that is not a CG report should not have any W3C markings.
  • TBL: Version number of the spec is independent of the level of review.
  • RG: I published an ED, which seems a generic term, removed W3C and not put a licence.. when it was adopted we brought in license and logo.
  • IJ: Documents that are not yet in the CG and brought in for discussion, whatever process the CG has for accepting documents, that should include updating the styles and branding of whatever the pre-CG materials were. I'd call them pre-CG, not ED. ED does not communicate clearly what to expect.

CG Calendar Feedback

  • VB: During SoSy I received feedback about bringing back calendar notifications, in addition to the calendar not being consistently up to date, which harms participation. Related: https://github.com/w3c-cg/solid/issues/20

STM Security Best Practices

URL: https://github.com/orgs/solid/projects/16

  • VB: Scheduled for May 21st
  • eP: I'll post in relevant issues, but HZ, AC, Otto could maybe join the meeting?

Solid CG meeting at TPAC 2024

  • VB: Proposed by PAC
  • PAC: LAst TPAC CG meeting was a success. It'd be great to have it. Not convenient for everyone but we can aim for hybrid. We have until the 20th to indicate whether we want to.
  • TBL: Maybe we should have two: internal and external.
  • PAC: What you describe is abreakout session. We can have that for more open and focused ? meeting. Im planning to ask for the slot for Linked Web Storage WG.

STM Notifications on non-taken slots

  • RG: I'd like to take up non-taken slots for notifications.
  • VB: Announce few days before so people know. Add to board.

WG charter

Coordination with the Federated Identity Working Group

URL https://github.com/solid/solid-wg-charter/issues/77

  • AC: Some feedback from AC suggested we should be coordinating with Fed CM.. somehow didn't make t to the list. We should mention the WG.
  • VB: Can we PR?
  • PAC: Yes.
  • AC: I can make that PR. In coordination we list Web Platform incubator.. FedCM is listed there. Not sure if I should reproduce that or remove from Web Platform..
  • PAC: If the only item is about federated credential management probably makes more sense to replace this with FedCM. Unless we have anything else, we can replace.
  • AC: There's also Linked Web Storage.
  • PAC: That's us.

ACTION: AC to PR adding coordination with Federated Itentity WG.

Strategy for making breaking changes

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

  • eP: we need to clearly communicate it to implementers and work with them to go throgh needed breaking changes
  • eP: nothing stops us from already working on rollout/sunset strategy that later can be used for major versions

Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.

Select a repo