# W3C Solid Community Group: Weekly

* Date: 2024-07-03T14: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)
* [Pierre-Antoine Champin](https://champin.net/#pa)
* [Rahul Gupta](https://cxres.pages.dev/profile#i)
* Jeff Zucker
* [Sarven Capadisli](https://csarven.ca/#i)
* Hadrian Zbarcea (first half)
* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
* Maxime Lecoq-Gaillard
* Grace Elcock
* [Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](http://www.openlinksw.com/))

---

## 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
* name

---

## Topics

### CG Report requirements
URL: https://github.com/solid/specification/issues/587#issuecomment-2189388004

* VB: RG, need any more input?
* RG: I don't believe ??? from individuals to CG. The recent changes with CG-DRAFT copyright/license doesn't reflect that. Will wait for IJ to comment on it. Have a strong feeling that there is oversight here.
* VB: I'm not sure I understand the issue.
* RG: Essentially the org is a seperate entity from the individual. If the organisation is publishing, then that's separate from individual licensing. The org could still 'charge' for instance as with academic publishing.
* PAC: Not sure I understand. The org is not the CG, but it is W3C.
* RG: The CG is the entity, but not every individual put together.
* PAC: I would've thought it'd be sorted with W3C.
* eP: This is not specific to Solid. Applies to any CG. Is there a place in W3C to track this for overall licensing? Other groups are interested as much.
* RG: W3C is really hands-off until starting a WG. All these quesitons should be addressed before.
* VB: From the conversation, IJ said he'll get back, and we can wait and maybe ping again next week for follow-up.
* SC: Ian is speaking on behalf of W3C Team's Community Process; that is probably the best place. Related to TR pages, lists of groups and types of licensing.
* SC: Perhaps https://github.com/w3c/tr-pages/
* SC: Rigo was involved in the licensing part of the Solid CG charter. What we wrote there was with the understanding that when we publish these reports, it'd be an easy transition to a WG work item.
* RG: When the charter was written, we changed the license a bit, and added an exception. If this should be published under a CLA and not a license, this is the first thing they should have pointed out.

### Please Add TRs to SpecRef
URL: https://github.com/solid/specification/issues/668

* SC: These identifiers are meaningful in the API; `specref` is one place. Is Solid-protocol or WAC reserved for a particular version? What happens if we re-use? But versioning can be done. We just need to add entries. I can generate some of that for the TRs we have. Some of it can be automated, some of it needs to be manual.

### Meeting recording and publication
URL: https://github.com/w3c-cg/solid/issues/18

* SC: If the process is not working then we recorded that issue some time ago... W3C offers this infrastructure to record meeting minutes and publish immediately. Many groups use this system; I don't see why we can't. There's support... this is a reaction to the challenges we may be having about getting these minutes published in a timely fashion. If stuff is sitting around for weeks or months, that is not giving good service to the community. If people think we can publish minutes once a quarter, we can update the process.
* VB: I agree and don't want to spend time on debate. We discussed before. Open to give the W3C infrastructure a go. If people have concerns, we can try to answer them.
* RG: Can we simplify the process by not having the agenda in the PR?
* VB: If we change the process, that's not applicable.
* HZ: I don't think the situation is as dire as presented, because the information is in the PR. In the past months, we talked about the process and didn't make progress on the specs.
* VB: If we don't get small things process right, I don't know how we are going to do bigger stuff. Admin stuff needs to not be mixed with spec. We have stuff relying on this, `ecomon` for example. I personally get people pinging me looking for the minutes. Important to have things working properly and smoothly. Maybe it's hard to rememeber to PR.
* HZ: Personally against it.
* JZ: Want to support RG's statement. Re: yesterday's agenda, not sure whether to add to `hackmd` or PR. It looks to me, it is unclear.
* SC: Separate topics between chairs proposing an agenda, and topic suggestions from everybody else. I don't agree with HZ that this is taking time and we're not making progress on specs. Many agendas are just an empty template. Not one-off, recurring pattern. Agenda does not need to be PR; it just initializes something, and gets updated when the minutes are finished. Agree with VB about admin being separate from spec progress. If spec progress is such an issue, I would have expected the CG drafts that are published, bunch of milestones we're taking off for 0.11, suggesting shouldn't block the release, I don't remember the chairs saying we should add to 0.12. Topic of milestones was not brought up at all. There was an initiative to remove things from a milestone and not an intention to see it through. Why is the spec not evolving? Show me implementation reports. There's a number of PRs and issues. If the chairs are not picking those PRs up, the argument cannot be made that arguments on meetings are holding back on the spec.
* VB: I get requests for topics and I check chats. Do we have strong objections to try the W3C infra or?
* eP: I think we can try and I have no hopes for that. Especially with regex, so that's a problem. I don't think we should try but I won't object. Definitely won't correct. I think we overengineered. Creating agenda, PR and merge. IMO, create hackmd, then don't do PR, chairs then commit the minutes. It can be like IRC. During the meeting people can make corrections. The main problem is someone has to go three times. This is two steps.
* VB: I disagree with some of this.
* TT: I also disagree with some of those things. There are principles at W3C on where you put the burden ... end users, software developers, spec developers (priority of constituencies). This is similar. In the current process, corrections are pretty easy to make. For someone not familiar with GitHub or other things like that, change suggestions are easy, where making a PR is much more complicated. As to three times, give me a break. If you don't have time to do it, other people can do it. To the question of whether to use W3C infrastructure, it is solid (no pun intended); it has evolved over a long time. We started out using that infrastructure. It was rejected because it uses WebEx, which is proprietary, and Jitsi, which is open source, was preferred. Jitsi has issues too, but I tolerate it as the community choice. Fine. W3C infrastructure can be helpful. But this is a very tiring topic, being rehashed multiple times over the years. Don't want to revisit it again.
* VB: I agree with TT. We shouldn't be explaining to people how to make PRs, but making easier to participate in the meeting. The burden is on the chairs, as part of their service to the community — not just showing up once in a while. I prefer to take on some of that so that people can participate. Re JZ's about separate places to raise topics — We don't *have* to PR before the meeting. I personally do it so people have a place to propose topics.

### Response to security review
URL: https://github.com/solid/solid-wg-charter/pull/80

* PAC: We requested a horizontal-review from the security team because we didn't have one on the previous charter. This PR is a response to that. Thanks to those commented already. There is a wording issue we shoud be able to solve. We are three PRs away from submitting the proposal. I don't think that the one I created is controversial.

### Testing clarifications and corrections
URL: https://github.com/solid/solid-wg-charter/pull/81

* SC: Mostly editorial. Updating links, etc. Also explicitly adding Solid QA.

### Add solid-lite as lws-protocol input document
URL: https://github.com/solid/solid-wg-charter/pull/82

* SC: Acknowledging some work on Solid-Lite as input, just like we did with Fedora. It has a couple of server implementations.
* eP: What's the rule of thumb for listing something as input? There's not a commitment. If something seems relevant, what's the rule?
* SC: There are things that are in the existing literature or there are issues. There's licensing, whether something developed using an open process. There's a hint of implementation, community, activity, use. The point of the inputs is that they're relevant towards the deliverable. Lots of parts where the WG will have to make the call.
* PAC: Regarding this particular document, I had not looked at it in depth. It looks like one person's work. Isn't that opening the door to adding all sorts of documents? I find this a bit concerning. Again, I don't have an exact answer, but there is a subjective assessment. In this case, it is borderline. It is very different than the other two documents.
* eP: For me the main question is, we have separately listed deliverables. If something is listed as an input, it doesn't mean it will be accepted, just taken into account. If that's the case, then we can list RemoteStorage. Should we list stuff from IndieAuth, etc? Understanding whether it fits or not vs. knowing/acknowledging something going on or using it. How to draw the line?

### Solidifying Solid Project
URL: https://github.com/solid/organizations

* VB: Proposed by JZ
* JZ: Don't have time to do the whole prepared demo. Just want to make the group aware; not sure if it needs to be a work item. Have been working on "solidifying the solid project" — RDF resources of Solid. Supporting solidproject.org. Both a place to store all this information and a generalised approach to it. Part of the reason I'm coming to the CG is because of shapes, software, and vocabularies. So not just a list of resources. I'll aim at a wider vocab re: what orgs and resources do.
* JZ: {Shares screen} The basic idea is that there are different resources. So, identify them and categorise them. What shape does that type of thing have? About the order of constituencies, the target audience is users and application developers. User doesn't need to know a server is in Typesript. Some of these items have homepages; some projects only have repositories, because no particular organisation is providing that resource. Useful to know if something is free, for example. Also categorization like chat, mailing list, ongoing meeting, message board. There is a shorthand search mechanism to say the name of a field. This is based on webcomponents.
* eP: Related to my solid efforts. We can collaborate on shapes. Client-client shapes could be a work item.
* JZ: There is possibility for collaboration. In terms of shapes, under the `solid/organization` repo. One thing about the shapes, specifically interested in users, e.g., solid server and notification server is important to a lot of people but may not be important for what we want on solidproject.org. I want a really basic shape where we have connected shapes, e.g., technical shape. I'm not intending to invent a lot of shapes. There are other vocabs. The technical issues are 'the' shape for products but developing a catalogue shape for resources of an organisation. We may have multiple shapes, but I'm concerned about basic multi-purpose and easily used shapes. If there is a basic catalogue shape to use them for different purposes.
* VB: Okay to pick up next week?

### TPAC: Call for Group updates and Technical demos (videos)

> We invite your group to create a video (or more) to be featured on the TPAC24 website at https://www.w3.org/2024/09/TPAC/group-updates.html
This is a great opportunity to showcase your work, share updates, and present technical demos of your latest advancements to the wider W3C community.
Drawing from our experience, we have compiled a set of best practices to help create impactful videos:
https://www.w3.org/wiki/TPAC/2024/Demos_and_Group_updates#Best_Practices_for_Recording_Videos
For reference, please have a look at the TPAC 2023 videos: https://www.w3.org/2023/09/TPAC/group-updates.html

* VB: If anyone is interested we should submit the name of volunteer(s) and proposed title of demo before July 28th, and the recorded videos before August 30th.
* RG: Is there an official site where all sessions are up?
* PAC: I'll share link on Matrix chat.