Meeting minutes
Introductions and announcements
balessan: Representing startin'blox, just joined w3c as official member, have been following Solid for a few years, building applications on top of parts of the specification, interested in contributing to the WG. Also involved in the data space ecosystem, at the technical level.
Status of UC document editors
hadrian: Action item of last week on liaising with other communities
hadrian: Did this with the Solid CG, already few use cases
hadrian: Will reach out to CCG this week
hadrian: Had a very good conversation with people in hospitality, very interesting use cases
hadrian: We already have quite a few use cases, this is very good.
hadrian: pchampin you suggested to already add an empty document for the WG note on use cases. I support this suggestion but might need some help.
hadrian: With respect to the use cases, there are a lot of commonalities
hadrian: They mostly reflect one angle: what the user will do with the protocol.
hadrian: The cases don't really reflect operational properties, e.g. I would like to discover providers, ...
hadrian: They might be user stories, but I have struggled with how we can approach this
hadrian: I was looking at how we can distill requirements from use cases
hadrian: It is not clear how we can distill requirements at this point
hadrian: Any questions?
ericP: Do you have the latitude you need to edit this document efficiently
hadrian: Do not feel any blockers right now.
hadrian: I don't think we need five days like TallTed suggested for reviews of use cases
ericP: We need to move quickly, and don't want to hamper people on unnecessary process
TallTed: The reason I asked for this five days is that creating a PR is a heavier lift than putting in some change requests on an existing PR
TallTed: This gets heavier as more corrections need to be made, requires a lot more thought
TallTed: The gist is not that the document is not touchable, but just that requesting changes on PR is simpler
timbl_: Authenticating should be pluggable, we want new ways of authentication to be usable when they come out
timbl_: Is that a use case or constraint?
<ericP> +1 to making that a use case
timbl_: It's higher level than a use case
timbl_: But architecturally it is important to consider
<Zakim> timbl_, you wanted to say that in fact there had been an architectural rule that ID and the rest of solid should be very flexibly connected -- but is that a use case?
ericP: I was asking if hadrian can be agile enough on this work item
ericP: does anyone have any questions for hadrian?
<TallTed> "As (an app user? a Solid server administrator?), I want to be able to change my authentication provider (a/k/a IdP) nearly at-will, i.e., the authentication layer should be loosely coupled"?
pchampin: I would be happy to support publishing the document offline
… We need a group decision to publish a first working draft of the use cases document
… once we have this empty skeleton of a document we can vote on publishing it
… The automation requires a different group decision for automatic publication.
<Zakim> ericP, you wanted to say that there's only one chance to make a first impression
pchampin: We first need a very first version of this, I will discuss this with hadrian.
<TallTed> (changing authentication layers raises the question of how authorization is handled)
ericP: The idea of publishing an empty document might not give a good first impression. Might be best to have a few initial use cases.
hadrian: We can choose a few initial use cases from what we have already
… will take it offline with pchampin
csarven: Are we going to have an editor's draft of this document (the use cases note)
… Unsure what it is called right now, there were some name changes. "Draft Note" I think ( https://
ericP: In the old days you would have an editor's draft
ericP: And at some interval you would have the WG review the document and cut a draft
ericP: After review that would be published under /TR
ericP: The world has become more dynamic, so nowadays you can have no delta between editor's draft and latest working draft on W3C TR site
… Another option is that we let the editor work for a while
… and then at some point we cut this draft. And then publish intentional drafts after some review period.
… What we have to think about is how we want to operate until we have a working draft. And what we want to do after that
… We are not stuck with our choice afterwards.
… Hadrian will make PRs. The git tooling will display the HTML diff of that, so the rendering as well as the code.
… And then we will have five days to make editorial changes and things like that
<TallTed> echidna pronunciation
ericP: Are we using bikeshed or respec?
hadrian: I do not have a preference
ericP: I would use respec
<pchampin> publication rules (testing service and link to doc): https://
<bumblefudge> as one casual observer/very-occasional-contributor, i also have a mild preference for ReSpec (devil I already know)
ericP: Hadrian will do PR's
ericP: when we decide to make a first public working draft we will have a week of review period
… it is also W3C process, so you can find it over there as well.
… We should work with hadrian to navigate this process.
hadrian: With respect to publishing we could use tags to indicate the published versions
hadrian: I think that helps to tweak the process
<Zakim> jacoscaz, you wanted to ask about the process of reviewing / evaluating / accepting / rejecting use cases and how it relates to the draft we're discussing
jacoscaz: Apologies if I missed this, what's the relation between the draft document and the overall process of evaluating use cases?
ericP: Right now we are not committing to use cases
ericP: The process by which we will accept use cases will have to evolve, for example some indication of "acceptance"
… I would not want to prevent writing use cases
… on speculation of what we want as requirements of the specification.
jacoscaz: I was wondering if this is just the process of submitting use cases and then accepting them later on
ericP: I would publish a lot of use cases, with indication these have or have not yet been accepted
jacoscaz: Sounds good
hadrian: Very quickly, we are going to build the spec off of requirements
… By building list of requirements we will decide if use case is accepted, and covers the use case
<Zakim> csarven, you wanted to discuss Draft Note / Group Note Draft / DNOTE
csarven: I want to clarify a few things on the type of document that we intend to publish
<csarven> The UC document falls under the Note Track: https://
csarven: per charter this use case document falls under the note track per the W3C process
<csarven> e.g., https://
csarven: so this should be either a Note or Draft Note as the document that can be published
… there's no such thing as a FPWD
… like what you would have in e.g. a recommendation track.
… There's a possibility that we could treat an editor's draft of this, as a scratch pad of what may be published later.
… Editors could start from an ED which does not have expectations from the WG or W3C community
… Recommendation track has things like IPR and more expectations from W3C community
ericP: pchampin is there anything process related we should respect?
pchampin: FPWD does not apply here
… Eric was describing the old style process, via the TR which is automated and synchronized with merges on main branch
… Whether we want this tight integration with what is published on TR and main branch should be decided.
… The use case document is meant to be on the note track
<Zakim> TallTed, you wanted to suggest a review of *current* W3C process by chairs & editors, assisted/facilitated by staff contact
TallTed: I would suggest a separate session between chairs and staff contact, as well as the current editors.
<bumblefudge> +1
TallTed: not all of us need to go into detail on this.
bumblefudge: I agree that the whole WG meetings should be used for contents of the use cases.
… Even if there wasn't much ready for review, even informal review of some issues on github might be useful.
pchampin: Could we go back to the introductions and announcements. Because I have a small announcement.
Introductions and announcements
<pchampin> https://
pchampin: I just wanted to inform you that I created a github project as a dashboard for the WG at https://
pchampin: This is to centralize issues and PR's
… allows us to sort and slice this in different ways
… I created a few views, but we can fine tune these
… I manually added the PR's that already existed.
TallTed: It is not useful for bringing attention to what needs to be prioritized
… has been a feature request with Github for five years.
Default minutes approval
ericP: To remind you that at the next meeting the minutes of the previous meeting are automatically approved (after 1 week)
<pchampin> https://
Pending Action Items -- taken up
<pchampin> https://
laurens: i saw announcements go past. i think we just have one open action on pchampin
pchampin: there is a link from the summary to the repo and the protocol repo
… we might want to point to the editor's draft
<Zakim> jacoscaz, you wanted to mention questions on Gitter
jacoscaz: Just to mention that as I was reaching out on Gitter, some people reached out in private
… as to the relation between CG, WG and ODI.
… I didn't have an answer myself.
… We don't need to address this today, but could discuss this next week.
… Do we know how these entities are going to cooperate?
jeswr: At present, ODI is not a member of the LWS WG nor a W3C member. So no official relationship.
… I am here in my Oxford capacity.
… ODI currently supports the community resources, e.g. solidcommunity.net, Github organization for Solid, ...
… There is no official relationship between ODI and the Solid CG. This will probably be administrative support and in development of client-client specifications.
… The governance structure for interacting with the community is still being established.
… ODI is a support structure and facilitator for the community.
… Might be good to discuss this in another WG meeting.
ericP: As a request for next week, can everyone look at their holiday plans and have that in mind by next week.
csarven: Minor remark on the tooling to write the spec and publishing
… the W3C does not require a specific tool, as long as it conforms to the rules
… You can use any tool, respec and bikeshed are quite popular. But there are other tools.
… It often comes down to editor's preferences. I suggest we leave it at that.
ericP: Let's close for today.