GitHub Survivor: a bug leaderboard for GitHub issues

http://99designs.com/tech-blog/blog/2013/01/05/github-survivor/

by harto • 14 years ago

67 17 14 years ago

I love this idea! Makes me wish we could implement something like this where I work. But I always remember that we're a business first, and software development office second. :(

Edit: Meaning, we don't sell software, but we need software to run our day to day.

dlutzy• 14 years ago

1. git clone https://github.com/99designs/githubsurvivor.git 2. profit

:-)

jjbohn• 14 years ago

This is really cool. Definitely want to implement someone like this with my teams.

kurrent• 14 years ago

How do you address that somebody could take on 5 bugs that take 5 minutes to fix versus the guy who takes the 1 bug that takes 5 hours to fix?

harto4• 14 years ago

Good question! We currently track that externally. E.g. in the issue description we might say "This is worth 100 whisky-points". It would be cool to build in a notion of value.

lucian303• 14 years ago

I can't think of a more worthless and demoralizing idea. Not all bugs are created equal, thus the measure is inaccurate.

richo• 14 years ago

Noones treating this as a definitive source of truth. It's a fun way to gamify our bug squashing efforts.

decklin• 14 years ago

Before reading the article, I hoped this was going to have something to do with the oldest issues (open, fixed recently, commented, etc) across all of GitHub. Does such a thing exist?

carbocation• 14 years ago

When designing systems that reward bugfixes, beware the Cobra effect. [1]

[1] = http://en.wikipedia.org/wiki/Cobra_effect

harto4• 14 years ago

On the other hand, it's an incentive for devs to log and fix minor issues they might've otherwise ignored.

watt• 14 years ago

If you start measuring some metric, the team will adapt at improving that metric, but inevitably this will spill out into distorting or lowering performance in some other aspect. So as you point out, such survivor board might make team focus on fixing trivial/easy issues, but the issues requiring big time investment might go unfixed (as it would make 10 trivial issues pile up while you fix 1 old hard ticket - which will make you look bad).

Just make sure this is what you want.

lvh3• 14 years ago

Are you suggesting developers would start adding bugs for the purpose of killing them off later?

FYI, we've had this system[1] at Twisted[2] for a long time, and that hasn't really happened. When it was first introduced, I argued that it might lead people to review too much; then Glyph counterargued that that's a feature, not a bug. History's proven him right.

It could be that because it's an open source project, and most development on it is by volunteers, that that mechanic is less strong: it's not like people collect bonuses or anything because of their scores... Nor would I suggest that in any other context :)

[1] https://twistedmatrix.com/highscores/ [2]: https://twistedmatrix.com/trac/

lvh3• 14 years ago

Twisted created one of these a good long while ago[1], and then someone adapted it for Github[2]. This one looks very fancy though :)

[1] https://twistedmatrix.com/highscores/ [2]: https://github.com/leereilly/github-high-scores/, also https://github.com/kans/highscores

harto4• 14 years ago

Wow, very similar style. I don't think we were aware of those!

lox• 14 years ago

How embarrassing, I guess I'd better close some bugs.

GitHub Survivor: a bug leaderboard for GitHub issues

Related Stories