# W3C Solid Community Group: Weekly

* Date: 2023-07-19T14:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://gitter.im/solid/specification
* Repository: https://github.com/solid/specification
* Status: Draft

## Present
* [Sarven Capadisli](https://csarven.ca/#i)
* [Virginia Balseiro](https://virginiabalseiro.com/#me)
* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
* Hadrian
* Tim Berners-Lee

---

## 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/solid/specification/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
* Virginia

### Introductions
* name: text

---

## Topics

### WIP Implementation Feedback
* SC: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.

### Add discovery and descriptions for implementation report, test suite, test case
URL: https://github.com/solid/specification/pull/542

* SC: Ongoing work on Solid QA. Please review.

### Update mission
URL: https://github.com/solid/solid-wg-charter/issues/7

* SC: This is editorial. PRs welcome.

### Add W3C Solid CG Charter
URL: https://github.com/solid/process/pull/323

* SC: We're not looking to make a decision now. This is primarily to build awareness and gather feedback.
* SC: Please review. This charter is for us.
* SC: Re: the timeline: https://github.com/solid/process/pull/323#issuecomment-1629875377 . Last call 2023-07-25. Accept/Merge after 2023-08-01.

#### License
* SC: See thread https://github.com/solid/process/pull/323#pullrequestreview-1512907580 discussing MIT and W3C CLA/FSA licenses.
* SC: Latest state of the discussion: whether the CG should only use W3C licenses or both MIT and W3C licenses.
* SC: AFAICT, W3C licenses are required for W3C CG DRAFT/FINAL docs. Other documents can be something else - as we've thus far with MIT. W3C snapshots can be created for particular versions.
* TBL: I don't see a reason to switch from MIT to W3C. Is there anything MIT license won't do?
* SC: If we ever want W3C CG draft/final, those need to use W3C. Haven't see any issue with MIT licensed documents accepted/transformed for a WG, so WG could pick up MIT licensed docs and change all licenses to W3C. I don't know if there's anything we can do so that the CG can publish using W3C licensing.
* eP: Maybe there's some person/group that can answer those legal questions, someone focusing/specializing in that. There's a reason why W3C is not using MIT. Since none of us are lawyers.
* SC: I'll try to get PAC to give us a concrete answer. We proposed WG charter while PAC is aware that we're using MIT license, so if there are any issues that will come up. I'm fine with keeping as we are, if/when we need to create draft/final we can create a snapshot.
* eP: I don't understand if we work as W3C CG why don't we publish work as W3C drafts.
* SC: Going forward that's a good question, but historically development on specs has been on MIT license.
* TBL: Was so that we can make sure everything can used in combination. MIT license is very well known. It'd be nice to find out if they're equivalent.
* SC: The thread is open, we can come up with a more concrete answer on why/when to switch.

#### Add Work Items section
URL: https://github.com/solid/specification/pull/543

* SC: The proposed CG charter includes a process for [new work item proposals](https://github.com/solid/process/blob/7a8cfc55edaaf9de26252976fa8365d7c884bdc7/solid-cg-charter.md#new-work-item-proposal) (NWIP).
* SC: As mentioned, "some of this information could be moved to other documents". So, this PR moves NWIP from proposed Charter to the [Contributing Guide](https://github.com/solid/specification/blob/main/CONTRIBUTING.md).
* SC: Merging this PR should follow be followed with committing suggestion to refer to NWIP in Contributing Guide: https://github.com/solid/process/pull/323/files#r1267917483
* SC: There is some consensus on accepting the NWIP (based on reviews and feedback in the charter PR).
* SC: We'll look into further incorporating/updating [Solid Editors’ Technical Report Development Process](https://github.com/solid/process/blob/main/solid-editors-tr-process.md) in a separate thread. But for now:

PROPOSAL: Merge [PR](https://github.com/solid/specification/pull/543) and commit [suggestion in charter)[https://github.com/solid/process/pull/323/files#r1267917483].

* TBL: Does it mean to commit the group to the process by which we decided on these priorities?
* SC: This is only about: when you have a new proposal of a spec, for example, what you need to do. It says "create an issue, let people know, make sure there are names, explain why we need it, how people can get involved, etc". I copied from the Credentials group. It's pretty open, the bar is low to making new proposals. It allows even when conflicting specs, allows for multiple approaches even if they overlap. This is what this process is saying. The idea is to write in down in the contributing guide and have the charter refer to it.
* eP: Why is it contributing on the specification repo?
* SC: I put it into specification because we're more or less treating it as the general place for technical reports. It is likely to get more attention to a proposal and we can pick up in CG meetings. To log a proposal, it can be anywhere. Or just mentioned in a meeting. The reason why I suggest putting it in a meeting is just so there is prior discussion. Just picking this one repo.
* TBL: If you work in new specs, fine. If your work is outreach, websites, meetups, I feel in the future this is part of owning the communication so that solid does not only producing specs but more outreach: hackathon, meetups.
* SC: I don't see why not, but that's not a work item. Work item is a document or software.
* TBL: Right. We don't have a way of deciding whether to prioritize working on a document or holding a meetup. This group is in a limbo state while the WG has not yet started.
* SC: Not sure I agree. Seems clear what the WG will do once it starts and the things CG will work on. But that's a separate thing. This is strictly about what is a work item and how we get proposals for it. There's other topics related to hackathon, meetups, or which group should look into it. We can look into that, and we have two topics related.
* eP: I did approve the PR understanding why you chose this repo. Commented that to ask specific questions issue template would be a good approach.
* VB: +1 to issue templates
* eP: I think we need to organize the repos, we have a little bit of mess with the panels: https://github.com/solid/process/issues/324. Separate topic but we should come back to this.
* SC: We can have a dedicated meeting. I like the idea of issue templates. PR can stay open, not making a major proposal just moving some content around.

#### W3C Solid Business Group

* SC: '[Creating a "W3C Business Group"](https://github.com/solid/process/pull/323#issuecomment-1632996576)' was mentioned as a way to help frame the conversation / expectations" that go beyond CG's activities.
* SC: This is for general awareness and to continue the discussion. We don't need to make any particular decision in this call.
* SC: Some of the aspects of outreach mentioned in the charter discussion can fall under this.
* TBL: Solid Creators, are they part of the CG?
* SC: Is this a separate topic?
* TBL: You mentioned outreach.
* SC: Solid Creators is a a role in the Solid Team. Creators don't have a specific role in the CG, or hasn't been in the past. Creators in majority are not editors/authors of any specs or producing contributing guidelines, meeting material, or any of that. Some people with multiple hats, predominantly they are not listed in a spec as a solid creator.
* TBL: Right it is mainly about the website.
* SC: That's one of many things they do yes. With respect to work items in the CG they don't have any special overview than anybody else. CG generally has editors/authors.
* SC: Whether forming a Business group is something folks want to pursue, we can discuss (possibly a dedicated meeting).
* TBL: Do you mean a business group focused on particular verticals, like healthcare?
* SC: I interpret it in general, yes, it could be covered. W3C says "application of technology to business contexts", so means gives input to CG/WG, and yes verticals of any kind, that would all be covered under business group. This is something W3C can help us guide.
* TBL: If you have a BG to look at all of those it does not ??? might be useful to have one for each domain, like healthcare, to focus around a topic.
* SC: I just want to put it out there as something to look into, whether it's one or specific to domains. I agree with TBL.
* eP: Is there a precedent that some effort organized as CG also has a BG?
* TBL: I think there is, that's why someone suggested it, because it's common.
* eP: Would be good to know and see how their experience is, and how they divide the work.
* SC: If we can have a link, that'd be great. Raising this because it's an angle to that discussion.

### Solid Demos
* SC: Background: Originally proposed back on 2021-08-05 at [Gitter/Matrix solid/app-development](https://matrix.to/#/!ogHmAuzhszmxlGQrVp:gitter.im/$FdBbaChBNThzgicpyNhs5eCPp07-Q1KCBrq8AqsTrio) . There is interest to conduct these series of events. Also welcomed by Solid Editors Team: https://github.com/solid/specification/blob/main/meetings/2021-09-22.md#solid-demos .
* SC: Quoting for convenience/discussion:
>@/all Who'd be interested in a regular "Solid Demos" gathering for the community to showcase their implementations (servers, apps..)? :)
>
>Think along the lines of a demoscene ( https://en.wikipedia.org/wiki/Demoscene ) for Solid. It could be pretty useful to increase the visibility of implementations as well as to attract feedback from (developers, users, spec developers, ... investors?).
>
>Quality of the work is not super important. Things don't have to be polished or production ready or whatever. Let's get ideas across and attract collaboration. Demos can be however long they need to be. 5 minutes? => awesome!
>
>This can be a bottom-up organisation.. just need to self-add interest in presenting and whoever/rotating moderators (if really need to).
>
>Any way... just an idea. What are your thoughts?
* SC: I think it'll be super useful and a lot of fun :)
* VB: +1. Would be fun :)
* eP: +1. I am working on some demos. Now on notifications with two different apps using interop spec. It involves Webhook channel between server side components and Websocket channels used by on device apps.
* SC: Usually I share screencasts.. but this would encourage me to write some code I have been putting off.
* VB: Same!
* SC: I know SolidOS has a lot of people demoing things... we can pick those up. I shared this in app-development chat. Maybe that group will also be more interested in demoing.
* VB: RG mentioned to have a date for AStCH topic.
* SC: Let's propose 2023-08-08 to have a dedicated call for [Alternative solutions to container HATEOAS](https://github.com/solid/specification/issues/525). Issue needs to be broken up but if not possible the understanding was that we pick it up generally in a dedicated call to give enough time. It is not urgent per se - not a milestone. Bar any significant changes will be made by WG in the future probably.
* eP: The issue has links to previous meeting with other people agreeing this should be addressed pre 1.0. I can find the meeting minutes. https://github.com/solid/specification/blob/main/meetings/2022-10-19.md#server-container-description

### Are uri semantics just neccessary or sufficient to determine containment relation?
URL: https://github.com/solid/specification/issues/505

### Proposals for Dedicated Calls
* [Alternative solutions to container HATEOAS](https://github.com/solid/specification/issues/525).
* Implementer Feedback meeting.
* Solid Demos.
* Reorganizing github repositories [related issue](https://github.com/solid/process/issues/324)