Versions Compared

Old Version 1

changes.mady.by.user Thorsten Lohmar

Saved on

compared with

New Version Current

changes.mady.by.user Rajat Kandoi

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Community Attendees:

Rajat Kandoi , Thorsten Lohmar , Barath K , Fadime Demirer Ulgen, steve.vickers , Alejandro Palmier , Jorge Garcia Hospital , Peter Kovacs

LF Staff:

Agenda

  • Antitrust

  • Agreement of last minutes

  • Release Tracker

  • Scope of first release

  • CAMARA all hands meeting (last week)

Antitrust: https://lfprojects.org/policies/antitrust-policy/

Last Minutes

2024-11-04 - DedicatedNetworks - Meeting minutes - CAMARA Project - CAMARA Project

Comments:

Release Tracker

Link: dedicated-networks v0.1.0 - CAMARA Project - CAMARA Project

Scope of the first release

Issue #8: Scope of Dedicated Networks API version 0.1.0 · Issue #8

CAMARA all hands meeting (last week)

Link: Monthly All Hands Status Updates - CAMARA Project - CAMARA Project

Meeting notes

  • Thorsten repeated that the Anti-trust policy applies to this meeting and that the policy can be found in the notes.

  • Thorsten understood in the all hands meeting that we should not target the Spring release

    • since the Dedicated networks api is a sandbox api

    • should use the label “camara others” (or similar)

    • how would sandbox api show up in meta release

    • Jorge: sandbox group cannot release a 1.0 - first need to do an initial release - test with operators - then can be moved to stable release work flow

    • Thorsten updated text in scope to reflect this

  • M4 milestone (Feb 2025 end) implies that API should be almost ready for the meta-release

  • M3 - thats the first deadline to start working against

  • 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)
  •  Peter Kovacs - Create scope alignment issue
  •  Thorsten Lohmar , - Create v0.1 of the initial document for discussing user stories (Supporting documents)
  •  
  •