[Repository Transition → Archived]: VoiceNotification

[albertoramosmonagas]

Transition Type

Sandbox → Archived

---

Problem description

This issue is raised as part of the unified clean-up process to evaluate whether the VoiceNotification API should be treated as a Phase A – Failed Onboarding (with an effectively empty repository) and therefore be closed and archived, together with its associated repository.

VoiceNotification shows the following characteristics:

• Onboarding tracker status

  • The onboarding tracker for VoiceNotification is still open and has been inactive for an extended period, with no recent updates to the onboarding checklist.
  • Initial onboarding steps remain incomplete: no evidence of basic setup being completed, no commits or API assets associated with the onboarding activities.
  • The designated code owners have been notified as part of the post–meta-release clean-up: they were informed that the tracker had been identified as inactive under the unified clean-up process.
    • A response window (4 weeks) was provided, clearly stating that, in the absence of updates, the API Backlog WG would propose to close and archive the onboarding tracker, with the option to transfer ownership to another CAMARA member.
  • No response has been received from the current code owners within this response window.

• Repository status

  • The repository camaraproject/VoiceNotification exists, and:
    • A mailing list and a wiki page have been created.
    • However, there has been no activity to properly set up the repo: no meaningful README file, no MAINTAINERS file , no visible API specification or validation assets (YAML, tests, etc.).
  • There have been no substantive commits, no test assets, and no sign of operator engagement.
  • In practice, the repo is a shell without artifacts, matching the spirit of Phase A/B (Failed Onboarding / Repository Without Artifacts) in the clean-up process.

• Working Group engagement

  • There is no observable recent WG activity related to VoiceNotification: no feedback or follow-up in the onboarding tracker, no evidence of this API in Backlog or Release WG agendas, minutes, or planning.
  • No meta-release participation, no tagged releases, and no operator validation or pilots are recorded.

Given the lack of onboarding progress, the absence of artifacts in the repository, and no response from the code owners after explicit notification and a defined response window, VoiceNotification meets the criteria for Phase A – Failed Onboarding and is therefore a strong candidate for closing the onboarding tracker and archiving the associated repository.

---

Expected action

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

1) Evaluation by API Backlog WG

Confirm that VoiceNotification:

• Fits under Phase A – Failed Onboarding: Onboarding tracker open and inactive, initial onboarding steps incomplete, and repository created but without meaningful artifacts (no README, no MAINTAINERS, no validation assets).
• Meets the clean-up criteria: no progress after an extended period, no response from the designated code owners despite explicit notifications and a defined response window.

The API Backlog WG is requested to confirm that:

• There is no active owner or realistic onboarding plan, and
• The tracker and repository should therefore be proposed for closure and archiving under the unified clean-up process.

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

Once the evaluation confirms that VoiceNotification qualifies as a Phase A candidate:

• Post meta-release review: VoiceNotification has been identified as inactive as part of the post–meta-release clean-up review (aligned with the unified Clean-up Process).
• Notification to code owners / maintainers: The current code owners have already been notified, with:
• A clear explanation of the inactivity finding.
• A defined response window (4 weeks).
• An explicit statement that the tracker would be proposed for closure and archival in case of no response.
• 4-week response window:
  • A response window was granted.
  • No confirmation, objections, or onboarding plan were received from the code owners within this period.
  • As a result, the archival proposal now stands.
• Escalation to TSC:
  After the elapsed response window and validation of the above conditions:
  • Submit this transition request and the Phase A evaluation to the TSC with the recommendation to:
    • Close the onboarding tracker, and
    • Archive the VoiceNotification repository.
• Execution upon TSC approval
  • Once the TSC acknowledges/approves the decision:
    • Close the onboarding tracker:
      • Close the onboarding issue with a clear note referencing: The inactivity period, the notifications sent, this clean-up evaluation, and the unified Clean-up Process section in Governance.
      • Indicate that reactivation would require a new API Proposal referencing the archived asset.
    • Archive the GitHub repository camaraproject/VoiceNotification:
      • Set the repository to archived (read-only, archived badge).
    • Update the API backlog / Governance records: If an entry exists for VoiceNotification, set its status to “Archived” and move it to the Archived section, preserving traceability.
    • Update wiki and public-facing resources:
      • Update the VoiceNotification wiki page:
        • Mark lifecycle status as Archived.
        • Move or tag the page under Archived APIs.
      • Ensure public-facing resources (if any) do not promote VoiceNotification as an active onboarding API.

