DRAFT MINUTES
...
Representative | Organization | Role | |
---|---|---|---|
Deutsche Telekom AG | TSC Chair, Active Maintainer | x | |
Deutsche Telekom AG | Active Maintainer | x | |
Ericsson | Active Maintainer | x | |
KDDI | Active Maintainer | x | |
Orange | TSC Deputy Chair, Active Maintainer | x | |
Radisys | EUC Representative | x | |
Summit Tech | EUC Representative | ||
Telefonica | not Active Maintainer | x | |
Tnot removedelefónica | Active Maintainer | x | |
Verizon | EUC Representative | x | |
Vodafone | TSC Deputy Chair | x | |
Vodafone | Active Maintainer | ||
Vonage | Active Maintainer | x | |
George Glass | TM Forum | TM Forum Representative | |
TM Forum | TM Forum Representative | ||
GSMA | GSMA Representative | ||
GSMA | GSMA Representative | x |
...
- New proposal how to manage "API Families" as Sub Projects with one lead repository and multiple API "family member" repositories (#142)
- Herbert Damker Proposal changed based on the feedback within the comments: no "lead repository" for a Sub Project, but a Sub Project / API Family will be a set of 1 to n equal repositories to describe, develop, document and test the APIs (family members). The link between the repositories is the home page of the Sub Project within the wiki
- Pull request to be reviewed: https://github.com/camaraproject/Governance/pull/146
- Ask for formal vote from the TSC: No... but we keep it open for next week. Will be merged by end of next week if no objections arise.
- Proposal for new API Project lifecycle approach (Sandbox + Incubated) (#129)
- Herbert reminds us the advantages of this proposal to have some flexibility to onboard easily new project.
- Next step: details out this.
- Herbert reminds us the advantages of this proposal to have some flexibility to onboard easily new project.
...
- Herbert Damker Two new API Proposals are forwarded by the API Backlog working group to the TSC (see https://lists.camaraproject.org/g/tsc/message/195)
- Device Connection Quality Indicator
- Device data Volume
- Both are intended to be part of the DeviceStatus Sub Project
- Eric Murray Raise an issue in Device Status project to formally ask the project to manage this 2 APIs
- Herbert Damker There are currently two approaches to define an API which delivers the network type a device is currently connected to
- Within DeviceStatus: https://github.com/camaraproject/DeviceStatus/issues/143 with PR
- Within ConnectivityInsights: https://github.com/camaraproject/ConnectivityInsights/pull/40 (see also https://github.com/camaraproject/ConnectivityInsights/issues/48)
- How to avoid and resolve such situations?
- Mahesh Chapalamadugu explained that discussion occurred already in the connectivityInsight project and this team stated that probably it did not make sense to keep this network type attribute in this API.... so the point is resolved
...