The project's Antitrust Policy, which you can find linked from the LF and project websites. The policy is important where multiple companies, including potential industry competitors, are participating in meetings. Please review and if you have any questions, please contact your company legal counsel. Members of the LF may contact Andrew Updegrove at the firm Gesmer Updegrove LLP, which provides legal counsel to the LF.
Migration of wiki.camaraproject.org into Atlassian Cloud
Was tentatively scheduled for August 29th ...was delayed due to an issue with linking to meeting templates.
New deployment date will start on
migration delay was due to broken links in template mechanism in the "create minutes" button on landing page. From now on: use the "create new minutes page" button on the parent page of the minutes list
Friday outage was due to license expiry as the migration was supposed to have happened already - Atlassian is depricating their data center solutions.
A note about the new Cloud deployment. Other communities have experienced issues with "copying" previous minutes' pages. It is suggested to always use the create from template button, which will be moved to the "2024 <sub project/working group> Minutes" parent page.
Sandbox/Incubated/Graduated/Archived proposal - new proposal for the lifecycle of API Repositories
Agreed changes to the proposal based on the comments (not yet applied to the proposal text):
Clarification that there are four cases of outcome for scope enhancements / new API proposals in API Backlog (if accepted within the working group):
Scope enhancements which are only impacting existing APIs are handled in existing API Repository
Scope enhancements proposed by a Sub Project and resulting in a new API: The Sandbox API Repository will immediately part of a Sub Project.
If an independent API proposal aims to be part of an existing Sub Project and gets accepted by the Sub Project, the Sandbox API Repository will be part of the Sub Project from the beginning as well.
An independent API proposal which has no target Sub Project gets only a Sandbox API Repository, but yet a Sub Project.
Within the Incubation pre-requisites it is sufficient that a previous (initial) version has been implemented – deleting the requirement that it has been (commercially) launched
Removing the dependencies between initial/stable API versions and Sandbox/Incubated status (requires the review of criteria for Stable API versions)
Incubation process will be decoupled time wise from the Meta-release cycles
Requirements to continuously update API to follow Commonalities changes have to be discussed
Further outcomes of the discussion:
Clarification that the nomination of a Maintainer for an API Repository after the initial development phase isn't time consuming, to encourage the active support from operators for an API they want to get incubated
Requirements about updates of APIs to follow Commonalities changes have to be clarified
With the current proposed requirements we have currently only Sandbox and Incubated API Repositories. Graduation will happen based on commercial adoption by operators.
Time to go to governance for finale decision
No need the change the charter document (tbc)
It will change the process of API onboarding & the document ProjectStructureAndRoles.
Next release cycle ("Spring25") starts on September 30th (M0 - Kickoff)
Initial indication that the M1 may need to be delayed. Date to be determined next week in RM meeting.
M6: feedback on release process welcome from all participants. Please provide feedback either as a GitHub issue in the ReleaseManagement repo or on the Meta-release feedback page.
Updates to the process will be incorporated for use in the upcoming meta-release.
Request from Jorge Garcia Hospital to check if we can align the release of the Meta release with the MWC (3-6 March 2025)
It was on purpose that the Meta-release is planned forafter MWC to avoid confusion between Telco API launch announcements (which will be based at MWC on Fall24 release) vs Spring24 Meta-release announcement (with new API versions which can't be already implemented)
This is probably a point to be discussed with GSMA communication/marketing team
Eric Murray raised the question about breaking/non breaking change assessment - up to the RM team or by Project?
Tanja de Groot answered that we have a section "guideline" on this topic here
Decision: Start this API in sandbox (repo) and then work on the name
Jorge Garcia Hospital propose first to ask to supporter companies if OK to start with this name.
Axel Nennker explained that for DT the term risk indicator was used. The use of score term is very risky (from regulation). We must be clear that it will not be used to discriminate people. If it based on AI model, the model must be shared to allow people to challenge it.
Dedicated Networks API
Supported by Ericsson, Nokia, Telefonica, Vodafone
Decision : Start the work in a sandbox (repo) and then with provided assets check/reassess collision/overlap with other CAMARA API (like network slicing booking API but other APIs could be affected)
An issue is open to discuss the scope of the next version: Commonalities/issues/273 - scope should be closed for
Since 5 APIs are now stable - how to deal with guidelines enforcing breaking changes in API specifications?
Herbert: add in the PR template a section on breaking changes and that indicates that there is an impact on API - the PR description should be updated accordingly if a breaking change gets added by a later commit.
M1 date for Spring25
Current date too early for the first alpha release
Eric: versioning numbers - review the versioning of Commonalities and ICM → Eric to raise an issue in commonalities/ICM
clarify what must be signed and by whom ? can it be rejected ? details in issue #194 (see link above - please comment
Sorting issues into what is planned to be included in Spring25
team is asked to create PRs with specific change proposals.
Specific Topic: Arazzo Specification discussion (Kevin Smith )
moved to next meeting
Any Other Business
Eric: we should be organizing new TSC elections - Casey will organize and discuss details.
Next Meeting
Next TSC Meeting would be on October 3rd at 10:00 CEST / 8:00 UTC / 01:00 PST
Holiday in Germany - one of co-chairs to moderate - others to nominate replacements.
Specific agenda topics (backlog:
Specific Topic: Arazzo Specification discussion (Kevin Smith )
Action items
Specific Topic: Arazzo Specification discussion (Kevin Smith ) - To review during next tsc call
Request the CAMARA Marketing Working Group to clarify if the Spring25 Meta-release should potentially be announced at MWC, or - as currently planned - after MWC at another event Herbert Damker
Check if linting can help to preserve backward compatibility (e.g. with warnings in case of breaking changes) Rafal Artych
Create New API repository DedicatedNetworks Herbert Damker
Clarify if new repository for the "Telco Index" proposal should be created with this or another initial name Jorge Garcia Hospital
Propose time plan and start TSC election with (self)nomination phase Casey Cain