# W3C Solid Community Group: Weekly

* Date: 2023-01-04T14: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)
* Jeff Waters
* [Ted Thibodeau](https://github.com/TallTed) (he/him) (OpenLinkSw.com)
* [Laurens Debackere (Digital Flanders)](https://github.com/laurensdeb)
* [Wouter Termont](https://github.com/woutermont)
* [Eric Jahn](https://alexandriaconsulting.com/files/eric_jahn.rdf#me)
* [Matthias Evering](https://solidweb.me/testpro/)
* [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me)
* April Daly
* [Arthur Joppart](https://github.com/belgiannoise)
* [Michael Herman (@web7arch)](https://twitter.com/web7arch)

---

## 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
* April Daly

### Introductions
* Skipped - all participants have attended this group meeting in the past.

---

## Topics

### Index and Registry
* SC: Registry as per W3C Process: https://www.w3.org/2021/Process-20211102/#registry
* SC: In order to document collections of values or other data that TRs use, a separate document can be published. For example, https://solidproject.org/TR/notifications-protocol refers to https://solidproject.org/TR/notification-subscription-types (Living Document) where an index of subscription types can be found.
* SC: To date, the index document only listed documents published under `TR/`.
* SC: The notifications-panel also has https://github.com/solid/notifications/blob/main/README.md#subscription-types that lists all types.
* SC: Question: Would it be simpler to re-use https://solidproject.org/TR/ as the index for auxiliary documents (e.g., notification channel types), since it is intended to list all of the CG's Work Items? The "Indexing Procedure" can be part of TRs that need it.
* SC: Quick Overview: a document that would hold things that need to be registered and are typically dependent on other specifications. Notifications protocol allows auxiliary specs that define individual notification channel types, for example. Similar to [DID method approach](https://www.w3.org/TR/did-spec-registries/#did-methods).
* We have published web socket subscription type (with corresponding document under TR). Terminology has been changed, from *Subscription types* to *channel types*. It would be incorrect to rely on notification subscription types. If this approach is continued a new document set is needed.
* SC: Instead of recreating documents or reusing, we could use the solid/TR, regardless of maturity. The TR document would be the central document with links to all related documents.
* PC: Suggest W3C doesn't require a separate document, but this should be verified. Propose using the TR document as a registry of SOLID and related specifications. Registries could be considered different (i.e., entries of a given registry are homogeneous). A registry is defined by a process. The TR Index document list has a heterogeneous mix of documents. We could use that document to hold all the registries that are need, but it would be ideal if it structured.
* SC: We had an extensive talk regarding the Notifications Panel and a decision was to use the separate document. If we change names again, the TR space may become confusing. IS there quick fix for the TR? Any question or comments?
* SC: Would a section in the TR dedicated to registration channel types suffice?
* PC: yes, that is my proposal.
* SC: A decision now is not needed, but we can take this approach if the panel (the only users to date), we can use it. If there are other specs in the future we can take that route as well.
* SC: There are not other comments, we can move to the next topic.

### Add TR/2022/notifications-protocol-20221231
https://github.com/solid/specification/pull/491

* SC: Notifications Panel will create a new release. It is versioned at 0.2. Current version in TR is v0.1. The decision regarding numbering has breaking changes from v0.1. Since it is not a v1.0 release and there are not enough implementations and test suites, we held back on labeling version 1.0. We don't expect major changes moving forward (sans editorial changes).
* SC: It follows the guidelines in place. If you have editorial or normative request changes, please submit them in the [notifications repository](https://github.com/solid/notifications/). Changes should happen at the source, and they will be incorporated into the Solid repository at the appropriate time. The independent repositories are more for work environment related to the specific repository topic: https://github.com/solid/notifications
* SC: Question for the group: is this process reasonable?
* WT: +1
* PC: What is meant by process?
* SC: The process of using the specification-specific repository for the work environment and then creating a snapshot for publication under `https://solidproject.org/TR/` at solid/specification repository.
* SC: Change log is available on the Change Notifications protocols. Note the PR view and diff view. This also applies to the next TR we are about to cover. I would add that we have a charter for Notification Panel and a Charter date (last month), hence we have to extend the Charter date. If theory we can work on these indefinitely, but the Charter helps use communication our objectives, plans, and dates with the public, but we are not required to adhere to the dates specified. The Charter does help with the Notification Panel. This has helped use produce other specifications. We have Notifications Protocol, Web Sockets - overall 6 channel types with different editors, plus three more => 9 documents. The Charter helps for other related panels that don't have a Charter. Overall net positive.

### Add TR/2022/protocol-20221231
https://github.com/solid/specification/pull/492

* SC: Proposal to add the release version 0.10 of the Solid Protocol. Includes the change log since release 0.9 (approximately 1 year ago). Same repository context as previous TR discussed. TRs should be against the editors draft (https://solidproject.org/ED/protocol), not the specification document.

### Publishing Rules for Community Group Documents

* SC: We have not released a community group draft as recommend by W3C. There is a recommend W3C template, but it does not have community group branding. In the past this was a group decision to release the specs are they are as opposed to a community group draft. The question is: should we or do we need to do that for any spec that will be worked by the community group (e.g., Solid specification).
* WT: Is it just template/style issue, or a structure issue?
* SC: Mostly templating rules. Publishing, status, copyrights, patent policy, etc., differ. As far as content specific to the protocol/topic, that does not change.
* PC: Should we do that? I think no — it's not required. If the group is okay with the current approach, then it is okay. The most important aspect is copyrights, etc. The protocol specification already points to the content contributor rules. The Final Report needs to follow the rules of W3C, etc. It has the added benefit of published on the public W3C website.
* SC: we have solidproject.org/TR/. If and when the protocol is published it will be under w3c.org/TR/.
* PC: Wouldn't be placed under the appropriate date space rather than under TR?
* SC: That is a different report.
* SC: we have our own space, if the stars are aligned we will have out own solid server.
* SC: Next week we have the call, please propose topics. Regarding the calendar, please let me know about changes or new meanings towards repositories, please inform me and the calendar will be updated. The event will not be added to the calendar if we don't have agreement (i.e., reduce the noise)
* PC: It has been request to not end meetings at the top of the hour; it does not allow participants to transition to their next meetings in a timely fashion.
* SC: Agreed, We'll end the meetings about 5 minutes before the top of the hour.