Draft Proposal: Clean-up Process for Inactive Onboarding Trackers and Repositories

1. Status & Next Steps

Draft under discussion by the API Backlog Working Group

Main issue: #199
Last updated: 03 October 2025

This draft proposal is currently being refined by the API Backlog Working Group, and will be presented to the TSC for feedback and decision.

If approved, the process will be added to the official lifecycle documentation in API-Onboarding-and-Lifecycle.md, and enforced during biannual backlog reviews.

2. Background

CAMARA currently provides a frozen status for API Proposals that become inactive during early discussion phases. However, there is no equivalent governance mechanism to manage inactivity after onboarding has been approved, particularly for:

• Onboarding trackers that are created but remain incomplete for long periods

• Repositories that are created but show no progress, no commits, no validation or operator engagement

This creates catalog noise and gives a false sense of progress, despite the lack of activity. It also creates ambiguity about whether these APIs are still intended to move forward.

3. Objective

This proposal introduces a unified, traceable and reversible clean-up process for contributions that stall during or after onboarding — whether the onboarding tracker is incomplete or the repository shows no evolution.
It extends the lifecycle governance already applied to API Proposals (frozen) to cover trackers and repositories in a consistent and structured way.

4. Scope of Application

The clean-up process is designed to handle four distinct phases in the lifecycle of CAMARA contributions:

Each of these phases requires distinct criteria and escalation procedures, described below.

5. Review Cadence and Governance Flow

• Reviews take place twice per year, after each meta-release cycle (Fall and Spring)

• The API Backlog Working Group conducts the review and notifies responsible parties via GitHub comment

• A 4-week window is granted to respond and show progress or intent

• TSC involvement is required before any archival:

  • Phase A–B: TSC is informed, and may confirm archival

  • Phase C–D: TSC must formally approve archival

• Before archival, contributors may hand over ownership to another CAMARA member if there's interest

• Reactivation is always allowed via a new API Proposal referencing the archived asset

6. Archival Criteria per Phase

6.1. Phase A – Failed Onboarding (no valid repository)

Triggered if any of the following are true after 4–6 weeks from tracker creation:

• No code owner nominated in GitHub

• Code owner did not join CAMARA GitHub org or pass EasyCLA

• Checklist not updated, no YAML/README present

• Repository has not been created

Outcome: API Backlog WG may offer the tracker to another party before closure. If no new owner is identified, the tracker may be closed and archived after confirmation by the TSC.

6.2. Phase B – Repository Without Artifacts

Triggered if ≥ 3 of the following are true after 6 months:

• No commits, PRs or file changes since repo creation

• No README or YAML uploaded

• No validation activity or wiki content

• Not proposed for inclusion in any meta-release

• No WG or operator engagement

Outcome: API Backlog WG may offer the repository to another party before proposing archival. If no new maintainers are identified, the tracker and repo are proposed for archival; TSC is notified and may confirm.

6.3. Phase C – Repository With Partial Progress

Triggered if 3 or more conditions are met after one or more meta-release cycles:

• YAML uploaded, but no meta-release submission

• No validation, operator support or WG engagement

• Code owner inactive or unresponsive

• No commits or issue activity in last 6+ months

Outcome: TSC formally reviews; the API Backlog WG may offer the repository to another party before closure.

6.4. Phase D – Repository With Reviewed Release (RC or 0.1.0+)

Treated with the highest sensitivity. Requires case-by-case review by TSC. Criteria may include:

• No activity post-release for multiple cycles

• Code owner left and no successor nominated

• No WG validation or engagement after release

• No evidence of usage or interest in the community

• Explicit statement by the current maintainer and codeowner group confirming that they are no longer interested in evolving the API towards a stable release, together with a request to archive the current state (which remains publicly available).

Outcome: TSC decides whether to archive, hand over to new maintainers, or wait longer.

7. Archival Actions

If a tracker or repository is archived, the following actions take place:

Nothing is deleted. All content remains visible and traceable in GitHub.