You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
Fallback, no response at all: the annual ping from Self-attested maintenance status via MAINTAINERS.md + annual ping (organizational projects) #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 Specify the support policy for organization projects #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.
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:
Activity level, release frequency, or any other "health" signal is explicitly not a trigger on its own — only confirmed non-response is.
Acceptance Criteria
resources/).I want to declare: I used AI to challenge my thinking on this proposal and to help me write it clearly in English.