-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stale Packages #231
Comments
A stale library shouldn’t be getting a low score just because there are not recent commits or have been recently publish. There is a state were a package is considered “finished”: it has near 0 issues, is stable (>=1.00) and many other criterias. The current algorithm might be a bit naive but there were a lot of complains about stable and final small libraries getting punished for not having updates. This shouldn’t be the case, and the “finalized” check solved that. Moreover, you can request the package details by clicking in the “view analysis info” in each result and check the “analyzedAt” field which will give you the latest date in which packages were analyzed. |
Thanks for clarifying. It does seem problematic in some cases (i.e. wrappers no longer keep up with the API they're wrapping, making them significantly less useful) but since the conversation's already been had I'm happy to close the issue. |
Heyo,
I keep running into very old packages that have very high scores, particularly in maintenance. For example, I recently looked for a Shipwire library. The top result was a library that hasn't been published or committed to in over 2 years but has kept a 100% maintenance rating (API call gives 0.9 to all four maintenance scores). The only way I can see this happening is if stale packages are not being enqueued properly. Any insight into how the Stale observer works and what it's missing (or what I'm missing) would be greatly appreciated.
The text was updated successfully, but these errors were encountered: