How do we remove crates?

[icefoxen]

There's clutter-y chaff in some lists... corange-rs is 3rd in engines even though it hasn't been touched in 3 years.

There has to be objective criteria for removing things or else it can get contentious. One person says "We should remove A" and then the owner of A says "wait, why?" and there's an argument. An off-the-top-of-my-head idea for how that might work is, a crate gets removed if:

• A crate is unmaintained and has no commits for X time (6 months? A year?)
• And it isn't obviously useful in its current state (a crate such as an audio codec may not get many commits because it's basically done)
• And someone submits a PR for the removal

[mbillingr]

What objective criteria can determine usefulness?

Hmm.. maybe no such criteria are needed if the removal PR is required to contain a succint rationale...

[icefoxen]

I dunno! Any suggestions? :D

[mbillingr]

No good suggestions from my side :)

A few objective criteria that do not quite measure usefulness come to mind:

• number of recent downloads on crates.io
• compiles on current Rust
• declared abandoned by author/maintainer

[doppioslash]

We could grey abandoned crates out, or put them in a separate category.
There may still be useful code in them, for reference, so I wouldn't like to just chuck them out.

[workingjubilee]

I suggest having the lowest threshold being editions since those are a thing now: about once/edition, if it wasn't touched in ~an edition and doesn't represent a "finished work" that is thus "continuously useful"? It gets booted (or downgraded to a historical archive) without comment required. Essentially, someone who was introduced in 2019 to Rust (hi!) will be very confused by the code in a library that was written at the beginning of 2015, when Rust 1.0 was still alpha, so even reading those is less useful.

And from where I am standing, I still kind of blink at the idea of trying to use anything written before 2018. It's still legible, but I am cozier with the newer idioms.

[icefoxen]

That's... actually not a terrible idea IMO.

[PatrickHoward]

Leaving comment here instead of opening a new issue about this..
It looks like there are also some crates that have been yanked/discontinued from Crates.io... nCollide in particular (which has been replaced with nCollide2D and nCollide3D) is the one that comes to mind.
So might I propose adding another criteria for removing crates from the website's list?

• If a crate has been removed from Crates.io

[ozkriff]

One more case for the historical archive, i guess? https://amethyst.rs/posts/amethyst--starting-fresh

[stefnotch]

I propose at least having a the following rules

• if the the current maintainers of a crate clearly deprecate it (e.g. Amethyst, nCollide) => remove it or replace it with the new version
• if it looks unmaintained, fulfilling all of the criteria (subject to debate)
  • no updates for a year
  • author and maintainers don't seem to respond
  • not a finished crate (e.g. an audio codec can be a finished crate)

If a crate seems useful, but isn't being maintained, then it might be worthwhile to

• either remove it, since recommending an unmaintained crate doesn't seem ideal
• or point it out that it's unmaintained, and thus encourage people to step up and hopefully get the crate back into shape :)

I also think that the consequences of removing a crate too soon are not that severe, because re-adding it isn't hard at all. Instead it's way more useful to keep these lists a relatively current snapshot of the state of the ecosystem.

[coderedart]

This issue has been open for 4+ years now. what even is this blocked on?

I thought arewegameyet.rs itself was abandoned because it showed so many old entries like amethyst or conrod etc.. which are explicitly abandoned by the authors themselves.

The older projects just increase noise and diminish the utility of the website imo.

This is not an "official" list, so we don't need rigid rules for deprecation either.

1. Did the project have any updates in the past six months? No? then deprecate.
2. If the project is done. Then, keep it.
3. If the project is explicitly abandoned by the authors with an announcement? deprecate.

If the rules don't work, they can be evolved later. But listing the abandoned projects mixed with the latest maintained projects is just not the way.