Meeting minutes
laurens: 4 topics, first is establishing categories for use cases
… propose doing this with GH labels
… currently have some topics labelled as needs discussion, need to work out how to schedule meetings with relevant people
bendm: How do we link to requirements from use cases
laurens: We will identify high level categories from use cases. Requirements will then come from the categories.
… This is as discussed by the chairs, but process can be updated based on feedback from other WG members
laurens: The ultimate goal is to distill requirements
Establish categories for use cases
laurens: Brings us to agenda item establishing categories from use cases
… There are 2 aims, identifying categories from use cases and getting a set of requirements from each category.
<laurens> laurens: Possible categories include
<laurens> Authentication
<laurens> Authorization
<laurens> Notifications
<laurens> Data Management
<laurens> Data Discovery
<acoburn> Use cases repo
laurens: This is just an initial set of categories.
… Data Management is about interfaces for reads and writes
… some use cases also touch upon different types of interfaces such as streaming data
hadrian: We have a good critical mass of use cases now
… Quite a few are duplicates already
… I like the labels proposal but have questions.
… The README defines 3-4 categories, e.g. functional, non-functional. The ones proposed are mostly non-functional
… but some are also related to infrastructure tasks
… Do we want to use categories and sub-categories here to put the categories like laurens has into the categories of the readme
… I understand we want to go to requirements as the end goal. But do we want to come up with an interim stage of defining use cases and user-stories and then put those into requirements
… and how do we close issues that have been triaged
laurens: The listed categories in the README are useful but too high level
… we either need to refine them
… some are also overlapping
… and we need to identify what areas of use cases you can get from user stories
<Zakim> csarven, you wanted to mention 1) Consider adding "Protocol" as a category 2) Introduce "Status" as a label, e.g., https://
csarven: One label you want to add is protocol, which won't fit into the categories listed
… This would be primarily HTTP stuff that does the primary read/write stuff of the server
… The other point. The Solid CG specification has a status label https://
… such labels help decide e.g. if we have waited long enough to close an issue if a commentor has not responded in a sufficient period
… Other status' would include "needs process help" to pull in pierre-antione for input
<laurens> q,
<bendm> +1 on using status
hadrian: status is a good way to decide when to close issues. I wonder if we can make a decision on doing this today
… The current categories we have in the README address only one dimension which is target audience
… some will be app developers, other will be server maintainers etc.
… Everything we discuss and decide around categories here today will also be reflected in the readme
laurens: I like the status proposal
bendm: I am confused about target audience. I thought categories were about technical requirements which servers and clients implement
hadrian: The target audience is important. Consider portability, if the target audience is the user, and the requirement is to take data from one provider to another that works. However for this to happen - there is a need for the providers in the background to have a protocol for sending data from one provider to another provider.
… Consider what banks do, some parts of the protocol don't involve the people that write cheques - some data is just sent directly between banks
bendm: I would then expect that the use case would be data management and the requirement would be data portability protocol
<csarven> My password: *********
csarven: I like this topic, but I think it is just about labels and what data we want to track about use-cases. Target audience is interesting if you want to keep track of that
… if the group thinks here is a portion of use cases including different actors or roles, e.g., authors and here is a portion of use cases for implementors and wants to make it easy to look up by those categories
<Zakim> broadly, you wanted to discuss labels: approach from the point of the kind of data we want to track
csarven: we also want to consider the priority of constituencies which is defined as the W3C Web Platform Design Principles.
… ie is a use-case largely defined for the benefit of users, spec editors, implementors etc
… now is a good time to mark that, because in the future it will be forgotten
… we should identify who the use-case is helping
… and we should track information such as whether the proposer is planning to implement the use case
… or are they sharing it on behalf of someone else
… at some point we need to decide which use-cases we are not going to finish within the lifetime of this particular charter
… some of that information can be gleamed by labelling these
laurens: The goal from my side is to enable use as a working group to produce a future spec
… we are asking other people submit use cases which we won't necessarily pick up, so we can't ask make submitters of those use cases to implement it either
… though it might be useful to ask those submitting use cases to indicate whether they are implementing this feature, or need the feature for the use case they are working on
<laurens> PROPOSAL: We will track the status of issues in lws-ucs repo with labels cfr. https://
<laurens> +1
<jeswr> +1
<acoburn> +1
<AZ> +1
<bendm> +1
<uvdsl> +1
<ericP> +1
<hadrian> +1
<eBremer> +1
<pchampin> +1
<TallTed> +1
ACTION: hadrian to apply statuses as labels to the lws-ucs repo
<gb> Created action #10
bendm: For the categorisation is that a next point?
RESOLUTION: We will track the status of issues in lws-ucs repo with labels cfr. https://
laurens: I would be interested to hear another concrete proposal of which categories we should take up - or further distill some subcategories from the readme
<TallTed> (usually chair prerogative, but to keep it near the votes)
hadrian: Yes my proposal is to open an issue in which to discuss the categories async for approx. 1 week
… then will create a PR
… From an editorial perspective I have question. Should we point from the spec to all the use cases in the git repo - I don't know how this fits in the W3C culture
laurens: Use cases document will be an output of this group, needs to live outside the GH repo afterwards and thus be a self contained document and reference from the spec
… I don't know if the back referencing from the use-cases working group to the spec is something we want to pick up
… I see it as an equal output to the protocol doc, but protocol doc will probably become our primary focus in a few weeks time
<laurens> PROPOSAL: Do we open an issue on categories categories in the lws-ucs repo, and discuss async for 1 week?
<laurens> +1
<jeswr> +1
<acoburn> +1
<ericP> +1
<hadrian> +1
<pchampin> +1
<AZ> +1
<ryey> +1
<TallTed> +1
<bendm> +a
<bendm> +1
<eBremer> +1
RESOLUTION: open an issue on categories in the lws-ucs repo, and discuss async for 1 week
ACTION: laurens to open issue in lws-ucs repo on categorization
<gb> Created action #9
<Zakim> ericP, you wanted to address W3C culture around UC&R docs
ericP: Historically, UC&R docs guide WG in their decisions and are not vanity pieces
… if we had use cases that were redundant we would remove them
<TallTed> Use Cases expose Requirements which are then addressed by the Specification
ericP: where possible we would use a single story and derive different use-cases / theses from that story
… I also think it is reasonable to point at the issues so people can track them back
… but not required
pchampin Hadrians question was can we just point to the issue rather than re-phrasing them in the note.
<ericP> +1 to including the user story in the UC&R doc
pchampin: also note that the working group note is not normative so not with same stand as the specification document
<Zakim> csarven, you wanted to discuss UC Note editorial and alignment with Issues
csarven: Yes you can point back to the note so you can cite back to it. But agree with pchampin that we should not just use the issues because different people write the issues up in different ways - having them re-written will create consistency and make them easier to read
… Many of us are proposing different use cases - I assume we are aligned within our own proposals but they are not aligned across proposals
hadrian: I think we all agree that requirements must be in the final note. Do we want to have user stories or use cases in the UC&R document?
… my preference would be to have use cases in the note, and point to user stories in the GH repo that informed them
… alternatively, we could create a final user story that would be the basis for pointing out the duplicates and having a consistent style
laurens: This is a useful discussion, we need to discuss whether we want to have user stories in the full-blown way we have received them. It is going to be very difficult to make consistent
"Needs Discussion" label
laurens: We still have a couple of issues labelled as "Needs Discussion"
… How should we proceed with these
… is it an action on Hadrians side to ask those people to join the WG meeting
hadrian: I don't know, but I know identity is what we need to discuss
laurens: I think this should be defined by categorisation and then plan ahead in the agenda to bring people in
hadrian: I can prioritise the labels part, should we prioritise those needing discussion in the next meetings?
laurens: No, we should go by category in a particular meeting so we can bring people in with warning
hadrian: By next week should I have categorised the needs discussion points
laurens: yes
ACTION: hadrian to add categorization to the needs discussion labeled issues
<gb> Created action #11
csarven: It is unclear why some are "needs discussion", shouldn't they all be
hadrian: some we may reach lazy consensus in the issue and not need time in the meeting
… needs discussion is where they have diverging view and need discussion in the meeting