Self-attested maintenance status via MAINTAINERS.md + annual ping (organizational projects)
@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:
MAINTAINERS.mdon every Organization/Affiliate project: who is committed, and when that was last confirmed.- 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.mdtemplate 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: #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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.