# Project Lifecycle Policy

Most of our projects are "Active" with issues getting opened, PR(s) filed, merges made with up-to-date CI jobs, and more. There are times when a project is doing something specific well and does not need constant care of an active project. There are also instances when a project is no longer needed or being used and should be retired. This document outlines the different "modes" for a project and the lifecycle policy requirements surrounding them.

Precedents and examples from other projects:
- [CNCF Project Archiving Process v1.0](https://github.com/cncf/toc/blob/main/process/archiving.md)
- [The Apache Attic](https://attic.apache.org/)

## Modes

Looking at the preamble we seem to the following labels we can use:
- Active Mode
- Maintenance Mode
- Archived Mode

Projects can move from Active to Maintenance, they could be revived to move from Maintenance to Active as well. Projects that are in Maintenance can move to Archived. The Archived projects are basically fair game for folks who want to fork under their own Github repos for example for their own use. We would try to keep as many projects Active as possible for as much time as possible. The value prop of Archived project is also clear, we basically cleanup anyone that depends on this project, tell everyone that this is basically out of community hands, we would not take on security or CVE resposibilities as well. Also given what Archived means, we know what a project cannot move directly from Active to Archived and will need to be under Maintenance mode until dependencies are cleaned.

## Peeling the layers

What's not clear is the middle one, the Maintenance mode, What does it mean? When can we mark some project as under Maintenance? What does it mean to be under Maintenance? Basically we are telling the community that:

- There is no concrete plan for any new features
- Incoming PR(s) will not be looked at in any regular cadence
- Issues being filed will end up being ignored
- Security related stuff will be taken care of
- Minimal upkeep say for golang updates, dependency updates will be taken care of
- There will be explicit guidance whether it is to be archived or not

Seems fair? The key here seems to be a key group of owners that can be relied upon for at least some minimum ongoing albeit delayed updates to the project.

When/How do we do this?

- Owning SIG can trigger the label changes. When in doubt, SIG-Architecture rules
- Usual community process(es) for decision making apply. We don't really need a KEP for this but there should be enough heads up and publicity to ensure if we can shake loose some contributors who may get interested
- Identification of specific members who can help with ongoing maintenance and add them to OWNERS to give them enough privileges to do the job.
- SIG Chairs or TLs can open PRs to add the label and a NOTE in the README.md for the project. A notice goes out to the mailing list(s), slack channels with a timer for lazy consensus (say 2 weeks?).

Oh the Archived projects can be moved to a different Github org (`kubernetes-retired`) once the SIG decides to archive it with the help of Github Admins. Before something can be archived, all references to the project will need to be eliminated
- projects that depend on this need to be cleaned up
- any images (container images?), artifacts (binaries?) that are being used need to be eliminated

So basically this means that the team that is pushing for Archival need to come up with a checklist of things to clean up, find people who can do the work and when the check list is wrapped up then the change can be triggered.

## What we will end up with

- Clear signal to the community on what to expect for different categories
- Clear plan of action and set of folks they can reach out to

What do you think?