# W3C Solid Community Group: Weekly

* Date: 2024-06-05T14:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://matrix.to/#/#solid_specification:gitter.im
* Repository: https://github.com/solid/specification
* Status: Draft

## Present
* [Virginia Balseiro](https://virginiabalseiro.com/#me)
* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
* [Sarven Capadisli](https://csarven.ca/#i)
* Grace Elcock
* Hadrian Zbarcea
* Gioberto C
* Jeff Zucker
* Rahul Gupta
* [Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/))
* Sungpil Shin
* John Kirkwood
* Jesse Wright

## Announcements

### Meeting Guidelines
* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
* [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
* 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
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/).
* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.
* If this is your first time, welcome! please introduce yourself.

### Scribes
* Sarven Capadisli

### Introductions

* GC: Scuola superiore Sant' Ana University https://www.santannapisa.it/en. Working on data portability related ot my PhD dissertation.

---

## Topics

### Solid CG meeting at TPAC

> ACTION: VB to respond to request with earliest time on Tuesday.

* VB: Some people have conflicts for Tuesday. Would Monday 23 September: 09:00 - 10:30 PDT (16:00 - 17:30 UTC) work for everyone?
* VB: Will send out request by Friday.
* VB: Probably a hybrid event.
* VB: If no objections, will submit request for 2024-09-23T16:00:00Z with estimate of 25 people attending.

#### Re Solid CG meeting at TPAC 2024 possibility and format
URL: https://github.com/solid/specification/blob/main/meetings/2024-05-29.md#solid-cg-meeting-at-tpac

* SC: Just want to note that all Solid CG meetings at TPAC were originally intended to be hybrid meetings or at minimum online in order to be most accessible: [TPAC 2021](https://github.com/solid/specification/blob/main/meetings/2021-10-27.md), [TPAC 2022](https://github.com/solid/specification/blob/main/meetings/2022-09-14.md), and including [TPAC 2023](https://github.com/solid/specification/blob/main/meetings/2023-09-11.md). The idea has always been to have some presence at TPAC. If those attending in person want to have a room, that's great.

### CG-DRAFTs published

* VB:
* https://solidproject.org/TR/2024/protocol-20240512
* https://solidproject.org/TR/2024/wac-20240512
* https://solidproject.org/TR/2024/notifications-protocol-20240512
* https://solidproject.org/ED/qa
* https://solid.github.io/webid-profile/
* VB: Announced at https://lists.w3.org/Archives/Public/public-solid/2024Jun/0001.html , https://lists.w3.org/Archives/Public/public-solid/2024Jun/0005.html
* SC: For fun and profit: https://solidproject.org/TR/?graph=https://solidproject.org/TR/protocol&graph=https://solidproject.org/TR/wac&graph=https://solidproject.org/TR/notifications-protocol&graph=https://solidproject.org/ED/qa&graph=https://solid.github.io/webid-profile/&graph=https://solidproject.org/TR/
* VB: Shoutout to SC for doing this work!
* SC: Shoutout to hobbyists in the community for making this happen. :) We move things based on shared knowledge, in the form of implementation experience, feedback, advancing the specs. If it's here, it's helping the standards; if not, it's not.
* SC: *screen shares graph*
* eP: You've mentioned test coverage. Is there a way to see a list with greens and reds?
* SC: We don't have it, yet; only a bit of that. We have a graph represented by RDFa. *shares screen* https://solid-contrib.github.io/specification-tests/coverage

### Please review CG Report requirements
URL: https://github.com/solid/specification/issues/587

* SC: There's an issue Ian created. In the context of W3C CG, W3C has only one way of communicating these reports. They're called CG-DRAFT / CG-FINAL.
* SC: https://www.w3.org/standards/types/#reports
* SC: Table has types of documents for different groups, etc. CG can only publish CG-DRAFT. Not clear at W3C (not just about Solid), groups use different tools and sometimes use Editor's Draft, Unofficial Draft, etc., based on tool configs. Part of the confusion as to why we have different documents like ED. Raised it to W3C Team, asking for clarification on what we're allowed to use. Somewhat clear that we cannot use ED, because ED belongs to certain types of groups called "W3C Group", which does not include "W3C Community Groups". Asked for clarification in [the issue](https://github.com/w3c/tr-pages/issues/102) and created PR, they will have to follow up.
* SC: We have to either express documents as CG-DRAFT, or we say these documents should not say they are produced by W3C CG. Downplay, remove logo, say it's prepared by the CG. They seem okay with the idea we have a CG-DRAFT, ED pushed out there removes all W3C markings. As long as that's okay, they are happy with that. For all our reports, we need to shift toward CG draft or something not implying CG. Solid QA and WebID Profile in particular only have one version. We don't have one version for CG-DRAFT and one for ED. But Solid Notificatons, Solid Protocol, WAC, have both things: CG-DRAFT and working right now on ED. We need to decide if we need these two other documents (WebID Profile and QA) to also have ED, or commit to CG-DRAFT.
* RG: Thanks for raising this. Asked last week. Reading from the definitions why W3C Group excludes CG. Nice that you raised it. Having "W3C" being removed from the CG work seems strange, I do not agree with complete removal of W3C branding.
* eP: https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fsolidproject.org%2FTR%2Fprotocol&doc2=https%3A%2F%2Fsolidproject.org%2FED%2Fprotocol . I think this is unnecessary complexity. The way I'd like to work on drafts I'm working on. So everything is CG-DRAFT. Later we can talk about CG-FINAL. The Editor's Draft is informal way of working / referring to the HEAD of the branch. Other than that, it doesn't change anything. We don't cut a release. This one is just the current version and the latest published version is pretty much showing that. I'd just like to use the CG-DRAFT and don't touch the version numbers.
* SC: The CG-DRAFT could be anywhere. CG-FINAL would have a copy on w3.org.
* eP: Timestamps we could publish on solidproject.
* SC: Can you share two different links? Distinguishing between CG-DRAFT and the one pointing at the head of the branch
* eP: Looks the same, just different URLs.
* SC: That's what we have right now with ED/qa and Solid WebID Profile. Historical reason: TR pages was the only thing out there that was "published" and versioned.
* JK: My understanding was that the WG charter that needs potentially approval by the AC to become a WG.
* SC: There's a W3C community and that includes AC as one group that needs to review. The WG would take the Solid protocol as one of the input documents, and other specs. If deliverables change it might need another set of reviews. If the group wants to work on other specs, they can be proposed. In CG we incubate this work and put it out there for WG to continue some parts of the work. There's tst suites, exit criteria.. etc.
* JZ: Want some clarity on the two drafts situation. If I understand eP, there'd be an HTML version of the CG-DRAFT. That wouldn't gt PRs. PRs would go to the head of the branch. And that this would be ready to push up to WG. Is that what you're proposing?
* eP: No, everything is worked under CG. The current main branch on a repo is the CG-DRAFT. Every now and then we have a tag release. Everything is being worked on as CG work and auto-versioning.
* JZ: I'm asking how many versions there are going to be and which would get a PR. If I want to change the WebID Profile, there is one document, and submit a PR if accepted it gets changed. This is now ready to become as labelled as CG-DRAFT, it'd then automatically generated?
* eP: Workflow is the same. We make PRs against main branch of the repo. I'd like to use same boilerplate for both.
* RG: To eP's suggestion, my understanding from the definitions is that ED has a label, and it may not involve everyone's agreement. Is that after the process. Are we good to release as a versioned thing? Therefore that distinction makes sense to me.
* SC: W3C ED is not for CGs. We should not say it's a W3C ED. We can of course call it an ED in ED/ .. but ED should not use the graphics, labels etc. saying it's a W3C things.
* SC: We canot have a document saying it's a CG report and ??? how many times it gets published is not important. We can do what eP says and keep updating. As long as we have consensus. In contributingguidelines there's a section about decisions. Leans on W3C process around what kind of correction class is being made. Some things are editorial changes, some are subtantial changes. There are guidelines for each category: use best judgement for editorial, for substantial must make a PR and regular process like getting approval, etc. I wouldn't worry too much about things getting through PR and updated. We don't need a special ceremony to ake a new release. W3C does not expect it. If you make a PR in Solid WebID profile and we agree to merge, just update version number in the PR and that's enough.
* JZ: In both version? GH and action would change CG-DRAFT?
* SC: Yes.
* eP: My suggestion is to completely avoid ED terminology.
* SC: That can work, but we have snapshots so we can refer to them. What you describe is a latest living standard and it's versioned but there wouldn't be a clear way for any impleentation to refer to the published document.
* eP: We should make a tagged release which are snapshots.
* SC: Separate HTML document?
* eP: Yes, separate URL, timestamped, etc.
* TT: Historically speaking ED exists because editor take suggestions for changes and produces a document for review. Not through PRs. Right now even though things are called ED, we have PRs and similar. When as a group we decide, this is a line in the sand and we don't want to go back, and want to refer to this version, then we say "make a timestamped copy in w3c archives". We can still do whatever we want in the github world, that's fine. Often we go in the wrong direction and have to turn back — that's normal. Either we are a W3C CG or we are not. It is okay to decide not to be, but that should be the question. Not timestamps, etc., as the discussion. Everyone should review the existing W3C processes. If that's going to break something that we want to do, raise such breakages as concerns.
* VB: I think we are not trying to redefine and looking for W3C guidance.
* JZ: I think we need some clarification.
* VB: Let's postpone this to next week.

### i18n (internationalization) and n11n (normalization) of resource identifiers
URL: https://github.com/solid/specification/pull/575

* VB: We still need implementation feedback. We said we'd wait for WT and SC on this in the past. We can actively ask for implementation feedback as a way to move this forward.
* eP: AFAIK, WT is working on it but not participating in the CG.
* SC: We need implementation feedback. Who really needs the feature, should give feedback. If others want it, it needs to be shown to be working and not breaking things. I haven't seen anything on records on any server of this being implemented of commitment to implement. Nor from applications. This is of interest, but we don't want to throw random stuff.
* eP: Do we have a test in test suite that this PR would affect / change tests or add tests?
* SC: Good question. Had to do with who wants to look into those tests. Some people are aware of the implications.

### STM meeting time change
* VB: Any objections to moving the meeting to one hour later? So, Tuesday's at 15:00 UTC.
* eP: That's colliding with FedCM. Prefer not to change it. Prefer another time
* RG: Perhaps two meeting slots. Many times we need more people for a special topic.
* TT: Current second half collides with FedCM. Later second half would also collide with CCG. Would need to consider a different day of week.

---