[Onboarding Tracker] Create QoSProfiles repository by splitting qos-profiles from QualityOnDemand

[albertoramosmonagas]

The Connectivity Quality Management Sub Project agreed to split qos-profiles out of the current QualityOnDemand repository into a dedicated QoSProfiles repository. The goal is to simplify maintenance and allow the API to be reused more clearly by other APIs within the CQM portfolio.

The new repository should start with the Fall25 release of qos-profiles, while Fall25 and previous releases remain traceable through the historical QualityOnDemand repository.

API Repository Information

• API Repository Name: QoSProfiles
• Sub Project (or "Independent"): Connectivity Quality Management
• API Name: qos-profiles
• API Status: Stable API — currently published as qos-profiles v1.1.0 in the Fall25 release of QualityOnDemand
• Mailing List: sp-cqm@lists.camaraproject.org
• Repository: https://github.com/camaraproject/QoSProfiles
• Wiki Page: TBC (still open)
• API Owner: @camaraproject/quality-on-demand_codeowners - Connectivity Quality Management Sub Project community
• API Proposal: N/A
• Original Approval Issue: Split qos-profiles out of the QualityOnDemand repository #319

⚠️ Progress to the next gate only after completing all items in the current one.

---

GATE 0 – Codeowner Validation (must be completed before repository creation)

• Code owner(s) nominated and confirmed by API Backlog WG
• LF account active and Confluence access granted
• Subscribed to all@lists.camaraproject.org
• GitHub account active with notifications enabled
• Invitation to CAMARA GitHub Organization accepted
• EasyCLA validation successfully completed via test PR in camaraproject/EasyCLA

Once all items are complete, repository creation can proceed.

---

GATE 1 – Repository Onboarding (infrastructure established)

• Update APIBacklog.md with status: Onboarding
• Request wiki page and mailing list (email support@camaraproject.org, specify details) - no new mailing list required, only wiki page
• Confirm mailing list creation (only if Independent Sandbox) (LF Admin)
• Confirm wiki page creation (LF Admin)
• Repository created (LF Admin via automation)
• Add repository link to the API wiki page (LF Admin)
• Update README.md in the repository with API details (API owner)
• Update APIBacklog.md with status: Onboarded
• (Optional) Nominate initial Maintainers (API owner)
• (Optional) Submit PR to update MAINTAINERS.md and CODEOWNERS

---

GATE 2 – Initial Codeowner Tasks (first activities within the repository)

• Confirm that the CODEOWNERS file is correct and up to date
• Update the Scope section within README.md to reflect the agreed API purpose
• Create the first GitHub issues (e.g. for drafting the initial API specification or defining next milestones)
• Announce the start of development and share planned next steps via the API mailing list

---

Notifications:
CC: @camaraproject/admins @camaraproject/api-backlog_maintainers @camaraproject/marketing_maintainers

[hdamker]

The new repository should start with the Fall25 release of qos-profiles, while Fall25 and previous releases remain traceable through the historical QualityOnDemand repository.

We might to revisit this and decide how to do it, as some work was already done in the current repository. Another option is to switch over with the first Sync26 release candidate.

[albertoramosmonagas]

Hi @hdamker,

It's up to the group to decide. Another option is to release the release candidate directly on the new rc version, or else we can wait until sync26 is finished, as you mentioned.

[hdamker]

Another option is to release the release candidate directly on the new rc version

@albertoramosmonagas Not sure what's your proposal here. My proposed option was to create 1.1.0-rc.1 still in QualityOnDemand and then copy the sources of that over to QoSProfiles and continue there.