Thinking about this more I’m of the opinion that showing CI badges is to serve a proxy metric for code quality. All other things being equal, I would trust a project that has CI set up (I’d also check to see what they’re running in CI). Even though the CI doesn’t correspond to the current version, I don’t see that as a problem. In theory, if there’s CI, a released version should have passed all of it, so I think it’s reasonable to assume that’s true.
If you look at these through this lens you really only see issues of scale (really with number of badges), but we aren’t certain those will actually end up being a factor. The whole way crate metadata is presented and the larger issue of presenting “crate quality” conceptually is currently under experimentation, I don’t think there’s any actions to do about this right now. It’s to keep collecting feedback from more people and see what the community finds useful. Currently it seems like you don’t think it’s useful, but that’s fine as it’s not an undue burden to have this functionality, and various other people find it useful. So let’s see where things go. Once we start to run out of UI space I suggest this topic is due for a revisit, until then let’s keep collecting data.
I’m really against trusting CI badges. My main point on choosing crates is maintenance (last update in at least on year).
CI badges doesn’t mean:
- It still builds on current release
- It’s well maintained and bugs are fixed
- It’s not even an indicator of well tested
It only means that the author is clever enough to use an IDE and compiled the code locally.
But all of what you say is IMHO besides the point. Badges are an indicator of crate quality (we’re really only arguing about how much throughout this thread) and can therefore b useful to people when shopping for crates. Exposing that information to users was not onerous to build and is not onerous to expand or maintain (I added the GitLab support FWIW). Therefore I think displaying them is useful to some users and currently does not get in the way of other UI/UX needs for crates.io. Given that, IMHO it seems premature to remove them.
I agree that it is currently a good indicator of quality, but I think we may need to do something to ensure it continues to be that.
It means the author has put in at least the minimum amount of effort towards setting up a CI like travis to run the code, and that it compiles - while this definitely isn’t much, it is more than say, a hobby crate that someone just published on crates.io for fun. I can see that this might be worrying to some though, in case it becomes the “default” for people who have put very little effort into their crate to still have.
I’d argue for not removing CI badges, but adding on other badges to augment their usefulness. “last update” and “number of updates” badges would not only be useful in itself, but make any CI badges also infinitely more useful. An indicator on the search page for if the crate has documentation and repository links set up could also be another good “minimum effort” indicator so we can see if that’s been done even for crates who don’t have travis-ci set up.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.