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

Project health checks and display #355

Merged
merged 3 commits into from Dec 14, 2018

Conversation

Projects
None yet
2 participants
@colszowka
Copy link
Member

colszowka commented Dec 13, 2018

Detection of unmaintained projects came in highest in the recent community survey.

This PR adds project health checks to make it easier to make a quick assessment of the maintenance status of a project.

See checks.rb for the currently defined checks. For starters it's mostly about commit and release activity, hopefully over time we can add a few more of these.

The assessments have 3 levels: Green, yellow and red, depending on the status.

  • For red I picked a timeframe of 3 years (no gem release in 3 years, no commits in 3 years)
  • For yellow it's 1 year of inactivity

bildschirmfoto vom 2018-12-13 16 12 51

Let's see how this goes. From a cursory glance across categories the indication seems nice, at the very least it seems to be working well on some very popular and well-maintained projects as well as some clearly unmaintained ones. Once this is live I'd like to gather some feedback, for example if we have a lot of gems that have no release in a year but work perfectly fine maybe the timeframe should be changed - in the end it's just supposed to give some guidance, making a one-size-fits-all solution likely is impossible anyway due to the huge variety of libraries we have out there.

Here's what it looks like:

health

@colszowka colszowka merged commit 772984e into master Dec 14, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

colszowka added a commit that referenced this pull request Dec 14, 2018

@colszowka colszowka deleted the co-project-health branch Dec 14, 2018

colszowka added a commit that referenced this pull request Dec 14, 2018

colszowka added a commit that referenced this pull request Dec 14, 2018

colszowka added a commit that referenced this pull request Dec 14, 2018

colszowka added a commit that referenced this pull request Dec 14, 2018

@maxim

This comment has been minimized.

Copy link

maxim commented Dec 14, 2018

This is really helpful! 👍 Thanks for implementing it. One minor concern I have is that some untouched projects are simply finished. They have neither new features to add, nor bugs to fix, and it's not all that rare in the mature ruby ecosystem.

Perhaps a possible direction could be to consider commit activity against issues activity. Some heuristic along the lines of "if project has at least N stars, no commit activity, but significant issue activity a lot more recently than commits, it's probably poorly maintained", but "if this project has stars, but neither commit nor issue activity, it's probably finished". Maybe that would at least promote it back to "yellow" status. 🤔 This is just a general idea.

@colszowka

This comment has been minimized.

Copy link
Member

colszowka commented Dec 18, 2018

Thanks for your feedback @maxim! I tried to take a balanced approach that fits all different situations somewhat reasonably here. Like I wrote in the initial description, finding a perfect solution might be very tricky, there's just too much variance between how projects are set up. We have rails with it's monorepo hosting all it's gems, rspec with it's zero-changes-metagem and sublibraries in single repos, and libraries generally vary hugely in size. In general my goal is to give a good estimate and allow picking out some libraries that look like a good fit and then rely on the user taking a closer look based on the actual data and project links themselves.

That being said, I'm sure we can make a bunch of improvements here, this is just a starting point :)

If you (or anyone else reading ;) stumble across any libraries that get "bad" health checks, please do me the favor and report them here. If we have concrete examples with their data it's much easier to derive some rules based on said data.

Incorporating recent activity in particular would be wonderful, be it on commits, issues or PRs. If a project sees no PRs or issues being closed, that's probably a much better indicator than the current issue check of < 75% issues being closed, however that needs additional data to be fetched from github as well. Maybe we can introduce a closed PR / closed issues average date like it's already in place for the recent commits (which takes the last 100 commits and calculates their average date) for these as well, but again, for "finished" projects this will have a very different value from highly active, big projects. We'll see :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment