Meeting minutes
Wrap up on Issue 143
Ege: we talked about this and wrote all the concepts that we are targeting
Ege: we don't need to agree on the name as we can change the repository name easily
… we can decide on the concrete wording later on.
Ege: forgot to mention but we have no TD call for two weeks
Moving Information to the New Repository
requirements
w3c/
Ege: we are basically copying the information from the binding templates here
proposal: For discussion around the binding registry, we will use w3c/
RESOLUTION: For discussion around the binding registry, we will use w3c/
Ege: then we have a resolution. but I will send an email
… also no objections to merging this PR?
Ege: any objections to moving the related issues as well?
… basically all the issues with the tag at https://
… if someone goes to the old link, they should get redirected
… we don't have any leftover issues regarding the registry mechanism in the binding-templates repository
Use Case Process
Reusable Connection
Ege: we aim to have documents of the form https://
Ege: that way we know why a certain was needed
Ege: we should not see this as a bureaucratic step but as a way to align before writing spec documents
Ege: we can write what the user needs to fullfil, the needs of users in form of requirements
Ege: in this example, we also have description about the concrete feature
Ege: we have a document which can be used as a reference
Kaz: we should note that this feature is not only useful for agriculture
… also extending the use case with the requiremeent of usability would be nice
Ege: we can link to more use cases for sure
… however I think the use cases should stay generic a bit
Kaz: TD TF should describe in which part of the use case this initial connection feature would be useful
Ege: so you mean we should explain why there is a link between a user story and use case
Ege: I have opened an issue for this in the use case repo
UC Issue 358 - User Story relation to the Use Case
Ege: any questions on the goal we have?
Ege: the first thing is to write a user story, which is simple to do
… you should basically write one sentence and link to use case that has domain information
Ege: I want to show an example
<kaz> UC Issue 357 - Relevant Payload Selection in (JSON) Payloads
Ege: (presents the content of the user story within the UC Issue 357)
ca: the use case is clear. there might be a way that people were using existing solutions. For example, you can undescribe the payload
… I am wondering, I can propose a solution on this thread
Ege: for existing feature in our specs, we should write here
… in the final document, we should collect existing solutions from other specs. see https://
… however, how to collect it in the beginning when the user story is submitted, I don't know
Kaz: I agree with Cris. The whole process needs to be clear
Kaz: we should make a proposal to the next main call.
Ege: we know the first step, the last step but the path between is not clear
Ege: we need to also decide on prioritization
Ege: right now we have a mixed process. We have a charter and an idea of what we want to do
Kaz: the process can be bidirectional. We can write requirements and use cases for the features we are building
… we should discuss this in the main call
Manageable Affordance
<kaz> TD PR 2096 - Manageable Affordances Analysis
<cris> +1
Ege: I am putting all information into one place first
Kaz: so we work on the potential user scenario right?
Ege: yes
… we can merge it to have a place to work on this feature
Ege: AOB?
Ege: Adjourned