Meeting minutes
Minutes
approved
TF Lead
<kaz> People section of the WoT Use Cases wiki
McCool: I have put myself as temporary use cases TF lead
McCool: I will also cleanup the wiki
Today's Topics
Process
McCool: we need to figure out how to link all use cases and requirements to each other
… we need to categorize them as well. For security they are obvious to me but for discovery I am not sure
… I have a list already
Ege: is this list for the previous rec?
McCool: yes
Ege: also, did you use the existing use cases for this?
McCool: no, but we should find the relevant use cases
McCool: we have a section commented out
Kaz: we should use this call and following ones for agreeing on the process and how to organize the current document
McCool: Using Discovery as an example to agree on the process would work nicely
Kaz: yeah, we could use the existing resources (both those in the Use Cases Note and those in the Discovery.md) to discuss the process :)
McCool: I will copyover the requirements now
McCool: each requirement should have an identifier
Ege: you can have IDs in lists, can't you?
McCool: Yeah, we can have some short names
Ege: so this requirement is too broad, ideally we should not have such requirements
McCool: yes this is a broad one but we can look at the process
Ege: yes I agree with the linking and similar part
McCool: I can create this requirement, i.e. the template to use, then we can do the same for the others
Ege: Actually, discovery has the requirements document so it is a bit an unusual case. I am not sure if TD has one
McCool: that is not good
Kaz: to generate an improved version of the Use Cases Note, we need to clarify what kind of granularity of the description is needed for the categories and each use case/requirement.
McCool: I get confused with different types of requirements
… what is a functional or technical requirement?
McCool: I will go over the use cases and give IDs
… and concrete names
Kaz: agree :) That is exactly what I have been mentioning.
McCool: categories make it difficult
… I will put uc before the requirement
Ege: it would be good to have numbers in the ID so that we can have future use cases with similar names
McCool: but not visible in the title right?
Ege: yes. Just to future proof
McCool: The id should be consistent with the title
Kaz: clarifying the notation for id is nice.
… if two use cases are similar, they can be categorized
… or even merged
McCool: categories are not good
Kaz: If we want to avoid using categories, maybe we need to merge all the similar use cases as a typical use case with several variations.
McCool: I do not want to change the submitted use cases, since they are submitted people
Kaz: In that case, maybe we need to have two bigger sections, one for the new use cases and another for the old use cases.
McCool: use cases should be concrete, there should be users
Ege: I have one "radical" idea which is to create a new document and transfer each use case that is fit to our new template one by one
McCool: that is indeed a lot of work and it should happen in one go
<kaz> McCool's slides on Use Case work
Ege: I think we should have a gate/check before moving to a work item
McCool: there can be also open requirements that are not being worked on
Ege: yes like 3 states, done, open or worked on as part of a work item
Kaz: what are the next steps?
McCool: we can have further discussion during the next discovery call
… and have a PR to merge by next use cases call