Add 2024-01-31 agenda

meetings/2024-01-31.md

@@ -0,0 +1,159 @@
+# W3C Solid Community Group: Weekly
+
+* Date: 2024-01-31T14:00:00Z
+* Call: https://meet.jit.si/solid-cg
+* Chat: https://matrix.to/#/#solid_specification:gitter.im
+* Repository: https://github.com/solid/specification
+* Status: Published
+
+
+## Present
+* [Virginia Balseiro](https://virginiabalseiro.com/#me)
+* [Sarven Capadisli](https://csarven.ca/#i)
+* Hadrian Zbarcea
+* [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me)
+* Grace Elcock (guest)
+* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
+* April Daly
+* Theo
+* [Rahul Gupta](https://cxres.pages.dev/profile#i)
+* Jan
+* Damon Outlaw
+---
+
+## 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
+* Hadrian Zbarcea
+
+### Introductions
+* name
+
+
+---
+
+## Topics
+
+### Co-chairs Rotation Schedule
+URL: https://github.com/solid/specification/discussions/618
+
+### Special Topic Meetings
+URL: https://github.com/orgs/solid/projects/16/views/1
+
+### WIP Implementation Feedback
+* VB: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.
+* Theo: FedCM, will demo next week with Jan. 
+
+### WG Charter Update
+* Proposed by PAC
+* PAC: Initial charter rejected. W3C council convened. Recommendation is to ask for permission to submit new charter, because of remarks, including from the TAG. It was considered that it's not enough to just tweak the charter; a new one is needed. We don't know when to expect a response. As soon we we get the response, we want to restart the process. PAC reached out to CG chairs, how to do that in a way that allows everybody to chime in. The question to the group is how to process; PA would like to be faster than the weekly meetings. Can we decide how many days and how many approvals we need per PR, without waiting for the CG meeting?
+* SC: Looking at the strength of objections is important. Majority of the objections had to do with the proposed chairs which accounted for 30% of the AC reviews. Proposed chairs was a W3C Team decision. There were other issues about scope and deliverable dependencies. The CG had requested W3C's guidance on addressing them; as it was not something that we'll be able to solve. That was something the CG flagged back in 2023-05. Everything else is relatively marginal. There are things we could do strategically that address the problem space. There were other suggestions on the mailing lists. We could say: these are some specs that we used as input; the group is open to other specs incubated per W3C recommendation on open space. This is similar to how Annotation WG and Social Web WG were chartered. See links below. Again, the proposed chairs were the primary reason for objections - W3C Team decision, and the concerns already acknowledged widely at W3C about Team's decision making process, rationale, and transparency. The rest of the issues about the charter are marginal and were expected.
+* SC: https://github.com/solid/specification/blob/main/meetings/2023-10-11.md#wg-charter-proposal-status-update
+* SC: https://github.com/solid/solid-wg-charter/issues/37
+* SC: https://lists.w3.org/Archives/Public/public-solid/2023Nov/0094.html
+* SC: https://github.com/w3c/charter-drafts/issues/455
+* PAC: https://github.com/w3c/charter-drafts/issues?q=is%3Aissue+is%3Aopen+wg%2Fsolid+in%3Atitle
+
+* PAC: Generally a few changes are required in the text of the charter. For instance, the issue of dependencies. It is a shared responsibility.
+* eP: I see that PAC posted the link to the repo for the charter. There is also [W3C repo](https://github.com/search?q=repo%3Aw3c%2Fcharter-drafts+wg%2Fsolid&type=issues). How do we split the work between the two charters?
+* PAC: The issues on the Solid repo are more for internal discussion. 
+* eP: The community group should not worry about ...
+* PAC: We should answer the specific objections in the W3C repo. We could use the draft charter repo for everything, but it would be odd. It makes more sense to have the tweaking of the charter in a separate repo. If the group thinks it's inconvenient, I'm open to change.
+* eP: Makes sense. It's more convenient to have everything in one place instead of synchronizing.
+* RG: How can we address and eliminate the objections by improving the spec?
+* PAC: What SC pointed out is really important. It feels like we're promoting a pre-baked solution. We must insist that this is just one input and the result may differ from what was incubated. PAC hopes that making this clear will resolve some of the issues raised with the CG spec.
+* RG: You looked at what changes can be made to the charter; I looked at what changes can be made to the spec.
+* PAC: I see your point, but I think it's more important to focus on the charter. I am trying to lower the importance of the spec, and show that the WG will not be stuck on one particular solution. Most of the AC reviewers thought the group is not open minded enough. 
+* eP: I am looking up at this particular paragraph:
+  <blockquote>When possible, the Solid Protocol will evolve while maintaining a high degree of compatibility with existing implementations, of both servers and clients, and with features from prior versions. If incompatible changes have to be made, then they will be done by introducing a stage where both old and new protocols are supported, to allow the implementors to upgrade their systems in a managed way.</blockquote>
+* SC: Even though there was a CG for Annotations, for example, the charters for Web Annotation and Social Web still proposed their work as inputs as opposed to 'the' solution to the problem space.  These are examples; processes and people may have changed. Solid just happens to be one of the many solutions out there. Why is this locked into just Solid? I tried to differentiate between the Social Web and Solid. Sometimes we get tripped up by what Social is.
+* VB: It would be good for people to subscribe to repo and chime in, to make it faster.
+* SC: We're rewriting; are we co-writing? PAC leading? It doesn't take much to write a charter.
+* PAC: Ultimately, this is the team proposing the charter. I am trying to be as open and transparent and possible. I am happy to take the lead and submit a new version. I want to be sure to let this group know that I want feedback, and I want to be as responsive as possible. Submitting every PR would take too much time. Is that ok, SC?
+* SC: I just want to make the distinction. If the charter comes from the CG, then it has to be collaborative work. 
+* VB: PAC, want to respond?
+* eP: I support PAC taking full leadership. I don't think we should slow things down. Maybe before submitting having one more round of reviews.
+* PAC: Thanks eP. I am willing to hear as much feedback as I can. I will not reframe while merging things. I commit to asking the CG for a formal approval before submitting.
+* SC: Again, if it's CG's work item, I would consider that as a topic on agenda. If we leave it all the way to the end, I am not sure we'll be able to address all the points. This group was as fast as it could've been in processing the issues and PRs in the past. I trust PAC's judgement, but I still think the CG should be plugged in.
+* RG: Is the group willing to do a Special Actions Meeting with PAC leading to resolve this?
+* PAC: I didn't want to seem like I am blaming the CG for being slow, by asking this question. Again, I welcome feedback. If we need an extensive discussion on some points, I'll try to attend these meetings.
+* VB: Is the primary concern that our meeting frequency will delay the submission?
+* PAC: Yes. Ideally I'd like to merge a PR within a few days. It's not a criticism on the CG. I just want to have a fast pace for the next iteration, not to bypass the CG.
+* VB: Let's take advantage of the async work, follow repo, make sure people are aware of PRs. If we need ad-hoc meetings outside the regular one we can have them.
+* SC: No strong opinion on the time. We don't need to wait for 2 weeks for a typo to be fixed; we work in an open space; other things may need more feedback. See https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md#decisions as example.
+* eP: The charter was proposed by the W3C team, not the CG. PAC is doing a best effort. I think we should not do anything that would slow PAC down. If we're all happy with the way it's done, we don't need to prematurely optimize. I don't think anyone is concerned that feedback from CG will be ignored. If someone wants to get something done, we shouldn't put too much procedure around it.
+* VB: Is there any objection to working async and letting PAC do his work? Any objections? (NONE from audience).
+
+### Access modes discussion
+URL: https://hackmd.io/@solid/ByPmZZ4KT
+
+* Proposed by eP
+* VB: There are a number of open questions. Specs need to be reviewed. How do you think we could move forward with this? SC, eP?
+* eP: I don't think we can make progress during this meeting. The question is where should be tracking that. Maybe we could try over the next week or two to make progress.
+* VB: any comments on that? If we need a separate meeting, we can schedule any time.
+* SC: I think that if we try to integrate the concerns in those issues into respective documents, it'd reduce the things we'll need to address separately. I don't think we need a separate place to track it since we have all the issues. Let's say we need to update the definition of operations; we know these things. If this is in the scope of the spec we'll clear it up. We have the information already.
+* RG: there is no meeting scheduled. We should schedule one during the next couple of weeks.
+
+### Add Workspace selection guidance
+URL: https://github.com/w3c-cg/solid/pull/16
+
+* VB: any objections to merging? (NONE from audience). Action item: merge this PR
+
+### Add guidance for maintaining clean git history with squash
+URL: https://github.com/w3c-cg/solid/pull/15
+
+* VB: needs adding guidelines. Requires squashing, there are a few comments, needs more attention. I'd like to hear more opinions on this. If you have some time please review this PR.
+
+### Add security consideration for serving user-created files
+URL: https://github.com/solid/specification/pull/598
+* VB: Some new clarifications from Otto on the issue.
+
+* VB: Needs more review. Otto responded to some questions.
+* eP: I think we need a bit of a strategy how to address this issue. We should mention potential vulnerabilities in the spec. We should first agree on the problem and have that documented.
+* SC: I think the PR and the issue are good enough for the discussion. I don't think the spec should have something. I don't think inlining an issue in the spec would help. Implementers already consider these issues. We don't have a lot of implementation feedback. They could be discussion points. To me it's not that significant. It's a question whether it's a feature. Solid should be extending the current web, not limiting what people could do.
+* RG: I would say that needs to be documented... (breaking up). Other solutions should be left to the implementer.
+* eP: That's what I am talking about. We don't need to agree on the solution, but we need to agree on the problem. If there is only one proposed solution, we shouldn't criticize it, we should propose alternative ones.
+* RG: to address SC: this is not a problem specific to Solid.
+
+* VB: we're out of time, please review remaining issue for next meeting
+* SC: It's worth repeating that we always need more implementers' feedback. We need to capture feedback in referenceable documents. If I were a reviewer, these are the things I'd be looking at. Need to prove it's real and not vaporware. 
+* eP: My understanding is that this is implementation feedback based on experience with ESS.
+* eP: https://github.com/solid/specification/pull/598#issuecomment-1892656519
+* SC: There's applications that be blocked. Proprietary implementation vs what people do on the web today. Pointing to one example is not enough.
+
+---
+
+### Clarify requests with N3 document in server-representation-turtle-jsonld
+URL: https://github.com/solid/specification/pull/608
+
+### Release 0.11.0 Milestone issues
+URL: https://github.com/solid/specification/milestone/7
+* VB: Want to know what the status is on some of these issues what is needed to move forward. 
+
+#### Specify container description
+URL: https://github.com/solid/specification/issues/227
+
+#### Server Description
+URL: https://github.com/solid/specification/issues/355
+
+### Should Solid (storage) servers support "RDF documents" containing multiple subjects (or quads)?
+URL: https://github.com/solid/specification/issues/610
+
+* SC: Chairs, can you use "status" labels, e.g., "waiting for commenter"
+* SC: I tihnk this issue can be closed but if there is anyhting, it should be broken up into specific questions/issues to follow up. I'd like to hear from ML on what needs further clarification or request...
+* ML: Sorry, did not take the time to review deeply and answer yet. 
+