Skip to content
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

Discussion: Out-of-date badge status / other activity metrics? #33

Open
ekzyis opened this issue Oct 17, 2020 · 4 comments
Open

Discussion: Out-of-date badge status / other activity metrics? #33

ekzyis opened this issue Oct 17, 2020 · 4 comments

Comments

@ekzyis
Copy link

ekzyis commented Oct 17, 2020

So is this more or less an "ironic" issue.

I stumbled across this repo because I stumbled across a repository of myself where the badge was still on "repostatus:active". This was definitely not the case because I didn't make a single commit in the last 2 years even though I always had in mind to further develop the idea of that project.

I found it quite ironic that I have seen that repostatus.org has a badge with "repostatus:active" and I was like "wow, let's check out what is going on in this active repository" to find out that the last commit was from 2018, just as with my repo who was still "active" :D

So I propose some feature to indicate better the current status of the repository without repository owner intervention. So basically as a solution for the problem that the badges themselves need maintenance. Maybe email notifications or an algorithm which calculates the "activeness" of a repo, looking at issue, PR and commit stats? A email would have probably reminded me to at least update the badge.

I know that this means a huge scope increase because currently, there are only badges but I do like the idea of this project and what it tries to solve.

If this repo is not active but this issue is seen, then if would be at least good to update the badge with "repo status:inactive".

With that said, this issue here goes full circle :D

@jantman
Copy link
Owner

jantman commented Oct 18, 2020

@ekzyis Yeah, this certainly is a bit of an ironic and circular discussion :)

So, for context, let's refer back to the current repostatus.org definitions:

  • Concept – Minimal or no implementation has been done yet, or the repository is only intended to be a limited example, demo, or proof-of-concept.
  • WIP – Initial development is in progress, but there has not yet been a stable, usable release suitable for the public.
  • Suspended – Initial development has started, but there has not yet been a stable, usable release; work has been stopped for the time being but the author(s) intend on resuming work.
  • Abandoned – Initial development has started, but there has not yet been a stable, usable release; the project has been abandoned and the author(s) do not intend on continuing development.
  • Active – The project has reached a stable, usable state and is being actively developed.
  • Inactive – The project has reached a stable, usable state but is no longer being actively developed; support/maintenance will be provided as time allows.
  • Unsupported – The project has reached a stable, usable state but the author(s) have ceased all work on it. A new maintainer may be desired.
  • Moved - The project has been moved to a new location, and the version at that location should be considered authoritative. This status should be accompanied by a new URL.

First, discussing repostatus.org itself, I guess it's either "Active" or "Inactive", and which one is really a subjective judgment. The reality is, there's not much activity on this repo in terms of issues, PRs, or commits. There are a few open issues which are years old, but none of them (as far as I remember) got enough community activity/interest/consensus for me to do anything more with them.

For me, personally, the line between "Active" and "Inactive" really boils down to how quickly I think I'll react to issues/PRs/support requests, not necessarily how often I'm committing. If a project (like this one) is "complete" in terms of the currently-desired features and doesn't have any known bugs, I'm (once again, personal opinion) fine calling it "Active" until something changes. So, for me, I'm fine calling repostatus.org active.

All that being said, the badge is only one possible indicator of the state of a repo... PRs, Issues, commit activity, etc. are all other indicators.

Defining an algorithm based on any of those other indicators is, in my opinion, both very subjective and likely outside the scope (not to mention the technical ability, since it's a static badge) of this project. For example, someone in some circumstances may care a lot about recent commit activity, whereas someone else or the same person for different purposes might only care whether issues are piling up without response or resolution.

Ideally, maintaners would periodically audit the status of all of their repos, and update as needed. There are parsers provided to assist with this, but I'll admit, it's been a while since I've reviewed the status of all of my repos and adjusted them as needed.

I'm certainly interested in feedback on this from the community, and opening a discussion here.

PS - Regarding subjective labels, the way I'm currently using Active/Inactive/Unsupported for my own repos is:

  • Active - I'm either actively committing, or at least will make a reasonable effort to respond to issues/PRs in a somewhat timely fashion.
  • Inactive - I'll probably revisit this at some point, and if you report a critical bug I'll try to at least respond, but don't expect a whole lot more than that except in rare bursts.
  • Unsupported - It's pretty much a black hole. Unless you open an issue offering to take over maintenance, don't expect a reply to anything.

@ekzyis
Copy link
Author

ekzyis commented Oct 18, 2020

Hey, thanks for your fast response! I must admit, while writing this issue, I looked upon the closed issues and saw that there was activity in one just about 2 weeks ago. So I definitely preemptively judged the status of this repo and got very wrong with :D But I still wanted to finish writing this issue to see what you would respond to the "how much can you trust a badge" issue (and also because I was quite amused by my little story and wanted to share it :D)

Defining an algorithm based on any of those other indicators is, in my opinion, both very subjective and likely outside the scope (not to mention the technical ability, since it's a static badge) of this project. For example, someone in some circumstances may care a lot about recent commit activity, whereas someone else or the same person for different purposes might only care whether issues are piling up without response or resolution.

I totally agree with you. There is probably not a good solution to this and some community effort has to be made from the maintainer. So basically with...

All that being said, the badge is only one possible indicator of the state of a repo... PRs, Issues, commit activity, etc. are all other indicators.

... everyone can just use the badge as another (dedicated) indicator to guess how fast the maintainer will respond to things.

I think you just made a good example that one can indeed trust the badge. I would probably respond to any issue on that repo which was still labeled with "active" also very fast, so it wasn't that "untrue" that it was labeled as "active".

@jantman
Copy link
Owner

jantman commented Oct 20, 2020

I'm certainly open for discussion around this, because it's a complicated issue. And while I try to respond in a timely fashion, I don't always.

@jantman jantman changed the title Update badge to indicate current repo status Discussion: Out-of-date badge status / other activity metrics? Oct 20, 2020
@llrs
Copy link

llrs commented Oct 20, 2020

For what is worth, here is one similar badge system https://www.tidyverse.org/lifecycle/ with slightly different semantics. I sometimes combine both of them for some of my code. Hope it helps

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

No branches or pull requests

3 participants