Meeting minutes
Agenda
<kaz> Agenda for today
Mizushima: (goes over the agenda). Minutes review, tpac wrap up, use case internal trial, requirements
Meeting schedule
Mizushima: I will not be available on oct23
McCool: but let's keep the meeting and I can chair it
Minutes Review
<kaz> Sep-18 minutes
Mizushima: (goes over the minutes)
… we discussed TPAC planning, schedule. Then talked about the internal trial.
… any opinions on the minutes?
Mizushima: Minutes are approved
Wrap up TPAC24
<kaz> TPAC WoT Meeting - Day 1 - Use Cases and Requirements
McCool: There is a small mistake in the requirements section
… "use case story" should be "user story"
McCool: I think we should look at how the Spatial Data in the Web WG does it
Mizushima: we can approve minutes from TPAC24 on the use case session
Use Case Trial
Mizushima: Is there any issues on the trial?
McCool: we should put a deadline for the changes to the template. If there is any feedback, please open an issue
McCool: people can comment on the issue to improve the template
McCool: Rob said that there are use cases and use case scenarios
McCool: they are not end user cases
… for Rob, they are user stories
McCool: ege's examples were more feature requests
McCool: the TD examples are feature requests that are placed in use case scenario
Kaz: I have asked the group to include the scenarios in the use case descriptions
McCool: it would be also weird to include two types of "submissions" in the use case document
McCool: we want people outside to submit features since they are not able to do something
Kaz: from my viewpoint, "use case scenario" a sequence of device or user behavior or results.
… but maybe the SDW guys use "use case scenario" for a bit different meaning, so I'd suggest we should look into their definitions in their document
Ege: "who is the user" is not clear for me. the developer or end user of an application?
… also I want to see examples for each of these terms
McCool: feature comes from developer and use case comes from a business point of view
Ege: If use cases are end user view, then the current use case document has just that and is merely a marketing document
McCool: if there is no end user scenario but it is a developer pain point, that can be a category but even a developer is working under a context
Ege: not always if they are building a library, e.g. node-wot which is used in multiple domcains
McCool: they can be all written down as application areas
Ege: can you give an example of an end user use case driving a technical feature
McCool: in a farm with contrained battery powered devices, they need to support CBOR-LD so that they be more efficient
Ege: ok I understand
Ege: in this case, even this submission would have a feature request in it
McCool: yes in a way
Ege: I would be fine if there is always a "demand" from the submission to the standards
McCool: not really. A use case can be explaining how WoT is used
Ege: why do we care?
McCool: because the W3C is asking for it when we go to REC
Luca: somebody can ask for a feature but there has to be a why.
… we also have the other side. I want a pony but there is no detail on what is going on
Luca: we should welcome use cases when a company says "we want to use WoT because we cant and here is the reason why"
Luca: I also agree that categories is a good idea
McCool: we have several problems
McCool: in a use case, people may not provide enough detail
McCool: then developers who have a limitation that is blocking them
McCool: and in the end going to REC, we have explain why we are working on the standards
McCool: last problem is that we also have a lot of use cases.
<McCool> my proposal: separate use cases and feature requests. Feature requests can be in the form of user stories, and link a feature to a purpose. The purpose can be a single use case or a category of use cases (e.g. use cases needing efficiency). If accepted, a feature request becomes a requirement.
Ege: we can use the current template since if they don't provide a technical expectation it can be a user story
<kaz> Transition Issue for CR
<kaz> Process Doc
McCool: it can work but it would be cleaner to separate
Jan: I agree with separation
Kaz: I would like to remind you all of the W3C Process which requires us to show the fact the specification (as a CR) meets all the WG's requirements. For that purpose, we need a document of use cases
… and feature requests can be formed from requirements
Mizushima: feature request driven by use case is good. We need evidence of feature request requirements
… I agree with mccool
Ege: could you provide definition and example of each terminology we want to use?
McCool: I will try that in an issue
Kaz: and McCool, please talk with Mizushima-san again about how to organize the UC calls./
McCool: will do
[adjourned]