Suggestion: definition of "at risk" packages using heuristics

A recurring topic I'm seeing in the open issues right now is how we want to make an impact across the ecosystem by identifying packages who are themselves in bad shape or depend (transitively) on packages that are in bad shape.

I believe there is an opportunity for this group to work on a set of heuristics to (either manually or programmatically) identify what it means for a project to be "at risk".

Here's a rather simplistic example of what such a set of heuristics might look like:

A package is classified to be at-risk when one of the following is true:

• The package has open GitHub issues or PRs that are more than X months old and have no interaction from an owner/collaborator.
  • The threshold is X/2 when the package has more than Y number of downloads per week - to correct for the much larger impact extremely popular packages might have.
• The package generates npm deprecate warnings from one of its dependencies
• The package uses some other explicit signal that the owner is no longer interested in maintaining the project moving forward.

Once it can be "tuned" and we feel confident in it, we can begin surfacing the results - projects which are classified as at-risk - in many places. We may be able to work with npm, Inc. to utilize this in the CLI or on the website. We might publish our own website. We might publish guidelines or a tool that application and/or package authors can use to analyze their own dependency tree. We could supply a README badge service. The possibilities are endless, but I think it starts with creating a common definition of what we think at-risk looks like.

Refs:

• This would be a prerequisite for #93.
• I personally think #78 should be reconsidered, but this would be required to make progress on that. I personally think of email as one way to surface the results of this set of heuristics applied to the npm ecosystem, but maybe not the best way.
• The anecdote in #73 is a good example of a case our heuristics should classify as at risk, and collecting more of these anecdotes should help us "tune" our algorithm.
• My comment from earlier is mostly about asking why npm deprecate as an opt-in way to signal this sort of information isn't working.
• I think #6 is related insofar as one "business model" might be "completely unfunded and unresourced". This could serve as an explicit signal from the owner that the project is at-risk.
• We could build the list in #14 fairly easily if we had this definition.=

No files, tests, or implementation entry points are identified. Start by reviewing the referenced issues #93, #78, #73, #6, and #14 plus the linked comment to understand the competing use cases; the issue needs an agreed definition of “at risk” and an actionable scope before implementation can begin.