Meeting minutes
<Tomo> Agenda
logistics
Mizushima: will be unavailable end of may 13-june 5, so would like to cancel june 5 call
plan
Mizushima: review previous plan, but luca proposed using github issue template using YAML
… that discussion was not finished... would like to discuss further today
… then, if time, initial discussion on req template including security categories
Mizushima: and, actually, functional and technical req templates fix by may 22-29 and june 12-19
minutes review
<kaz> Apr-24
Mizushima: (walks through minute from 4-24)
… made resolution to use github issues to submit use cases, at which point luca made the proposal to use YAML for the template
… note github issues will allow non-members to submit use cases
Mizushima: no objections, minutes approved
Github issue template using YAML
Mizushima: generated an example template, based on markdown template
<kaz> MD-based
<kaz> YAML-based
<kaz> actual YAML code
<Ege> +1
About
McCool: suggest wording of "about" be changed
<kaz> Use this issue template to suggest a new use case to be added to the WoT standards.
McCool: to "Use this issue template to suggest a new use case to be considered for driving requirements for the WoT specifications."
Submitter
McCool: also, may be multiple submitters, suggest updating instructions to say separate multiple names with comments. First person is the contact person. Should also ask for an email but somehow not make it public.
Ege: not sure the email is required, a lot of trouble
McCool: I do feel it's important; we constantly have problems contacting people who submit use cases
Kaz: personally ok with publishing emails, since already public, but too much for other people.
Kaz: but first person should be contact
McCool: we should get the id automatically for submitter; should warn people names may get published and associated with github id.
Ege: would be useful to get emails of submitters, but not make it public
McCool: right. lots of people just use github occasionally and may not respond to notifications
McCool: if we can't capture the email with the form, we will have to contact them out of band
Kaz: we can hold the issue until we get an email; but we can start with github id
McCool: right, just consider it part of the process; can't proceed with publication unless we have their email
Mizushima: if contact person is same as submitter, and has github id, then they don't need email
Ege: I agree with mm, we should be more strict with this
<Ege> +1 to mm
proposal: 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.
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.
What to be done
McCool: the "What to be done" should be specifically about WoT (and say that); Stackholder -> Stakeholder
McCool: suggest moving "gap" up, and changing "what to be done" to "summary"
Target users
McCool: target user list should have checkboxes; should make this list consistent across docs (e.g. see list in security, arch as well - different! Need to consolidate)
… should allow multiple answers
McCool: later on, I think security and privacy categories should also use checkboxes, e.g. "Manages personal information", etc.
How to proceed
Mizushima: we had previously discussed the content of the template, btw
McCool: yes, sorry to reopen things, I am just noticing these issues now that I see it as a form
McCool: although I did previously state that we need to consolidate the stakeholder list, for example.
Kaz: suggest we once confirm the YAML-based template includes all the content from the MD-based template. Also the additional notes from the old template are also included in the YAML-based template. Then we can stat actual review (like McCool already started :)
Ege: agree with kaz that first agree this is the direction we want to take; I do agree with the YAML direction
… second point is how to move further; using PRs?
McCool: would prefer issues or PRs; would be better to have one representation as master; may need to file issues instead of PRs. YAML has some things that are not in markdown.
Mizushima: if we use YAML, then we can specify whetther each item is required or not
McCool: we need a way to look at the YAML template, then we can file issues against it
Kaz: McCool is talking about how to raise issues against the template itself
... So Mizushima should first confirm that the content of the YAML-based tamplate is identical to the one of the MD file, then we can continue discussion on further improvement.
<Tomo> MD-based template
<Ege> YAML-based template
McCool: right. step 1, make sure YAML has everything in MD; 2. archive MD file; 3. use issues to suggest improvements to the YAML template
Kaz: I've quickly skimmed both the YAML and MD, and think both have the same content. However, it seems Mizushima-san is kind of confused, so let's simply ask people to review the YAML-based template and give comments and suggestions using GitHub Issues and PRs
Luca: I am fine with the current template, but do have some minor changes
… note though there are ways to generate MD from the YAML if we want it
McCool: but in summary, you are ok with the YAML template being the master, right?
Luca: yes
Mizushima: ok, please review the YAML-based template and provide Issues and PRs.
Luca: agreed that we should just use the YAML as the master
<kaz> YAML-based template to be reviewed
<kaz> [adjourned]