Meeting minutes
Call Organization
<kaz> Proposed workflow
Mizushima: we start with reviewing the minutes and create issues based on identified topics
… then review issues and PRs with the process label
Kaz: basic flows seems good to me, and Ege to it seems
… we need to think of how to handle existing issues and PRs
Mizushima: that means we can approve the proposal
Minutes review and GitHub Issue creation
<kaz> Jan-24 minutes
Kaz: I have added you as chair, please reload
<kaz> Proposed Issue from the previous minutes
How to deal with GitHub Issues/PRs?
Mizushima: I don't need to create an issue about the first discussion but I will think about the workflow
How to extract information, e.g., about requirements, from the UC description?
Mizushima: I have created an issue about how to handle generic use case
When/which level of UC description to be generated?
Mizushima: also another one about what level of details UCs should be, I have created an issue
Who/how to submit UCs?
Mizushima: for the submission workflow clarification raised by Ege, I have created an issue
How to deal with gap analysis?
Mizushima: the next part was how to deal with the gap analysis
… it is an important topic, with already two issues from Ege. I have created another one
Technical use cases vs Functional use cases
Mizushima: regarding this topic, there is an existing issue from McCool that we can use
How to manage the feedback from brainstorming discussions?
Mizushima: we don't need to create an issue
McCool: that's fine
<cris_> +1
Mizushima: so any questions or changes to minutes?
Ege: I like the approach, thank you
Mizushima: minutes are approved
Mizushima: can we approve the extracted topics as well?
Ege: We can approve the extraction. Can you add your name for your comments?
Kaz: I think these are not his opinions but the decisions are made simply based on whether there is already a related Issue or not
… we should label those issues with "Process" label
Mizushima: I have created a "Process" label in the use cases repository
Mizushima: any other questions?
Mizushima: extracted topics are approved
Review the GitHub Issues/PRs with "Process" label
Mizushima: We can talk about the process labeled issues so that we can improve the process document
w3c/
Ege: should we discuss that?
… sorry I did not see that it is labeled with process
Kaz: yes it is in scope
Mizushima: Yes if we have time
<kaz> Proposed Process.md
<kaz> Issues with "Process" label
Issue 257
<kaz> Issue 257 - [Discuss] Focus on Functional Requirements
McCool: we can start with the functional requirements or not
Mizushima: we should explain the difference between use cases and user stories
McCool: the discussion to have is whether use cases need to be low level or not
… toumura-san's comment suggest different templates.
McCool: I think we can move the categorization to separate issue
Lagally: there is also the discussion on whether we should consider business requirements which are even higher level
Kaz: I agree with McCool and think we should focus on functional level description for Use Cases and Requirements for the Use Cases and Requirements document to describe users' story and need.
… maybe the comments from toumura-san and ege are about templates and to be filed as another issue on the description and template.
Ege: I think we need to agree on the definition of use case, user stories, functional and technical requirements
<cris_> +1
Ege: I want to stress that we need technical details from the inputs of users. Otherwise they are too high level and cannot be used for feature extraction
… if they are for outreach items, that should be a separate category like toumura-san has mentioned
McCool: some examples on functional requirements vs technical requirements
<McCool_> w3c/
Mizushima: I think that use cases document should be about functional requirements
McCool: (before tm) we should not overconstrain the requirements that will constrain the specifications. E.g. oauth2 is technical requirement, access control is functional requirment
Kaz: we need multiple levels. Functional level description about users' need for use cases, and another Technical level of description for Requirements description.
Ege: We need as technical as possible for driving specifications. From TD TF point of view, I do not care about anything high level since they cannot be used for specification development. Thus, it is better to separate them from the beginning as toumura-san has proposed
<McCool_> w3c/
McCool: I have commented in the issue
Kaz: I think we should clarify what we mean by "Functional" and "Technical" clearer
… we want use case submitters to explain their "User Scenario" (or "User Story") a bit in detail for their use cases. This seems to be something we agreed on.
… I think what McCool meant is that we need user stories first
Cristiano: Couple of comments. I kind of support Ege with the bottom-up approach. We have done work on going through issues and they are very actionable
… we can write a use case from such issues
… sometimes use cases are mixed with stories. Sometimes they are feature descriptions. So we should clarify the definition first
Ege: In the example we are seeing, I want the technical requirement to be submitted to specifications. Otherwise spec work cannot proceed
Koster: I think that the problem is split. Functional requirement is high level, a description of the problem.
… we should maybe have more requirements without designing the solution
… in some cases, the solution can be visible in the requirement since a certain stack might be needed
McCool: I agree both points. It is just about where the work takes place.
Kaz: sorry but we're out of time. anyway we've clarified the basic workflow, and have started actual discussion based on that. thank you very for organizing the discussion, Mizushima-san!
Cristiano: I recommend reading the shacl use cases and requirements document above
<kaz> [adjourned]