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

[jepfp]

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

• Split out: Define deprecation process #211
• Related, not merged: typelevel/tsc#196

---

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