# W3C Solid Community Group: Weekly

* Date: 2023-11-01T14: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
* [Sarven Capadisli](https://csarven.ca/#i)
* Aaron Coburn
* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
* Hadrian Zbarcea (Inrupt)
* Eric Jahn
* Vivien Kraus
* [Ted Thibodeau](https://github.com/TallTed/) ([OpenLink Software](https://www.openlinksw.com/)) (he/him)
* TimBL

---

## 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
* Aaron Coburn

### Introductions
* Eric Jahn: My main perspective is the need for consent sharing. That would be patient or human services client.
* Vivian: I’m interested in interoperability on the web, and I think RDF is the way to go.

---

## 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: plan to record some screencasts. Still missing some labels for storage; does anyone remember the best UI label for storages (e.g. a social agent interacting with multiple storages and wants to be able to distinguish)
* SC: dcterms is one possibility
* ...: when all else fails, when there is no human readable label, you could derive it from the URI path (or fragment, if relevant), for instance the last path component, convert non-ASCII characters (e.g. dashes)
* eP: if a client doesn't have public access to the root of a storage, what would be the best location for making this information available? Can we rely on the Storage Description?
* SC: from an implementer's side, if it's specified, use that. But if the resource isn't self-describing (e.g. Forbidden) you can look for a describedby property; failing that, look at the URI
* AC: If root of the storage is not public, and put labels about the storage in there, how can an agent find it? I'd take one step back. Discovery re storage, and put the label in the place, e.g. ,here are my storages, and the label could be found there too.
* eP: for now, I think I'll just use the full URL of the storage and from there we can find the storage description. This topic might be too far into the weeds for this meeting, but I'll create an issue with this use case and document it in that issue. We can continue the discussion there
* SC: This discussion isn't unique to the storage resource. AC's suggestion could also be applied to containers. E.g the container description could hold those labels
* ...: For those items that have been spec'd we could say something, but there may also be other cases
* eP: we may want to consider different permission levels for container description vs. listing contained resources. This is a somewhat bigger topic, so perhaps we can save further discussion for later. Keeping in mind a resource level access control in solid.
* SC: This conv. (and many similar) would be great in a best practices document

### Special Topic Meetings
URL: https://github.com/solid/specification/discussions/555

* SC: Joint meeting with Social CG. Propose for the week of 2023-11-13 or later? Tuesday (some preference for this) or Friday 16:00 UTC okay?
* Upcoming
* Solid-OIDC
* Solid and Social CG (their mtgs are on Fridays @ 1600 UTC). Should we use Tues 1600 UTC or Friday 1600 UTC. Some indication from Solid CG would be good, that way SC could get back to the Social CG
* eP: how about an online poll?
* SC: will start an agenda
* MdJ: would like to propose a special topic meeting related to OAuth and UMA
* MdJ: Is this orthoganal to WAC/ACP?
* MdJ: Should the two systems live side-by-side?
* eP: SAI doesn't have a hard dependency on WAC/ACP. If a resource server can operate on a higher level, then it can be independent
* SC: let's have a special topic meeting on this; we will need to pick a date and should give priority to scheduling the Social CG group
* ...: Please jot down a title for the discussion and SC can add this to the list
* eP: In SAI Access Authorizations (build with Data Authorizations) are the single source of truth, based on them Access Grants (build with Data Grants) can be generated. As well as ACP rules, but ACP can't be directly changed since they are not the single source of truth.

### W3C Solid WG Charter Proposal

### conduct issue
URL: https://github.com/solid/solid-wg-charter/issues/55

* SC: Consensus may have been reached. Any objection to closing this issue? Indicate decision in comment and mark as 'waiting for commenter'.
* ...: no reaction on the proposal to close from creator. Also noting that the issue is off topic.
* eP: unless there are objections in this meeting, I think we can close the issue now; it can always be reopened if necessary
* SC: Objections to close?
* AC: (notes no objection)

RESOLUTION: Close issue.

#### clarify scope
URL: https://github.com/solid/solid-wg-charter/pull/62

* SC: Please review.
* ...: this is a new PR and would like to give everyone a chance to review
* ...: once reviewed, issues will be assigned to PA to merge

#### clarify the handling of low-maturity normative references
URL: https://github.com/solid/solid-wg-charter/pull/63

* SC: Please review.
* AC: (see notes above, as they apply here, too)

### Add section on decisions and processing-pull-requests
URL: https://github.com/solid/specification/pull/590

* SC: Further details decisions and processing PRs based on https://www.w3.org/2023/Process-20230612/#correction-classes
* ...: e.g. "editorial", "substantive changes"
* ...: it would be helpful to map PRs to these categories. "Editorial" would be at the discretion of the editor. Substantive PRs must be issued as PRs
* ...: we need rough expectations about the amount of time to respond to PRs
* ...: the above mentioned PR indicates some general expectations for this process. Please comment on that proposal
* eP: This is the CONTRIBUTING.md document of the Solid protocol, but as the Solid Protocol will move to the WG, what will be the use of this document for the CG?
* ...: Will there be links from other documents to this location?
* SC: There will be a CG-specific repository and all work in scope for the CG will apply to those expectations
* ...: at present, the Solid specification repo serves multiple purposes
* eP: assume that the WG is created and the protocol moves to the WG, for those CG items (e.g. SAI) will they link to this contributing guide?
* SC: Yes
* eP: so every repo in scope for the CG would need to link to this global contributing guide?
* SC: Yes, this would cover all work items in the CG
* SC: The Solid Protocol isn't moving until the WG is sorted out
* ...: Often, when a WG finishes, a CG picks up all follow-on work (e.g., errata, new features for incubation, etc.)
* eP: once the WG is created, will there be one repo in [@w3c github org](https://github.com/w3c/), or will there be one repo per draft?
* AC: There are different patterns for different WGs. A lot of them have single repos. Depends on how tightly coupled they are. Don't really know until when things start. Will see if need multiple repos or single.
* AC: re processing, when should CG members review this?

ACTION: Please review this PR by Nov 15

### Solid CG Chair Election Procedure
URL: https://github.com/solid/specification/discussions/582

* SC: https://github.com/virginiaBalseiro/solid-ecosystem-monitor/ now includes code using W3C API (see `node-w3capi` directory) towards helping with the election process, in particular determining eligible voters. This data will be passed to W3C Staff for the questionnaire/verifying results. Will add more documentation. Run `npm install` and `node index.js`. Try not to generate too often, W3C and Cloudflare seems to rate limit (429) or other issues (520).
* SC: There is the possibility that some organisations may not respond to the call on having one representative for putting their ballot, and more than one participant with the same affiliation may vote. To work around this, simple solution: take the vote from the participant that has their name earlier in alphabetical order.
* ...: each org will have one representative that will vote
* ...: W3C staff will assist with the processing of results
* ...: For orgs that don't respond, identifying which representative will vote, we will provide an ordered list of participants. In that case, if both A and B vote on behalf of that org, then A's vote will be counted
* ...: Code can be reviewed; we need to ensure that there are no bugs
* ...: orgs will be ordered by number of participants; those with more than one will be mentioned on the mailing list so that a representative can be named
* eP: another option may be to work with W3C to enforce certain authorization rules within their system. There are ways to accomplish this, but it will likely be a lot of manual work. Personally, I don't see a problem with this type of enforcement
* ...: I don't want to bite off to much with this process
* SC: we're using as much as we can, given what W3C offers
* ...: The questionaire is limited to CG participants. The W3C is curious to see how this will work with a CG
* ...: Other CGs have a similar process
* ...: The W3C will announce the winners on the mailing list
* ...: We use W3C infrastructure to take advantage of existing W3C accounts
* AC: I was wondering if you have a timeframe in mind for when we will initiate voting.
* SC: once we have elegible voters ready. Let's say within 1 week to announce to mailing list
* AC: I find it helpful if we have dates, we've been talking about the vote for a while now.
* SC: I think this is the same issue as we had with spec releases.
* AC: From my own experience I'm really confused when it comes to the timeframe. A lot of folks would love to see it happen. Many folks already nominated themselves. If we have some dates it would be a good motivation to make it happen.
* SC: Agree with you but dates haven't been particularly helpful in a number of cases, as in there is apathy or accountability in the CG.
* TBL: CG process historically was ..., people don't come to the meetings because...,
* SC: When I made PR to release SP v0.10 only Kjetilk reviewed it on time. It wasn't just about "CG process". You say things are bureaucratic sometimes but tell me what prevent people, including the co-editors to review that in the first place for example? And ditto Solid-OIDC issues that I've created that the editors did not take on entirely - issues still sitting around. I can't fire editors in the CG or something. Then what? How about the CG charter? People that have opinions on it from the sidelines literally did not contribute. One shouldn't complain about process if they're not contributing when they had all the time in the world and chance to do so in the first place.
* eP: someone could invite 10-15 people to the CG as individual contributors today. it is easy to game the system. We shouldn't try to over-engineer the system
* SC: Right. It is also taking advantage of W3C infra and support as much as possible.
* AC: I feel like the conversation is going in a lot of different directions. Dates about previous releases of spec and editors doesn't seem to be in place. I'm just asking about expectations for the vote, talking about all the history doesn't help. We should just have a timeframe.
* ...: By the 15th of November we will have the list of candidates and start voting?
* SC: No we can start nomination period after 15th, two weeks after that we could vote so Nov 29th.
* AC: I think we already had good list of candidates. We could have process of nomination in paralel.
* SC: We wrote down the process and asked for feedback on the process. It feels like asking to change it in the last minute. I want to make an announcement to invite people to nominate themselves.
* MdJ: Aren't the participants of the CG eligible candidates?
* SC: Not everyone, if a company is affiliated with more people, ...
* TBL: I see it examle of being overly bureaucratic, the process may not be perfect ...
* SC: Maybe we can shorten it one week, I'm hoping that we can have the eligible list sorted out soon.
* TBL: Why do you need to have it sorted out before you send the call for nominations?
* SC: The idea is that those who are nominating are eligible.
* MdJ: If you get 2 candidates from the same company they could just need to choose one
* TBL: everyone can nominate...
* AC: I know that Pavlik had tentative nomination, I would like to nominate him. Whatever process is relevant I would like to do that. Processes are great, they should clarify how things supposed to happen. When I look at the process for voting I'm just confused. For me that seems like something is not working there.
* ...: In my experience, when there is confusion about something, I would see a leader coming to help clarifying it.
* SC: We haven't come to determine the list of eligible participants. The process I came up with was coordinated with W3C staff. I'm happy to improve the process.
* AC: I think there are 2 levels of clarity, one is something written down. But also ensuring that it happens in undenstandable way is also important.
* eP: it sounds like we can have this running in parallel. But that process is locked so it may be hard to modify
* MdJ: I'm ok with waiting another 2 weeks if needed
* AC: It's fine with me, that's the first time I hear a concrete dates.
*

### Align shared core terminology
URL: https://github.com/solid/specification/discussions/557

* SC: The discussion served its purpose (but we can improve as suggested by Ted). We should considering convert this to issues and/or PRs. And try to cover them for the next releases of the specs.

### i18n and l11n of resource identifiers
URL: https://github.com/solid/specification/pull/575

* SC: All, please review.
* SC: Didn't get a chance to review but very interested in us getting this (in one shape or another) into 0.11.0.

### Please review CG Report requirements
URL: https://github.com/solid/specification/issues/587

* SC: Concerns releasing CG-DRAFT/FINALs.
* SC: See also next topic re Solid Protocol v0.11.0

### Solid Protocol Version 0.11.0
URL: https://github.com/solid/specification/milestone/7

* SC: Let's make sure to add any missing issues/PRs that can reasonably make it into this release. The ED includes class 3 and higher changes, and some in the pipeline. See [Solid Protocol ED Changelog](https://solidproject.org/ED/protocol#changelog).
* SC: Unless there is new information to discuss, I suggest we keep this topic short and only for awareness.