Meeting minutes
Introductions and announcements
acoburn: One announcement, we're all in daylight savings, so scheduling should be back to normal
… anything else?
Action items
(nothing)
acoburn: Action items, weekly update on the UCS issues repo
hadrian: Issues w3c/lws-ucs#122 and w3c/lws-ucs#125 have been closed
Charter schedule
acoburn: According to our charter, we're behind schedule
… I wanted to go through roles and responsibilities
… Hadrian is editing use cases and requirements. We'll soon move to the main protocol documents
… We want editors to have autonomy and be able to work efficiently
pchampin: We had similar discussion a few weeks ago in the RDF-Star WG
… PRs are made in the open, by editors or anyone else
… The issue we had in RDF-Star is long discussions in PRs that didn't converge, so we had lots of pending PRs
… Editors are the owners of the document, they should feel entitled to merge PRs, even if not all points of discussion have been resolved
… Merging a PR can result in issues being raised if not all points have been resolved
… Editors are expected to respond to comments, but they can defer until after merging a PR
tallted: There are a lot of English-isms that foreign speakers my not understand
… Editors merging PRs happens often, with my disagreement
… If PRs are merged, the issues should not be marked as resolved in the PR thread
… It's difficult as participant to keep track of which comments were made, and have been resolved or not
… It makes a big difference to know that things aren't being closed out of hand
… Rather than clicking the Resolve button, putting in a comment to explain helps
pchampin: +1 tallted, important to have transparency and traceability
… So don't mark Resolved, so we can still see what's pending
… If we use Echidna, it will turn every merge into a new public WD. But these WDs aren't expected to reflect group consensus
… This speaks in favour of giving editors autonomy while allowing unresolved issues to be solved later
csarven: I'm not so concerned about whether a PR is merged by the editor. Depends on the status of the document. We can go faster this way up to FPWD, I'm OK with it
… Also things like making sure requirements relate to use cases
<acoburn> rrsagent: make minutes
csarven: We could put energy into doing that yet, or wait to FPWD
… We may be able to save time. But I want concrete agreement on which option we're going with
… We need to review things, and make sure it's what we agreed on
… When we're writing the spec, if this has FPWD, the members will review it. If the paperwork isn't aligned, it becomes a target for objections
… I believe that will come up. Some people aren't in favour of what this WG is doing
… Editors should feel comfortable to move forward as best they can, but needs to reflect group consensus
acoburn: So you're saying any WD should reflect WG consensus?
csarven: It's better to have more people on board at FPWD stage than find out at CR that there's disagreement
… So get early agreement as much as possible
<TallTed> FPWD starts the patent policy clock, among various other arcane things, and does not require the same level of consensus os CR or PR
hadrian: I agree with what's been said. Is there something we're trying to improve?
<Zakim> pchampin, you wanted to comment on consensus and WD
pchampin: To csarven's point, we're in general agreement. My point was we don't need to get consensus at the granularity of every WD, which changes with every PR with Echidna
… Not suggesting to wait for CR to see if we have consensus
… hadrian, I brought this up as it was necessary in the RDF-Star WG. At the moment, the way we've worked with the use case document is aligned with this way of working
<Zakim> ericP, you wanted to say that including issues inline in the doc makes it easy for readers/contributors see where there are disagreements and whether they are editorial
<TallTed> There is relevant ReSpec markup for issue inclusion, which includes a link to the issue on GitHub, among other things.
<Zakim> csarven, you wanted to mention correction classes and the role of the editor
<csarven> https://
csarven: Correction classes, this is a guideline, doesn't apply to every kind of document
… What works in my experience, if a PR says what kind of a change it is, it gives a heads up to reviewers
… A PR needs to explain what is the ask. Correction classes can be a good guide: e.g., adding a new feature - does it break anything, etc?
… If it adds a new use case, that's like adding a new feature
… The editor guide is useful. If editors feel it's faster to push things through, there'll be a moment when we can review it, that's a fair approach
… The time we're taking in meetings for use cases and requirements, should be reflected in PR with links to minutes
… It makes reviewing easier, leading to less confusion
… I just reviewed a PR earlier, I wanted to know where the requirements are coming from
… Lots of energy went into the PR, good to acknowledge that, the requirement is in scope and relevant for the protocol spec, and it links to the use case
… The rest is authoring level changes - does it accurately reflect the requirement?
<Zakim> ericP, you wanted to say that a measure of whether a change is substantial is whether it would change an implementation
csarven: Those two links are useful to read
ericp: A way to gauge if editorial or not is if it changes implementations
hadrian: Anybody can make additions to issues and PRs. But not everything can be solved asynchronously. I'm available if you or anyone wants to push things forwards
acoburn: I think we have consensus on where we want to go
… May be some details on the best path
… We want documents that reflect consensus, whether per-PR or at significant points in the lifecycle
… Other comments on this topic?
(nothing)
Use cases update
pchampin: One small thing, I haven't set up GitHub Pages on the use case document, to have the HTML rendered automatically
… I'll set it up, unless anyone objects?
(no objection)
acoburn: Go ahead
hadrian: pchampin and I discussed last week after the meeting. Everything I tried after that worked
… One thing is writing text vertically in the matrix
… If we have too many columns, we can split into multiple matrices based on categories
… I created a Miro board, should be ready to share next week
… I tried to use the same personas, and created some context so it's clearer in what context the use cases apply
… It's work in progress
… No pointer to the minutes though, and the other issue was about the glossary
… Any questions?
(nothing)
hadrian: I started looking into the consent part. Didn't have time to look into discovery, but it's high on my list
Clarify scope of portability use cases
acoburn: Could spend more time on consent, but want to look at other use cases than go deeper
hadrian: Portability is a big topic, would be good to gauge the group's opinion
… Portability refers to moving data between storage, or from a provider. Want to do it without breaking anything, or as little as possible
… Depending on the governance, it should not always be a required feature, a negotiation between a service provider and a user
… Some storages should not be moved outside a specific jurisdiction
… The user may not have complete control over the portability process, but the spec should allow that as much as possible
… Need to deal with identity. If the identifier is issued by the SP, that's OK, and you may get another identifier in the new SP
… Need something controlled by the user, to ensure continuity
… An alternative is to use self-sovereign identifiers, which would make it easier, but means dealing with discovery
tallted: This is where things start getting complex. I have question about the question being asked
… Identifiers are a challenging aspect of portable web storage
… The idea I have stuff on one provider, move it somewhere else, and have it still work. Requires use of portable identifiers instead of provider based identifiers
… purls and dids
… This is where portability of data structures becomes important. Maybe one provider only stores JPEGs or PNGs. Users will hit these things, the point of standardised structures so any application can work with your picture album
jeswr: In response to tallted, that we're necessitating ?? identifiers
… Suggest we ensure identifiers are portable, but not require that, so that whatever identity method we use, not restricting use of non-portable identifiers like web ids
… A meta comment, when we have these use case discussions in other groups, is there a structure that's followed to help get a written form of consensus faster?
pchampin: No straightfoward answer...
tallted: Same. A small WG could do it. It could be helpful to set up a structure, e.g., announcing which use case we'll discuss in a meeting, focus less on administrivia
… Then enable async communications so we don't have to do everything in a group call
<Zakim> csarven, you wanted to mention URI persistence, AWWW
tallted: F2F is more efficient
<csarven> https://
csarven: On portability, we need to be careful with the charter scope
… Whether the protocol is covering things around the interface, HTTP is the key candidate, there may be others
… If describing other aspects of storage, e.g., whether encrypted, things behind the interaction
… HTTP for example hides those details
… How representations are stored is up to the implementation
… If the representation is expressed using relative URLs or has a particular way of referring to things, from one lens, that could be fine, but from another we could constrain it to use absolute URIs or have canonicalization
… This ties into the web architecture's URI persistence
… If you put something on the web, announce a URI, there's a social agreement, you have the means to keep it up, the semantics of the resource. You can 404 or redirect to the new storage
<TallTed> "Cool URIs don't change," except that they do.
csarven: So the former owner of the URI can redirect to the new storage
… Whoever has authority of the URIs will make the call
… Need to clarify what level of the storage we're talking about. The protocol doesn't need to describe implementation details. It's the web architecture's description of persistence
hadrian: Web ids are portable provided you use your own domain
… Other solutions for portability is to have part of the URL, the path, that's controlled by the user, and part that's controlled by the service
… What do we want as a group? Jessie demonstrated this a few years ago with SOLID
tallted: A lot of these open questions that csarven and hadrian are highlighting, are part of the picture when discussing a use case
… Use case may be that you want images available at the same location for ever
… Capture these in the requirements area of a use case
<Zakim> ericP, you wanted to say that portable IDs, for individuals out resources, lean on a some shared resource
tallted: The use cases may have things that are common and things that are specific, e.g., storage and portability of the storage. Just needs hashing out
ericp: Any portability requires on a shared resource, could be DNS, a registry like purl.org which we've seen fail, a shared ledger
… In use cases need to figure out if we want portability when their data provider turns evil and they don't do the equivalent of a domain transfer
acoburn: there's more to discuss here. Want to see some more direction. Let's discuss additional details on this next week