typelevel / typelevel/tsc

Define deprecation process

Open
#211 0 comments 0 reactions 1 assignee View on GitHub

@jepfp is already working on this.

Since Sep 18, 2026.

Dominant language
No language data
Stars
11
Forks
4
Avg merge
1h 49m
Merged PRs (30d)
2

Description

User Story

As maintainer of an organizational project, I want to know the process of deprecating/archiving a project, so that I know what would happen in case I initiate it.

Approach (deliberately narrow)

The default is: the TSC does not initiate deprecation. A maintainer who answers the annual ping (see #210) and confirms they still care about the project — however busy they are — is done; that answer is sufficient on its own, nothing else happens.

The TSC only gets involved in two specific cases:

  1. Voluntary retirement: a maintainer themselves asks the TSC/dedicated group for help retiring their project. The TSC assists on request, it does not propose this unprompted.
  2. Fallback, no response at all: the annual ping from #210 goes fully unanswered after the agreed number of reminders. This is the one case self-attestation structurally cannot cover — nobody is left to ask — and it is also where the foundation's own backstop responsibility (controlling the group id, security releases per typelevel/tsc#196) requires someone to act, since an unmaintained Organization Project left untouched quietly implies a support guarantee that no longer holds.

Activity level, release frequency, or any other "health" signal is explicitly not a trigger on its own — only confirmed non-response is.

Acceptance Criteria

  • Default rule documented: the TSC does not initiate deprecation for a maintainer who confirms continued commitment, regardless of activity level (separate from #196 security-backstop obligations, which can still require action independently).
  • Voluntary path documented: a maintainer may ask the dedicated group to help run the retirement process for their own project.
  • Fallback path documented: triggered only when the annual ping (linked ticket) goes fully unanswered; defines the steps from there (further outreach attempt, downgrade Organization → Affiliate, archival, public announcement).
  • A dedicated group of 3 people is defined, responsible for handling both the voluntary and fallback paths.
  • The process is documented (e.g. as a markdown doc in this repo, similar to resources/).
  • The process is communicated to all maintainers of Typelevel Organization projects, so they know exactly what does and does not trigger it.

I want to declare: I used AI to challenge my thinking on this proposal and to help me write it clearly in English.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.