Discoverability and Engagement: starting the conversation

  • I think it’s also useful to list things that we don’t want to see in My first thought when I hear “community engagement” is (for some reason) “adding social features”. I’m not assuming that anybody is actually proposing this idea, but just to be clear, I wouldn’t like to see e.g. a rating system as implemented in e.g. Google Play or WordPress Plugins on Those examples in particular only “engage” commentators that are unlikely to participate in the community in a constructive way. Even with the freeform-textfield removed (leaving just the star-rating), I don’t think there’s actually anything to learn out of those other than to never look at comment sections. On a related note I would say that crate authors have the “right” to define their own communities, and that should rather avoid interfering with that by forcing their own one on the author when all they want to use is the package index.

    I guess the reason why such things are implemented in the first place are to give stats about which crates are popular/“any good” and which are not. As far as I’m concerned the download count has done this job well enough for Python’s package index PyPI and What would be nice to see is to count multiple downloads from the same IP address as a single download, to account for automated builds. Breakdown by country, rust version…

  • What I’ve also found interesting are regression reports (example). For some reason we have the resources to just build almost all of I wonder if this data could be fed back into, to determine which crates still build under the latest Rust version and which do not. On a related note I’d like to see in which crates require nightly features and which don’t.

  • When I determine whether a project is still alive, I found GitHub’s “Pulse” stats to be very useful. I wonder if this data can be put onto as well.

  • npm has pretty informative statistics (including some data from GitHub). I also find the week/month/year breakdown much more “useful” (for some definition of that word) than the graph currently has. I suspect there’s more to steal from NPM too.

  • Reverse dependencies are not exposed in’s UI. I would love to have a list of the most popular (most downloaded) reverse dependencies of a package.

  •, a package-index-index, has some useful search filters (search by license, keyword, …). Also shows reverse dependencies!