Meeting minutes
<acoburn> open item 1
Introductions and announcements
acoburn: Checking new participants. No. In November, TPAC will take place in Japan. US timezone and Japan may make meetings difficult.
Pending action items
acoburn: For TPAC meetings, usually face-to-face, but also virtually. Ideally people can join, in person or remote.
… Anything still pending? Hadrian?
hadrian: Was at BBC. Added some details. Question 1: How do we triage an issue, and how do we close it?
… Item 2: wouter said he agrees with me, but I don't agree with myself.. We need to get a resolution.
acoburn: I think Item 2 is done already. Am I mistaken?
acoburn: Issue #10 in lws protocol
<gb> Action 10 apply statusses as labels to the lws-ucs repo (on hzbarcea) due 2025-01-13
<csarven> ryey, just use "XXX" as a thing that could be substituted.
<csarven> then we do `s/XXX/foo`
hadrian: I think it's mostly done, with one item needs further discussion.
acoburn: I would suggest we are going to talk about the labels in a minute. And we close this issue.
hadrian: You probably saw my comments previously. I think it can be closed.
acoburn: Closing it now.
Initial label set for user stories
acoburn: Hand over to Hadrien for user storie
hadrian: Authn and Auth are different. we should note this. I added the relevant labels. Labels are not exclusive.
… Question: when can I remove the triage from stories, and when should we close issues?
… Also another comment about keeping labels more coarse. I'm neutral to that.
acoburn: We will use labels to help categorize issues. We can start categorizing the issues already.
csarven: I think when we understand an issue well enough, we can remove triage. We don't need to worry to much for closing, as long as it's still relevant.
<bendm> +1 on csarvens comments
csarven: We just need a marker to denote we have already seen it and discussed it. Not necessary need to close it.
<Zakim> csarven, you wanted to suggest that no UC issue needs to be closed until much later e.g., when all issues are taken into account in the UC Note or postonned. Remove triage label when some specific labels are assigned (categorisation)
hadrian: One possibility is to allow issuer to remove triage mark. Otherwise it may be too difficult to manage.
acoburn: What if we leave the issue open, but if we agree the issue is well-disscussed, we remove triage.
hadrian: Yes. My question is: who should be responsible to remove the triage mark.
acoburn: Technically anyone can. I suggest editor can add/remove labels as appropriate. If it's not your issue, feel free to add labels.
hadrian: Thus I propose to add another label named "review", and assign it to original author. Give it 1-2 weeks. Then, move it to triage. If no response, close it.
acoburn: Writing that as a proposal
<acoburn> PROPOSED: add a new label, called "review", when the triage label is removed. Assign the issue to the author of the issue and provide 1-2 weeks for review
hadrian: I think that would satisfy anyone's needs
<TallTed> +1
hadrian: Yes, I second the written proposal
<hadrian> +1
<bendm> +1
<acoburn> +1
<balessan> +1
<laurens> +1
<ryey> +1
<kaefer3000> +1
<eBremer> +1
<jeswr> +0
RESOLUTION: add a new label, called "review", when the triage label is removed. Assign the issue to the author of the issue and provide 1-2 weeks for review
hadrian: Plus, anyone, if they are not satisfied with the assigned label, can change it
… This has addressed all my questions at the beginning of the call.
<acoburn> Proposal for labels
<gb> Issue 91 Categorization of user stories (by laurensdeb) [needs-discussion]
acoburn: For issue #91 in UCS repo. Can we do a quick poll for if we are happy with the current initial proposal? (Just a poll, not a resolution.)
<gb> Issue 91 not found
acoburn: (proposal by Hadrian)
bendm: We need the labels with descriptions
<TallTed> list of labels with descriptions
hadrian: Data management has to do with management of data. Infrastructure has to do with manage of system.
kaefer3000: In an issue, xxx3 is roughly equivalent to data management. I don't know if it's a misrepresentation.
hadrian: I think there is a difference. E.g. for portability, do we care about the underlying storage?
kaefer3000: I would say "data management" means "do we have a triple store, or file store"? Thus similar to infrastructure?
hadrian: Some people may still have issues, and there will still be some new proposals. But I think the current main item is whether the current category is a good start thing to use already or not.
csarven: Maybe we can expand the description of categories when needed. The issue author should also check if the assigned labels are indeed correct.
hadrian: Absolutely. Also, we should also add some links to README
<acoburn> csarven: yes, an initial list. not set in stone
csarven: I believe the list is not fixed. We will always update them. Point is: we use it to help us manage use cases. They are good starting points for me.
… If someone is assigned editor, they need to maintain uniformity. Hadrian should be in a better position to have the better say when needed.
TallTed: Agree current list is a good starting one to use, and we can refine things as we go.
kaefer3000: "Infrastructure" sounds to me like architecture, like what components we have. "Data management" sounds like what storage components are there. So somewhat non-clear, and needs clarification.
acoburn: It seems we generally agree the current list for now, and start using.
… Any further comments? No.
… We still have 10 minutes. we can start to add labels to some now, to do some demonstration.
… Hadrian, do you think we should try that now, or end early?
Discussing use cases
Data integration
<gb> Issue 46 [UC] Data integration across medical, fitness, dietary, medication data (by timbl) [triage] [usecase]
acoburn: Let try this one (#46).
<bendm> data management
acoburn: (Explained the issue content.) What kinds of labels do we want to add for it?
<bendm> authorization
<csarven> discovery + management
hadrian: I think many (e.g. authorization) are implicit and most use cases will be related to them. So we should add the most relevant ones.
<bendm> +1 on TallTed, that's why I'd add authorization
TallTed: This one may be extremely complex, if considering different laws. May not be a good starting point.
bendm: I think so, so I added authorization
<acoburn> eBremer
eBremer: I agree with TallTed. It's not the best thing we should start to tackle right now.
acoburn: I agree, but we should start to recognize that something are complicated. But we should always finish it in time-frame.
… Even if complex, we should still try to categorize it, to help us progress.
<csarven> s/tackle right now. And, probably out of scope./
<eBremer> +1 TallTed
TallTed: Maybe still start with simpler ones, with one or two categories, to better demonstrate. This one, for me, contains all categories (which may be a good thing in fact). I'm sure we will get there, but not right now.
Storage Description
<gb> Issue 21 [UC] Server / Storage Description (by csarven) [triage] [usecase]
acoburn: I agree. It may not be the best one to use now. Maybe alternatively try #21
… csarven, maybe you do it as it's from you?
csarven: Data management, maybe? I think Hadrian made a good point to focus on the core one(s). So, data management and data discovery.
acoburn: Any further topics? Nope