---

📋 Checklist for Archiving Repository (Phase A candidate)

• API is no longer being onboarded or maintained
  Onboarding steps are incomplete, there has been prolonged inactivity, and the code owners have not responded within the response window.
• No significant activity in the last 6–12 months (or declared sunset)
  There have been no meaningful commits, no onboarding checklist progress, and no WG interaction over an extended period, including the clean-up review period.
• A formal deprecation/retirement rationale is provided
  The effective rationale is failed onboarding:
  • No completion of initial onboarding steps.
  • No artifacts in the repo.
  • No response from code owners after explicit notifications and a 4-week response window.
• Decision acknowledged by API Backlog WG
• Decision acknowledged by TSC

---

Additional context

• Repository: https://github.com/camaraproject/VoiceNotification
• Onboarding tracker: [Onboarding Tracker] Voice Notification #203
• Status summary:
  • Onboarding tracker inactive for an extended period.
  • Code owners notified (initial clean-up notice + final reminder before the end of the response window).
  • No response from code owners.
  • Repository exists but has not been set up (no meaningful README, no MAINTAINERS, no validation artifacts).
  • Mailing list and wiki page exist but show no recent activity.

CC: @niu-chinauicom, @camaraproject/admins, @camaraproject/api-backlog_maintainers, @camaraproject/marketing_maintainers

[ChinaUnicomXiaoDongrui]

@albertoramosmonagas hello I am Xiao Dongrui from China Unicom, I'm very sorry that our API has not been active in the Repositories for a long time. My colleagues @niu-chinauicom and I will continue to work on the Voice Notification API and Voice Notification code API. I hope to maintain our operation permissions in the repository and ensure its effectiveness. If there is anything else that needs to be done besides normal work, please let us know. Thank you

[ChinaUnicomXiaoDongrui]

@albertoramosmonagas hi I want to say this API(#286) is in the same situation. We once again apologize for the inactivity of these two apis in the Repositories. We will actively participate in Repositories contributions in the future @niu-chinauicom

[albertoramosmonagas]

Hi @ChinaUnicomXiaoDongrui, @niu-chinauicom,

Thank you very much for your reply and for confirming that you intend to continue working on the Voice Notification and Voice Verification Code APIs.

Just to clarify the context: the goal of the unified Lifecycle Clean-up Process is not to remove your permissions, but to make sure that Sandbox/onboarding APIs that stay inactive for a long time are either (a) clearly owned and progressing, or (b) cleanly archived with the option to be re-proposed later.

Given your confirmation, we can pause the archival proposal for these APIs, but we need to anchor this in some concrete next steps so that the Backlog WG and TSC see that the situation has really changed.

To keep both APIs active, could you please:

1. Ownership: Confirm that you will act as active maintainers for both VoiceNotification and VoiceVerificationCode.
2. Repo setup: In the next few weeks, update README.md, MAINTAINERS.md and CODEOWNERS in both repositories so they reflect the current scope and China Unicom maintainers.
3. Plan & timing: Share a short plan (in the tracker/issue) with a target meta-release and indicative dates for a validated YAML and initial validation assets.

From the API Backlog WG side, the idea would be: if we see this minimum setup and concrete progress in the next few weeks, both APIs will remain active in Sandbox. If there is still no visible progress (no commits, no validation work, no WG engagement) after that short window, we will resume the clean-up process and move forward with the archival proposal, without waiting for the next meta-release review.

Thanks again for your quick reaction and for confirming your interest. Once you share the points above, we will update the status of these issues accordingly so that the Backlog WG and TSC have full visibility.

[albertoramosmonagas]

We are closing this issue. The China Unicom team has expressed interest in continuing with the proposal. We will see the new changes starting in Q1 2026.

[ChinaUnicomXiaoDongrui]

yes, My colleague @niu-chinauicom and I are advancing the matter of the Voice Notification API. We hope we can continue to contribute content and also thank you for your assistance @albertoramosmonagas