[Repository Transition → Archived]: ShortMessageService

[albertoramosmonagas]

Transition Type

Sandbox → Archived

---

Problem description

This issue is raised as part of the unified clean-up process to evaluate whether the ShortMessageService API repository should be considered a Phase C – Repository With Partial Progress candidate for archiving or reassignment.

ShortMessageService shows the following characteristics:

• Repository status

  • The repository camaraproject/ShortMessageService exists with README and YAML present.
  • The YAML / API draft exists but has no formal versioning or validation evidence.
  • There is a tag r0.1 dated 15 May 2024, but there is no indication that this corresponds to a reviewed release or to participation in any official CAMARA meta-release.
  • The wiki/documentation space exists but has not been updated and does not reference recent work or planning.

• PR and issue activity

  • There are 3 open pull requests, but: they are old (originating in 2024) or are automation/admin PRs (e.g. workflow/migration), with no functional impact on the API definition.
  • There are open issues in the repository.
  • Across these PRs and issues, there has been no substantive response or follow-up from the working group or the listed code owners.

• Working Group engagement

  • There is no recent WG engagement: No visible feedback on issues/PRs, no evident progress on validation, design, or meta-release planning.
  • ShortMessageService has not been included in any CAMARA meta-release (no meta-release tags, no Release WG references, no operator-adoption signals).
  • There are no recent mentions of this API in API Backlog or Release WG discussions.

In practice, ShortMessageService is a repository with partial progress: there is a basic structure, README, and YAML draft, but no validated release, no formal meta-release participation, no WG engagement, and no clear roadmap. This matches the criteria for Phase C – Repository With Partial Progress in the clean-up process and makes it a candidate for either archiving or transfer of ownership if a new sponsor steps in with a concrete evolution plan.

---

Expected action

This issue is intended first as an evaluation request and then as the trigger for the formal Phase C clean-up governance flow.

1) Evaluation by API Backlog WG

Confirm that ShortMessageService:

• Fits under Phase C – Repository With Partial Progress (YAML present, but no reviewed release, no validation/evidence, no WG engagement).
• Meets the clean-up criteria for Phase C (inactivity, no validation assets, no meta-release participation, maintainers/code owners unresponsive).

The API Backlog WG is requested to evaluate whether:

• There is a realistic path forward (e.g. a new owner and concrete evolution/validation plan), or
• The repository should be proposed for archiving under the unified clean-up process.

2) Standard post-meta-release clean-up flow for Phase C

Once the evaluation confirms that ShortMessageService qualifies as a Phase C candidate:

• Post meta-release review: Include ShortMessageService in the post-meta-release clean-up review as a Phase C repository with partial progress.

• Notification to code owners / maintainers:

  • Notify the current code owners / maintainers via GitHub comment (linking this issue).
  • Clearly state that the API is being considered for archiving or reassignment under the clean-up process.

• 4-week response window:
  Allow for: Raising objections, proposing a concrete evolution and validation plan, or taking over ownership of the API.

  If no viable evolution plan or new ownership is proposed within that period, the archival recommendation stands.

• Escalation to TSC:
  After the 4-week window, and assuming no credible plan is agreed: Submit this transition request and the Phase C evaluation to the TSC with the recommendation to proceed with archiving ShortMessageService.

• Execution upon TSC approval: Once the TSC acknowledges/approves the decision (archive vs. reassign):

  • If archived:
    1. Archive the GitHub repository camaraproject/ShortMessageService (read-only, archived badge).
    2. Update the API backlog entry for ShortMessageService:
       • Change status to “Archived”.
       • Move it to the Archived section, preserving traceability.
    3. Update any related CAMARA wiki page(s) for ShortMessageService:
       • Change lifecycle status to Archived.
       • Move or tag the page under the Archived APIs section.
    4. Ensure public-facing resources clearly mark ShortMessageService as Archived (or remove it from active API listings).
  • If reassigned: Document the new owners and agreed evolution plan in this issue and in MAINTAINERS.md, and keep the repo active with an updated roadmap, milestones, and validation plan.

---

📋 Checklist for Archiving Repository (Phase C candidate)

• API is no longer maintained or used
  There is no ongoing development, no recent responses from the working group or code owners to open PRs/issues, and no visible roadmap or validation activity.
• No significant activity in the last 6–12 months (or declared sunset)
  The last meaningful work dates back to 2024 (with only old or automation-related PRs) and there has been no substantial progress on validation, releases, or WG alignment since then.
• A formal deprecation or retirement reason is provided
  The de-facto reason is lack of ownership, no WG engagement, no validation, and no meta-release participation. This issue documents that the API currently has no active sponsor or evolution path and is therefore being proposed as a candidate for archiving under the unified clean-up process.
• Decision acknowledged by API Backlog WG
• Decision acknowledged by TSC

---

Additional context

• Repository: https://github.com/camaraproject/ShortMessageService
• Status summary:
  • README and YAML present but without meeting links, validation evidence, or meta-release references
  • Tag r0.1 (15 May 2024), but no reviewed release or meta-release participation
  • Wiki exists but has not been updated
  • No recent mentions in Backlog or Release WG
  • 3 open PRs (old or automation, with no WG/owner response), open issues with no WG/owner response

CC: @camaraproject/short-message-service_codeowners, @camaraproject/short-message-service_maintainers, @camaraproject/admins, @camaraproject/api-backlog_maintainers, @camaraproject/marketing_maintainers

[albertoramosmonagas]

Decision accepted and adopted at the TSC meeting on 15 January 2026 with no objections.

[hdamker]

Progress update on archival preparation:

• Repository topic updated: added archived-api-repository, removed sandbox-api-repository
• Closed 3 stalled issues (Scope change within QualityOnDemand sub project - removed initial limitation to mobile #25, New Proposal - Capability and Runtime Restrictions #22, API to Request the Status of the Network Traffic #9) and 3 stalled PRs (New Proposal - Steering of Roaming Management #24, New Proposal - Carrier Wholesale Pricing #23, New Proposal - Customer Premise Equipment Management #21) with reference to this archival decision (this was done as preparation for a clean archival, not originally part of the checklist)
• Created PR for the README archival notice: Add archival notice to README ShortMessageService#26

@albertoramosmonagas please review the PR and approve, I will merge and archive the repository. remaining afterwards are the update of APIBacklog.md and the move in the wiki