-
Notifications
You must be signed in to change notification settings - Fork 44
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Add agenda 2024-09-18 * Update meeting minutes 2024-09-18 * Apply suggestions from code review Co-authored-by: Ted Thibodeau Jr <[email protected]> --------- Co-authored-by: Ted Thibodeau Jr <[email protected]>
- Loading branch information
1 parent
46eac4c
commit a613eb3
Showing
1 changed file
with
133 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,133 @@ | ||
| # W3C Solid Community Group: Weekly | ||
|
|
||
| * Date: 2024-09-18T14: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) | ||
| * [elf Pavlik](https://elf-pavlik.hackers4peace.net) | ||
| * Hadrian Zbarcea | ||
| * Willem Datema | ||
| * Grace Elcock | ||
| * [Rahul Gupta](https://cxres.pages.dev/profile#i) | ||
| * Maxime Lecoq-Gaillard | ||
| * Michiel de Jong | ||
| * Jeff Zucker | ||
| * Tim Berners-Lee | ||
| * Laurens Debackere (from 14:30UTC) | ||
| * [Pierre-Antoine Champin](https://champin.net/#pa) (from 14:45UTC) | ||
| * [michal/mrkvon](https://id.mrkvon.org) | ||
| --- | ||
|
|
||
| ## 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 Conduct](https://www.w3.org/policies/code-of-conduct/) | ||
| * 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 | ||
| * Grace Elcock | ||
| * | ||
|
|
||
|
|
||
| ### Introductions | ||
| * [name]: | ||
|
|
||
| --- | ||
|
|
||
| ## Topics | ||
|
|
||
| ### TPAC | ||
| * VB: Agenda for 2024-09-27 (TPAC), please review and suggest topics: https://github.com/solid/specification/pull/681 | ||
| * VB: Live minutes: https://hackmd.io/1QInJs0-QS62qHPQbUTV-Q | ||
| * eP: https://www.w3.org/2024/09/TPAC/breakouts.html#grid | ||
| * eP: Link above is for breakout sessions that are relevant to Solid. Some on end-to-end encryption, etc. | ||
|
|
||
|
|
||
| ### Plans for Q4 | ||
|
|
||
| * VB: Proposed by eP, continued from last week | ||
| * eP: CG <-> WG coordination | ||
| * eP: The idea is that the CG can give a bit more room to activities related to the "C" in "CG", as long as this doesn't stand in the way of continued spec writing and QA process of the remaining specs. | ||
| * eP: Introducing the topic, we have a little bit of a plan for what to accomplish in Q4. Some meetings we, have discussed the work happening but it's hard to pinpoint outcomes of CG activities. It would be useful to outline what we should accomplish to focus the CG. This is especially important as the WG has been approved, and some work will be taken on by the WG. | ||
| * eP: Core specs will be taken over by the WG, and the CG will incubate some things not yet ready to go to the WG. | ||
| * eP: CG would focus on UX/DX, Practitioners' work, feedback. CG could work more 'inside in' in this way. | ||
| * VB: Questioned what the feedback posted was and realised what it referred to. | ||
| * eP: https://forum.solidproject.org/t/solid-interop-in-practice/7701 | ||
| * RG: Would we be appointing official liasons for WG to CG and vice versa? | ||
| * VB: As far as I know, communication will remain open, but unsure if there's something official. Will stay in touch with PA. | ||
| * eP: relevant ideas from FedID CG&WG (recently transitioned) https://github.com/w3c-fedid/Administration/blob/main/proposals-CG-WG.md | ||
| * VB: Unsure what is needed regarding plans for remaining part of the year — is it just awareness? | ||
| * eP: One of the efforts to focus on could be processing the feedback, e.g., see how we will follow-up. Forum post above has 0 responses. Next topic is the catalog to map the community and give visibility to what is happening in the community. Proposal would be the new schedule of practitioners appearing in the CG calendar (something else to give prominence to the practitioners effort). | ||
| * VB: How do we want to approach processing feedback as a group? | ||
| * eP: Not sure if there is time to take this as a to-do, but to break up conlusions from the report to take ups separately, e.g., difficulty with picking up shapes. eP to go over report and draft bullet points to then drive some of the agenda on special topics/other meetings. Everyone could do something similar for different topics. | ||
| * JZ: At last team meeting, Michelle and Oz and I were discussing the idea of having a longer meeting that involved the team, CG, interested parties to step back and do some planning re organisational structure and goals. It's past time to dedicate time to talk to one another about this, e.g., afternoon to talk about where we are going as an organisation and a project. | ||
| * eP: Ask MdJ to ask how they see continuation of UX/DX to encourage more prominence? | ||
| * MdJ: Yes, can do that in these meetings and special topic meetings. Officially, need to make it a work item, or add something to the charter. Might want to add something about organising events as a CG. | ||
| * TBL: UX/DX seems quite broad — do you mean consumer experience? | ||
| * MdJ: Yes, very broad, but allows people who want to to add topics for the agenda. | ||
| * VB: Remember, when writing the charter, we had an extensive discussion on activities (e.g., hackathons). Agreement was that there was a Solid team, and other groups that conduct different types of activities. Over a year has passed since, and I am wondering what in the charter blocked these or other activities from happening. Not opposed to changing anything in the charter but would like to know what went wrong given extensive discussions during charter writing and agreement reached to carry out these activities in Solid Team. Not seeing anything in charter that is blocking the activities, so is it something to do with the functionality of the group? As I said, I am not opposed to updating the charter, but I would like to know that whatever changes we are making are actually going to facilitate some work that is currently not happening due to it being missing in the charter. Otherwise, it feels like we might be procrastinating on actual work by changing text, when I am not sure any of these activities were attempted and failed due to the charter text. | ||
| * eP: Like to follow up on UX/DX. Attempted diagram with different audiences and where things are happening. Have seen something being discussed in fedID WG. Have app developers, some core library developers, etc., then spec writers. If there is a burden to put somewhere, the last place should be the user. Web app developers can take some burden (minimal), but browser developers can take a bit more. We can use UX/DX feedback from app developers, etc., to see how their specs are impacting UX/DX and how it could be switched to smaller audience. | ||
| * TBL: Certainly whole UX/DX areas. Some things exciting in landscape — "Local First" community has a lot of energy regarding users having control over their data. "No code" is another one that has some important directions to pursue/in touch with. | ||
| * eP: Does anyone have a good reference to understand the authorisation approach for "Local First"? | ||
| * TBL: Could look at things like [tinybase](https://tinybase.org/) | ||
| * RG: Look at https://martin.kleppmann.com/papers/local-first.pdf | ||
| * MdJ: The remote storage widget that we did now supports Solid. It allows you to start using the app in the browser. That supports Solid now so a connection. Regarding getting it wrong on the charter — I think we got it right. Can use the CG as all passionate people about what feels like one project. Big difference between time when that CG was written and now, is that WG is now active so CG will no longer be working on that spec, and therefore will have more time to work on the community. | ||
| * RG: MdJ, can you provide a link to the remote storage? | ||
| * MdJ: https://github.com/remotestorage/remotestorage.js/pull/1319 | ||
| * VB: If no other comments, then closing. | ||
| * LD joined — conversation on this picked back up | ||
| * LD: Greenlight on WG and call for participation now out. In terms of coordination with CG — this still needs to be shaped. Chairs of CG might have thoughts on how to organise that. WG also discussed. Some specs need further incubation (part of crossover), but also topic of _Use Cases and Requirements_ (UCR) that is likely one of the first items of the WG, so wondering what sort of inputs the CG could give to this. Don't feel like there is one master source of all use cases and requirements. | ||
| * eP: Happy to hear that UCR will be a focus at the beginning. | ||
| * TBL: What are the relationships between use cases, requirements, and roadmap? Each vertical is potentially a huge gain but the sort of thing that has to be done in careful collaboration looking at existing work in that area. Is a vertical a use case or a requirement? | ||
| * eP: I think we may have had similar discussion previously — for use case to be realistic, it needs to come from specific vertical/domain. If there are similar verticals, there will be overlap. | ||
| * LD: Also, relation between a Use Case and what you try to address in a roadmap. One thing that would be interesting is if the CG tries to bring together or clean up UCR that could be used as start point by WG. Right now, we just have scattered our resources on UCR, but no true source. Either need to start anew in WG or get input from CG that would be greatly appreciated. | ||
| * eP: Suggest a clean up on UCR and add links, etc., on path/agenda. Few places where use cases have info. Everyone reviews over next week, then next week, discuss how to compile into one document and share with WG. | ||
| * VB: Suggest not meeting Wednesday, as it's TPAC. Discuss this topic the week after? | ||
| * eP: Don't mind having 2 meetings as not travelling but others might be. | ||
| * LD: Yes, difficult next week. Don't have to be present but would like to join. | ||
| * VB: Best to skip so have people's undivided attentions. | ||
| * eP: Agree to have this discussion in 2 weeks. Could be opportunity next week to get input on use cases from people present during TPAC. | ||
| * VB: Sounds great — plese add to the agenda. | ||
| * MdJ: Would be amazing to ask them to add, but I think we have more use cases than we can serve, so main effort is to document and label, so when we have a discussion, we can refer to them. | ||
| * LD: Looking forward to working on this and starting from a good basis of UCR. | ||
| * eP: Impression on approaching use cases in the past — use cases should not suggest a specific solution, they should just describe the problem. | ||
| * TBL: SolidOS accumulated over many years. How should we connect the scheduling and calendar together? The way things connect in Solid is really interesting to keep track of, as that is where Solid delivers value. | ||
| * eP: With Hadrian, met with Data Food Consortium, to say there are existing applications that would benefit from Solid, so don't need new use cases, i.e., extract from what exists, than imagine new things. | ||
|
|
||
|
|
||
| ### Solid catalog | ||
|
|
||
| URL: https://github.com/solid-contrib/catalog | ||
| URL: https://github.com/elf-pavlik/solid-efforts | ||
|
|
||
| eP: I plan to merge the dataset used by solid-effort into the catalog. | ||
| eP: We will have two different apps using it — Jeff's webcomponents-based one and the Vue + LDO I started prototyping. | ||
| eP: Let's meet next week for focused discussion. We can also invite people to explore and PR their efforts/initiatives during TPAC. | ||
| JZ: I'd like to demo the catalog and say a bit about its intention. | ||
| JZ: Some people have seen this, so apologies for that. Re intention, relation to what this is. Think about names for what we are doing — eP called his Solid Efforts (what people already involved in Solid have done). JZ is Solid resources (what anyone in Solid can use). Different approaches to the same thing — this one about supporting bigger community, etc., that need to focus on the practicality and what is occurring in the community vs. how things theoretically fit together. Think important to head in this direction as well as direction eP is going in. | ||
| * Based on RDF data source, and uses web components to draw information out. Everything is based on an RDF SHACL file and a set of sub-classes. All of the major categories seen in 'table contents' and the tabs are derived from classes of the major types that are used. The idea is that for each kind of service, we have the name, type of thing, and links that go outside of the catalogue and highlighted like the service endpoint. This brings you to Inrupt pod sources. If looking at ESF, then can see it is used by Inrupt pod spaces, and then see it uses Solid server. For subcategories, we're going to need to figure out what the main things we use are, and talk about how people can find them. | ||
| * Have subcategories of things within communication channels. Have forum, chat, and mailing list all represented. This call and others listed. | ||
| * Category 'services for specific communities' — i.e., have dedicated pod server (there are many). Each presents a pod for a particular set of users. | ||
| * Servers not done yet but will include keywords, etc. | ||
| * If wanted to look at only calendars, then can show calendar apps. If wanted to look at 'bookmarks', then shows number of different bookmark apps. | ||
| * Can do a full text or fielded search. | ||
| * Developer tools — need to figure out how to sub categorise them. | ||
| * Specifications — and vocabularies — each section will have its own shape. | ||
| * Resources offered — was tracked at one point on solidproject.org. | ||
| * eP: Great work, happy to see it. Follow-up would be to meet up with others interested to join the conversation to discuss next steps. | ||
| * JZ: Excited about work you are doing so will have one RDF data source and multiple applications that spin off of that |