[Website] Reflect Archived API Repositories (ShortMessageService, SiteToCloudVPN, HomeDevicesQoD)

[albertoramosmonagas]

Context

Following a TSC decision, the API Backlog WG has started the Repository Transition → Archived activities for the following API repositories (each tracker issue contains the rationale and evidence of inactivity / lack of traction):

• ShortMessageService — [Repository Transition → Archived]: ShortMessageService APIBacklog#285
• SiteToCloudVPN — [Repository Transition → Archived]: SiteToCloudVPN APIBacklog#284
• HomeDevicesQoD — [Repository Transition → Archived]: HomeDevicesQoD APIBacklog#283

What has already been done (Backlog / Repo hygiene)

For each of the three repositories:

• Removed the repository topic and set the correct topic: archived-api-repository
• Closed open issues to reduce noise and clearly signal the repository is not maintained
• Created a PR adding an archival notice to the README (so the GitHub landing page is unambiguous)

At this point, the main open item is the CAMARA website: how we represent archived repositories on the public site and in the API overview.

Ask to Marketing / Outreach WG

We need guidance + execution on how to reference archived APIs on the CAMARA website, including a repeatable pattern (this is the first time we apply the “archived repository” process end-to-end).

Decisions needed:

1. Remove vs keep the API page(s) on the website
2. If kept, how to label them (banner, badge, “Archived” status, disclaimers)
3. Where to list archived items (e.g., separate “Archived APIs” section)

Proposed handling per repository (initial recommendation)

A) ShortMessageService + SiteToCloudVPN

Recommendation: remove from the main API overview and remove their pages entirely (or redirect to a generic archived list), because there is minimal historical value and almost no traction.

B) HomeDevicesQoD

Recommendation: keep the API page, but:

• Add a very visible Archived banner: “This API repository is archived and not maintained by CAMARA.”
• Remove it from the main API overview table
• Optionally list it in an “Archived APIs” section with a short note + link to the archived repo

Suggested website pattern (standardize going forward)

Create an “Archived APIs” section/page on the CAMARA website with:

• API name + link to GitHub repo
• Archive date (month/year)
• Reason in 1 line (e.g., “inactive / no maintainer support”)
• Clear disclaimer: “Not maintained, not part of meta-releases, no roadmap”

[MarkusKuemmerle]

An API repository is visible in the following artefacts, so when archiving API repos all these have to be considered:

• GitHub: Solution see above, done for the 3 APIs
• Maintainer and Codeowner teams: Solution open, ToDo for the 3 APIs (@hdamker)
• Mailing List: Solution open, ToDo for the 3 APIs (@hdamker)
• Wiki: Move it to "Archived" section, done for the 3 APIs
• Website: Remove links to API description in API Overview table and in menu, but keep API description in background, add disclaimer "Archived dd.mm.yyyy, not maintained, not part of meta-releases, no roadmap". With this the API description is still reachable by direct link if needed (e.g. for operators who have still implemented it). ToDo for the 3 APIs.
• Presentation: Remove archived APIs, ToDo for the 3 APIs

@hdamker: What do we need to do in Release Management GitHub / Wiki and in the project automation?
@hdamker: We should add this archiving instruction to the ops playbook

I would like to bring the proposal into the next meeting of the Outreach Commitee to finalize the website and presentation piece.

[hdamker]

Thanks @MarkusKuemmerle for the comprehensive list. Parts of it are already mentioned in the "Unified Clean-up Process", but you are right that the detailed checklist should be documented in other form.

An API repository is visible in the following artefacts, so when archiving API repos all these have to be considered:

• GitHub: Solution see above, done for the 3 APIs
• Maintainer and Codeowner teams: Solution open, ToDo for the 3 APIs (@hdamker)

I propose to delete the teams, which were created dedicated for the repositories, as they don't have any operational function for read-only repositories. The last team setups are documented in the archived repository (CODEOWNERS and MAINTAINERS.MD file).

• Mailing List: Solution open, ToDo for the 3 APIs (@hdamker)

Depending on the content of the mailing lists I would either delete or only lock them. In latter case we need a final message, and then we can lock them (= read-only, no new posts).

The concrete lists:

• HomeDevicesQod: meeting announcements only, no discussions. Proposal: delete (minutes are documented in GitHub/Wiki)
• ShortMessageService: only 3 messages, proposal: delete
• Site2CloudVPN: meeting announcements only, proposal: delete

• Wiki: Move it to "Archived" section, done for the 3 APIs

• Website: Remove links to API description in API Overview table and in menu, but keep API description in background, add disclaimer "Archived dd.mm.yyyy, not maintained, not part of meta-releases, no roadmap". With this the API description is still reachable by direct link if needed (e.g. for operators who have still implemented it). ToDo for the 3 APIs.

Ok and important for HomeDeviceQoD as it was part of a meta-release, the historical record makes sense.

But I'm not sure about the other two ... no release which could have been implemented. The descriptions were published too early (before a release candidate), are outdated and will age even more as they are not maintained. My proposal would be to drop them completely or replace with a short placeholder, pointing to the archived repository, but without the prior description.

• Presentation: Remove archived APIs, ToDo for the 3 APIs

@hdamker: What do we need to do in Release Management GitHub / Wiki and in the project automation?

For this first case there was an implementation change of Release Collector necessary, adding the proper handling of archived repositories. Please review camaraproject/project-administration#147 and camaraproject/project-administration#148. In future cases it will be a single workflow run to get the release reports for meta-release and across the portfolio updated. See for example at https://hdamker.github.io/project-administration/fall24.html how the archived repository is represented. (cc: @tanjadegroot)

Note: the current change and archiving is only affecting the lifecycle status of the repository. What we need in addition is a lifecycle overlay for the APIs (active -> deprecated -> retired/obsolete) ... but that's another story.

@hdamker: We should add this archiving instruction to the ops playbook

We need to decide about the future of the ops playbook, I propose to bring it into the public for transparency. E.g. as the archiving is changing the project structure we should follow the project charter and document the procedure in public (e.g. in Governance documentation, technical details in project-administration)

[MarkusKuemmerle]

The 4 APIs mentioned in the issue title are now archived in the website too.
@hdamker Do you take care of the other tasks I've mentioned above?