Meeting minutes
Logistics
Mizushima: I'd cancel the 5th June call, since I'll be in vacation
[[[
<Tomo> [No changes from the previous plan on 8 May 2024
<Tomo> May-15: Fix Github Issue template using YAML and Initial discussion on Requirements Template
<Tomo> May-22 and May-29: Fix basic Functional Requirements Template
<Tomo> June-12 and June-19: Fix basic Technical Requirements Template
]]]
Mizushima: Any objection for the next meeting plans?
<no objection>
Minutes
<kaz> May-8
Mizushima: Anything to change for the past minutes?
<nothing to change>
Discussion point
[[[
<Tomo> Github issue template using YAML
<Tomo> confirmed the YAML-based template includes all the content from the MD-based template.
<Tomo> additional notes from old template are also included in YAML-based template.
<Tomo> further improvement for the YAML template to be done using GitHub Issues and PRs
<Tomo> Question about the need for submitter's email address (discussion to be continued)
RESOLUTION: While not required for submission of a use case for consideration, the email of the submitter should be requested and recorded before a use case is published in case followup is necessary. These emails will be kept private and only used for communication on the use case.
]]]
Mizushima: Anybody wants to add additional discussion points for today?
<all agree>
Fix YAML-based issue template
Issue #281
<kaz> Issue 281 - Mention Possibility of External Submissions via Issues
Luca: the issue is closed because the new issue template addresses it?
Mizushima: Yes
Issue #288
Mizushima: mm found some typos
Mizushima: I fixed them with the PR #292
<Tomo> w3c/
Mizushima: is it ok to merge?
<all agree>
Luca: Would be good to always use rebase-and-merge so we keep the history linear
McCool: No objection
Kaz: I'm all also ok with rebase-merge, but also ok with ordinary merge for this PR since it's not problematic
… If we want to use rebase instead of merge, probably we should discuss that during the main call and suggest we use rebase for clearer log as our policy.
McCool: We can discuss it in the main call, but we can use it on the UC task force for now
Issue #289
<Tomo> Issue 289 - [UC Template] Stakeholders
Mizushima: I agree we have multiple lists of stakeholders and we should keep a single list
McCool: The security TF has the most developed list, but the current usecases is using the other list, so if we pick the Security one we need to update the names in them
Mizushima: Luca created a PR to address the UI concern
McCool: Would be nice to link to the Security guideline with the description of the other stakeholders
… let's compare the two lists
<kaz> WoT Security Note - 3.2.1 WoT Primary Stakeholders
McCool: <shows the lists for Security and Architecture>
<kaz> Preview
McCool: Can we see a preview
McCool: I'd rather have a checklist with a link for each item to their description
Luca: Ok, can be done
Kaz: Given McCool suggested we use checkboxes within his original Issue, we should try checkboxes as the style, for the link to the definitions we can do that later
Luca: Checkboxes can be implemented via https://
Luca: I'll update the PR later today
Mizushima: Luca will change the PR while Michael will provide the links with the definitions and the up to date list
Issue 286
<kaz> Issue 286 - [UC Template] "Submitter" should indicate Real Name(s)
Kaz: Since Ege is unavailable we can discuss the PR next week
… and We can address the problem with emails and Real Names separately
McCool: Agreed
Kaz: how to proceed with this issue?
McCool: I can comment on Ege PR right now
Issue #287
<kaz> Issue 287 - [UC Template] "What to be done?" is ambiguous
Mizushima: I agree with Michael opinion
McCool: I'm updating the order in the issue
<kaz> McCool's comment
Kaz: If everybody is ok with that, we'll use that order
Luca: Since we all agree, I'd go with that order.
<everybody agrees>
<Tomo> 1. summary, 2. Why WoT, 3.Gaps, 4.Description
Mizushima: I'd close this meeting
<adjourned>