# W3C Solid Community Group: Weekly

* Date: 2023-07-05T14: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)
* [Wouter Termont](https://github.com/woutermont)
* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
* Maxime Lecoq
* Hadrian Zbarcea
* Jeff Zucker
* [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me)
* [Ross Horne](https://satoss.uni.lu/members/ross/)
* Brandi Delancey
* Fara
* [Rahul Gupta](https://cxres.pages.dev/profile#i)
---

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

### Introductions
* Brandi Delancey: I work with [Life Equipt](https://www.lifequipt.com/) focused on creating digital tools for veterans. Looking at if what you are working on could help with transitioning veteranans.

---

## Topics

### WIP Implementation Feedback
* SC: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.
* eP: Met with Jackson/Wout on TypeScript implementation of Solid Notifications Protocol: https://github.com/o-development/solid-notification-client . Participation is welcome!
* RG: Last week I've been talking about distinct notification protocol [Per Resource Events Protocol](https://cxres.github.io/per-resource-events/protocol/) I hope I can get some suggestions on how I could advance with it.

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

* SC: This is editorial. PRs welcome.

### Best deadline for the AC review?
URL: https://github.com/solid/solid-wg-charter/issues/41

* PAC: We need to setup a deadline for AC vote on the Solid WG charter. The choice was to have it just before TPAC or during TPAC. My thought was if we set the deadline during TPAC than we will have an opportunity to discuss it with people who have objections. I realized that if we set it before, we will still have formal period to address those objections during TPAC. I would advise to have the deadline set before TPAC and take advantage of TPAC to talk with people who might have objected and discuss it, hopefully helping with retracting them.
* RH: What are the objections and how we can access them.
* SC: There are no objections (yet) - the review hasn't started.
* PAC: Right. We don't know, if no objections, sooner the better. If there are objections may need ot deal with other TPAC. Do we try to avoid objections before or try to negotiations before the deadline. Having a clear picture during F2F is a better strategy.
* SC Decisions won't be made on the spot. Discussions about objections should be async and recorded. PAC, could you clarify how the CG can access AC feedback? Some may be on the w3c-ac-forum mailing list (which is private to Members) and some may jump into the GitHub on the charter.
* PAC: Process-wise discussion of the charter is not a prerogative of the CG. Process is concerned when charters get submitted to members. What happens before is not covered. CG is the natural place to discuss but there's no official prerogative to respond. Some members might choose to make vote public, others member-confidential. I don't have a straight-forward answer as to how CG participants will get access to that information, but the team (me probably) will come back to the group but informally.
* SC: As long as we get a version of the objection, that's fine. Some people might be at TPAC in person, but as long as we're all in agreement the sooner the better.
* SC: Any objections to set the deadline before TPAC as suggested in https://github.com/solid/solid-wg-charter/issues/41#issue-1779682756
>setting it in the first week of September, just before TPAC, so we can have our first WG meeting there

* WT: +1
* PAC: +1
* HZ: +1
* JZ: +1
* eP: +1

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

* SC: I'm not proposing a decision in this meeting. This is more of an initial announcement to raise awareness.
* SC: Until now, since 2018-2019 we had a rough process documented in the process repo. I has worked in some ways and in some ways it didn't work. The practice of the CG doesn't reflect of what is recorded in that process. I noted that it is bit complicated and convoluted. There are also certain rules that are expected to help with advancement of TRs, it worked for some time but not in last 6 months or so. We need a new process which is more approachable, reflect current practices and simplifies things. You can find it all in the PR.
* SC: It follows general charter outline, CGs are in general not expected to have charter. Some do have a charter, especially those who incubate reports and transfer them to WG. We should codify what seems to be working for us today. Besides the charter we have a separate document - Contributing Guide. The charter highlights chair elections, aiming at having more diverse voices and backgrounds. Reflecting peoples track records in the group. It also clarifies how work items are created and how we incubate that work to the point that it can be passed to WG.
* SC: I found no point in revising the old process since it would lead to re-write anyways. It is as close as possible to what we are doing. There will be time to provide feedback on the PR.
* JZ: I think this is a great idea to get the charter going. I think there are so many different parts there. Each one deserves a lot of thought. General comment about the purpose of the group, the way it is phrased now it suggest that it is discussion. As I understand the purpose is strenghten the process of developing the specification.
* SC: The group's missing hasn't changed entirely we both are producing specs and implementing. Please do review the charter and add inline suggestions / comments.
* SC: You mentioned that CG is just an incubation, I think this is by definition [???]() shows the differences between CG and WG.
* RG: Regarding the license, you still kept it into MIT. Is it a wise choice going into the WG. There is no mention about client-client standards, there is a lot of desire to work on it here.
* JZ: The WebID Profile group is an example, also SAI. I assume that those will continue to be worked on here. What was you first point?
* RG: The licensing aspect, we probably want to use W3C licensing instead of MIT. I'm just saying that it has to be made explicit (the client-client part).
* SC: The scope hasn't changed, I tried to write it clear enough to cover the current scope. I said "profiles for social and software agents". The fact that WG is starting doesn't mean that all the protocol work stops in the CG. For the working group the agreement is that the Solid Protocol and the other outlined specs will be carried in WG. If there are other protocols we need to look at are still in scope of CG, for example query interfaces. WG has a start and end date, what happens after the end of WG is still open. We should keep the CG as primary incubation stage. This is similar to Credentials Community Group, they ensure that the specs are moving out.
* SC: I'm not a lawyer, the MIT license is compatible with W3C picking it up as a submission. When W3C releases it's first working draft, the new document will use W3C license and IPR. I think PAC can have a say in that.
* PAC: My understanding is that W3C license is for community reports. CGs are not required to have a charter and are not required to conform with the same criteria as WGs.
* RG: CG will continue with incubating specs and promoting it to WG. Will we redefine the charter in the relation to WG?
* SC: The specs that are picked up as WG deliverable will be worked within the framework of WG. There are different requirement on how one can join WG meeting vs CG meeting. Once the WG starts, the CG will not have topics in the meetings about WG work. That development will happen in the WG.
* eP: re server-side client, there is no spec for that but eventually that can be something the WG can deliver. The WG can adopt it and still include it alongside. Would it be still possible for the CG to work on it a year that the WG in the middle of it can adopt it / iteration in it. Release it alongside Solid-OIDC,. on the device.
* SC: I think we covered that in the scope of WG charter, if it is within WG scope an the WG accepts it as a work item. If proposal comes few months before the WG charter ends it would be most likely to late. If it is in scope it could be picked up.
* PAC: You covered it. Nothing to add.
* JZ: End date for the WG?
* SC: It is 2 years after the start. If we start October 2023 it would be end of September 2025. There could be rechartering, if group needs that they need a little more time to complete something in CR or PR stage. If something is in FPWD state it would probably not justify rechartering.
* PAC: There is a tendency now, even if group finished the deliverables to recharter in the maintenance mode. Which means applying some errata and ensure any minor updates are taken care of. In the maintenance mode no new specifications are being worked on.
* SC: Please provide your feedback directly on the PR.
* RG: How the organization of the CG will continue, not the WG? If you become WG chair, would you also keep the CG chair?
* SC: CG and WG are independent but we will be coordinating the work. CG would be incubating new work.
* eP: In this PR we're discussing the CG charter, not the WG charter.

### Clarify that slash doesn't entail containement
URL: https://github.com/solid/specification/pull/538

### Add section describing the the relationship between Solid Protocol and LDP
URL: https://github.com/solid/specification/pull/539

### Alternative solutions to container HATEOAS
URL: https://github.com/solid/specification/issues/525