...
Thorsten: Scope issue
Bit awkward to start documenting as issue
Should ideally move to release documentation at some point
Should also include what is NOT in scope
WoW: Update scope issue in the meeting but also possible to make comments which can be reviewed and updated during the meeting
Thorsten checked the APIs - some point to open issues. For Dedicated Netowrks - should start with initial requirements. Can point to more issues later
Phrase in the form of requirements
Current thinking is to start looking at the API description
Take hints of the requirements from above and convert to “real requirements”
Scope should cover at least what is written above
Jorge: For the release, user stories are required
In development pipeline, this is a typical workflow to start with user stories (even though other APIs did this in the end)
Could we start with user stories now?
Thorsten updated the comment directly in the scope issue.
Jorge gave example of Device swap etc. on how a sandbox API could be part of meta-release
Thorsten: What about the testing material
Jorge: API test plan - at least the happy paths - need to be documented (simple test plan)
Thorsten: Need to start working on the first draft of first user story
Thorsten: Update regarding all-hands meeting
No update provided by this WG yet. Similar to perhaps something like Quality by design.
For next hands-on - provide info so reporting starts to work properly
Thorten: User story
Showed example of QOD
Perhaps most important is pre-condition, then what needs to be done to get desired output, and then the final outcome
Need to expand from the API Summary
Can potentially use the examples from the Supporting documents prepared in the “preparation phase”
Jorge: Suggest to create a copy of the slides in supporting documents (can include in additional documents)
Create an issue referring to the document and ask for confirmation from the group
Thorsten: Would it be better to create a CAMARA branded version of the document
Jorge: Agrees that it might be better
Peter: Can there be multiple use stories?
Two cases - reserving, then adding devices
Can it be one or two -
Thorsten: No clear guidance - at the moment
Jorge: Seems we need a user story “per endpoint” (e.g. Number verification and swim swap)
Thorsten: So seems we need at least two (since device list management might end up as separate endpoint)
Thorsten: Suggest to start with a new document (could use the prep material as input)
Should start with the CAMARA template
Jorge: Should create an issue, better to create markdown with principles.
All WG members have the existing pdf - and initial material will be based on that - so reviews can start already (even before the new alignment issue is created)
Action items
- Thorsten Lohmar to check the tags in Release Tracker (business as usual)
- Thorsten Lohmar Create v0.1 of the initial document for discussing user stories for first alignment (Supporting documents)