Page Comparison

DRAFT AGENDA

Attendees & Representation

...

...

• 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
•  Todos (to be moved to the issue as checklist):
  • Create a PR with the necessary changes to ProjectCharter.md and ProjectStructureAndRoles.md Herbert Damker 
  • Ask potential Maintainer to commit to the role Ricardo Serrano Gutierrez Markus Kümmerle 
  • Create two new repositories "APIBacklog" and "Marketing"  (CAMARA Admin team)
    • Include creating Maintainer and Codeowner files (CAMARA Admin team)
  • Add existing content into the new repositories, transfer issues Ricardo Serrano Gutierrez Markus Kümmerle 
  • Set repository https://github.com/camaraproject/WorkingGroups to read-only (remove write access)(CAMARA Admin team)
  • Update links within GitHub, Wiki and website, especially within https://github.com/camaraproject/WorkingGroups 
• Approved by the TSC
  • • Herbert Damker will get in touch with Ricardo Serrano Gutierrez to execute accordingly for backlog projet. 
      • Ricardo will look for Maintainer candidates.

...

• Discussions on event subscription evolution are going on (issues 1-4 from the consolidation list)
  • Proposal (Ludovic Robert ): have explicit workshop (mid of April) to resolve the open points
  • Proposal (Jose Luis Urien Pinedo ): Another meeting for the open points regarding test definitions (also in April)
• Error response format
  • No feedback on Adopting RFC 9457 for Error Handling
  • Decision: will be closed with "not to be implemented"
  • Smaller improvements:
    • Which error send back when issue with Device Identifier provided by the API Consumer
    • Proposal to add error response for not supported method for phone number
    • Add reference documentation link to error responses
• Release (0.4.0) plan
  • Meeting on 15.04.2024 fixing the scope → M0 
    • Rafal : Having a Artych mentioned that having stable commonalities guidelines for M1 is very challenging
  • The latest moment to finish the release candidate of Commonalities is 10.06.2024 → M2
    • M2 should include update of linting rules introduced with M1 release of Commonalities (as far as able to be checked by linting rules) 

...

API Backlog (Ricardo Serrano Gutierrez )

Initial content proposal by Herbert Damker , please change as appropriate:

• OGW Product Team & CAMARA API Backlog Way of Working
  • Was presented within last TSC meeting (see 2024-03-21 TSC Minutes)
  • Next steps, result?
• Criteria for approval of new API sub projects - discussion
  • ...
• API proposals forwarded to TSC by API Backlog Working Group (see https://lists.camaraproject.org/g/tsc/message/149 and following mails)
  • Device Connection Quality Indicator
  • Best Interconnection
  • CPE Management
    • Already approved, will go in a separate repository beside HomeDevicesQoD, but planned to be managed by one group
    • Final name under discussion, see <...>
    • Sub Project will be create after name is decided
  • Capability and Runtime Restrictions
  • Most Frequent Location
  • Device Visit Location

• There was not enough time left for the API Backlog items, especially the proposals from https://lists.camaraproject.org/g/tsc/message/149, they are postponed to next TSC meeting
• CPE Management:
  • Already approved, will go in a separate repository beside HomeDevicesQoD, but planned to be managed by one group
  • Final name under discussion, see comment in https://github.com/camaraproject/WorkingGroups/issues/378
  • Sub Project will be create after name is decided
• Ricardo Serrano Gutierrez mentioned that there potentially will come a lot of new proposals with GSMA Product team "Drop 4" and we need to discuss how to handle that.
• Herbert Damker reminded of the name of the working group "API Backlog", which means that proposals can also stay there until the project has enough bandwidth to manage the work on the proposals. Criteria need to be defined about which proposals will be put into "work in progress" (= will be developed and afterwards managed in a sub project).

No life sign projects - how to handle these? (Herbert Damker Ludovic Robert )

...
• 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?

Add structure to project and working group information (Casey Cain )

Initial content from Casey Cain - to be discussed if time left:

• Now that we have GitHub Include macro for the wiki, it is easier to structure project data.  In order to reduce duplication of effort, we suggest that we add a bit more structure to where project information is located and updated. 
• We are open to feedback about how to accomplish this, but we suggest the following changes:
• The Project README.md should be limited to mailing list information and information about that subproject/working group
  • Start with link to mailing list
  • State of Project Lifecycle (Once defined by the TSC)
  • Detailed project descritipion
• Meeting information should live in the wiki
  • Check Sub Projects to see if your project is listed
    • If your project is missing, add your project with the "Project Proposal Template" found on the Sub Projects page.
    • You can Slack Evan Harrison & Casey Cain if you have a quick question about how the templates work.
  • Verify that you have used the wiki labels to add your project/working group identifier:
    • sp-xxx or wg-xxx
  • We could also alternatively create a "MEETINGS.md" GitHub file that has the meeting information, which we can use the GitHub Include confluence macro to include that information in a similar to the way we would with README.md
  • Why separate meetings from the project description?  Consistency and formatting concerns about the ease of finding information.

Any Other Topic

• • • , yes, how to find volunteers who will work on them?
    • If no volunteers: Postpone these APIs to a later time?

Add structure to project and working group information (Casey Cain )

• Postponed to a later TSC due to lack of time.

Any Other Topic

• none

Next Meeting

• Next TSC Meeting will be on April 18th, 16:00 CEST / 14:00 UTC / 07:00 PST
• Specific agenda topics backlog:
  
  • Update from TMForum collaboration and how members are working in Catalysts and Operate APIs (Olta Vangjeli )
    • Catalyst and Operate APIs update
    • Can we have more usecases proposed how TMForum APIs and Camara communicate in e2e journeys?
  • No life sign projects - how to handle these? (Ludovic Robert )
  • Add structure to project and working group information (Casey Cain )

Action items