As a minimum, the project should attempt to respond to significant problem and vulnerability reports. A project that is actively pursuing a badge is probably maintained. All projects and people have limited resources, and typical projects must reject some proposed changes, so limited resources and proposal rejections do not by themselves indicate an unmaintained project.
When a project knows that it will no longer be maintained, it should set this criterion to "Unmet" and use the appropriate mechanism(s) to indicate to others that it is not being maintained. For example, use “DEPRECATED” as the first heading of its README, add “DEPRECATED” near the beginning of its home page, add “DEPRECATED” to the beginning of its code repository project description, add a no-maintenance-intended badge
in its README and/or home page, mark it as deprecated in any package repositories (e.g., npm deprecate
), and/or use the code repository's marking system to archive it (e.g., GitHub's "archive" setting
, GitLab’s "archived" marking
, Gerrit's "readonly" status, or SourceForge’s "abandoned" project status). Additional discussion can be found here