Page Comparison

DRAFT MINUTES

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
• 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
  • For further resulting action items see https://github.com/camaraproject/Governance/issues/84#issuecomment-2036723582

...

• Review of CAMARA release process CAMARA Release Process (https://wiki.camaraproject.org/x/16N3)
  
  • Meta-release Fall24 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 process Releasing API versions (https://wiki.camaraproject.org/x/AgAVAQ)
  • 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(https://wiki.camaraproject.org/x/PQEVAQ)
  • 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)

...

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

...