...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Attendees Attendees & Representation
TSC Members may indicate their attendance by marking an X in the column to the right.
...
Representative | Organization | Role | |
---|---|---|---|
Deutsche Telekom AG | TSC Chair, Active Maintainer | x | |
Deutsche Telekom AG | Active Maintainer | ||
Ericsson | Active Maintainer | x | |
KDDI | Active Maintainer | x | |
Orange | TSC Deputy Chair, Active Maintainer | x | |
Radisys | EUC Representative | ||
Summit Tech | EUC Representative | x | |
Telefonica | Active Maintainer | x | |
Telefónica | Active Maintainer | x | |
Verizon | EUC Representative | ||
Vodafone | TSC Deputy Chair | x | |
Vodafone | Active Maintainer | x | |
Vonage | Active Maintainer | ||
George Glass | TM Forum | TM Forum Representative | |
Olta Vangjeli | TM Forum | TM Forum Representative | |
GSMA | GSMA Representative | ||
GSMA | GSMA Representative |
...
Change Working Groups into Sub Projects (https://github.com/camaraproject/Governance/issues/84)(Herbert Damker )
...
- Proposal (as in https://github.com/camaraproject/Governance/issues/84):
Create separate repositories for all Working Groups (Commonalities and Release Management already available, API Backlog and Marketing todo)
The new repositories follow the same procedures as the repositories for Sub Projects. That means it will have maintainers and code owners, but no WG_participant.md files
- To distinguish repos for Working Groups from repos for API Sub Projects we use a new badge "Working Group"
- Existing content will be added into the new repositories, issues will be transferred
The existing "Working Groups" repository is set to read only after the content is transferred and then archived after 1 month
- How to define the initial set of Maintainers and Codeowners for the API Backlog repository?
- API Backlog:
- Proposal: candidates for Maintainer in API Backlog group are all current participants who have attended >=4 of the last 6 meetings (9 candidates, representing ATT, CableLabs, Charter Communication, Ericsson, GSMA, Nokia, Telefonica (2), Vodafone). Further 6 candidates if >=3 of last 6 meetings or >=5 of of last 9 meetings (Deutsche Telekom, Huawei, Orange, Schabodi, Telefonica, Vodafone). The candidates would need to commit to the Maintainer role to get Maintainer.
- Codeowner will be defined by the Maintainer group
- Maintainers and code owners of Marketing Working Group will be defined by the existing working group respective the Outreach Committee members nominated by Board members
- API Backlog:
...
- Approved by the TSC
- Herbert Damker will get in touch with Ricardo Serrano Gutierrez to execute accordingly for backlog project.
- Ricardo will reach out to the Maintainer candidates and ask for their commitment to the role
- Herbert Damker will create a PR with the necessary changes to ProjectCharter.md and ProjectStructureAndRoles.md
- Herbert Damker will get in touch with Ricardo Serrano Gutierrez to execute accordingly for backlog project.
...
- Include creating Maintainer and Codeowner files (CAMARA Admin team)
...
...
- For further resulting action items see https://github.com/camaraproject
...
Release Management (Samuel Adeyemo Tanja de Groot )
- Review of CAMARA release process CAMARA Release ProcessMeta-release Milestones (https://wikilf-camaraproject.camaraprojectatlassian.orgnet/wiki/x/16N3ah7e)
- MetaTest meta-release Fall24page layout timeline
- Next step: create API version assets and acceptance criteria for Commonalities and ICM release-candidates
- Action Point: clarify current comments on the process
- Action Point: align dates M1 & M2 with ICM and Commonalities
- Action Point: disseminate the release process information into sub projects; starting with AHC on Thursday April 11th
- Draft Proposal for Release management & versioning API versioning through the release management processRelease Process (https://wikilf-camaraproject.camaraprojectatlassian.orgnet/wiki/x/AgAVAQjine)
- Feedback requested
- Will lead to update of Camara_Versioning_Guidelines.md
- May lead to updates / moving of release checklist to RM
- May lead to updates of the testing guidelines
- Action Point: Check linting rules, if the proposed version numbering and extensions are allowed Herbert Damker
- To be discussed and decided: will only sub project releases with >=1.x.y be part of the meta-release or could also "development" releases 0.x.y be allowed as part of the meta-release? => Open issues below
- Open issues
- Review: Open issues Multiple APIs in one Sub-project(https://wikilf-camaraproject.camaraprojectatlassian.orgnet/wiki/x/PQEVAQxBXe)
- Next steps: in all outstanding issues related to RM, request teams to check if proposal meets the needs.
- Action Item: create or reuse GitHub issues for the open issue(s)
...
- Not much feedback from TSC members on our request to comment on "purpose" and whether multiple purposes are a business requirement
- Request for action to all: Please add your company's position
- Working on the last remaining open topics before merging our Interoperability and security document. Thanks to TEF for summing up the open points.
- Most difficult remaining point is how to represent "purpose" (see previous point). If there is no consensus within the the next meeting, the only option might be to have no statement about it in the first version of the profile (= deleting the current proposal of adding an explicit parameter from the PR).
- Steady participation, we are making progress
...
- Following points were only shortly mentioned my Ludovic Robert , but not discussed (=> backlog item)
- We have currently two project without (visible) work within the repositories
- Device Swap (repository created but no activity over the last 6 months)
- IMEI Fraud (Attached to device identifier repository but no activity there on this API)
- Are these APIs still relevant?
- If, yes, how to find volunteers who will work on them?
- If no volunteers: Postpone these APIs to a later time?
- We have currently two project without (visible) work within the repositories
...