typelevel / typelevel/tsc

Self-attested maintenance status via MAINTAINERS.md + annual ping (organizational projects)

Open
#210 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 a user evaluating whether to adopt a Typelevel library, I want each project's maintenance status to be self-declared by its maintainers and periodically reconfirmed, so that I don't have to guess from raw git activity whether a quiet project is stable or abandoned.

Approach (deliberately lightweight)

No central score, no dashboard, no TSC judgment call on individual project health. Two ingredients only:

  1. MAINTAINERS.md on every Organization/Affiliate project: who is committed, and when that was last confirmed.
  2. An annual automated ping: a bot opens an issue asking current maintainers "are you still committed?". A confirmation just updates the date in MAINTAINERS.md — nothing else happens. "Yes, but I'm busy" is a complete and sufficient answer.

If the ping goes fully unanswered after the agreed number of reminders, the project is handed to the fallback process defined in the linked deprecation-process ticket. That hand-off is the only consequence defined here — this ticket does not decide what happens next.

Why not a score/dashboard

  • A centralized score (e.g. commit/release frequency) is already known to be noisy in this org: scala-steward's automated commits make "last update" meaningless as a raw signal.
  • It would misjudge stable-but-quiet projects as dead (the Spire case raised in the original discussion) — activity level doesn't distinguish "abandoned" from "finished."
  • A public low "health" score is discouraging to volunteers and risks being self-fulfilling.
  • Building and maintaining scoring infrastructure competes for the same scarce volunteer time this whole effort is trying to protect.
  • The raw signals (last commit, last release) are already public on GitHub; what's missing isn't more data, it's a current confirmation from the person who actually knows.

Acceptance Criteria

  • A minimal MAINTAINERS.md template is defined (maintainer(s), last confirmed date, how to reach them).
  • An automated annual ping mechanism is defined: what triggers it, how many reminders, over what time window, and where it posts (e.g. an issue on the project itself).
  • The escalation point is defined: after N unanswered reminders, the project is handed off to the fallback process (linked ticket).
  • No score, dashboard, or TSC judgment on individual project quality is introduced as part of this ticket.
  • Rolled out to all current Organization and Affiliate projects.

Non-Goals

  • Any scoring/dashboard mechanism (rejected, see above).
  • The deprecation/retirement process itself → linked ticket.
  • Security backstop policy for actively maintained projects → typelevel/tsc#196

Open Questions

  • Exact reminder cadence/count before a project counts as "fully unanswered."
  • Where does the ping bot live technically (extension of typelevel/steward, a new GitHub Action, something else)?

Related


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.