Hacker News Reader

Comment by david_allison | Hacker News Reader

Badges are toxic because they divert a subset of people away from their current open source workflow to focus on getting badges. In reality, the incentive of a lot of these badges is for GitHub's best interest and not necessarily a project's. This is insidious.

To finish my badge collection, I need:

* Merged a pull request without a review - 100% toxic.

* Answer 32 discussions - this is a strong incentive to enable GitHub Discussions on a project, which is the wrong move

* Create a repository and get 4096 stars - diverting focus from the projects I maintain (although I'm a core contributor to a project which meets this requirement, I didn't create it)

* Coauthor 38 more commits on merged pull requests - this'll happen over time. Not a 'bad' thing, but not something I want to take time to achieve.

View on HN

I'm with the grandparent poster in that I see a badge/achievement/whatever and think "neat," but I don't feel a visceral compulsion to collect the whole set.

It seems there are people who do feel that way. I wonder if the folks who set up the badge system are all of the first type, and didn't realize that some people would be thrown completely off the rails by it.

> Merged a pull request without a review - 100% toxic.

There's a case where this is not just ok, but healthy (especially on smaller teams) - if you're comfortable doing trunk-based development then you can use a PR to "snapshot" a set of changes and either invite commentary or just have a link to share as an FYI around the change, without the awkwardness of linking to an unnamed commit sequence.

https://martinfowler.com/articles/ship-show-ask.html

Yes, you can get that badge safely only if you adjust your project's development flow.

This exactly proves the central point of the article - gamification affects software developers.

I would say this is never healthy, even for a team of 2 people. These days merging code without at least asking for a review should be anathema for devs. Even a 'rubber stamping' review at least signifies a shared awareness of changes.

Other workflows exist; pretty silly to act like you’ve found the One True Way.

If you don't care about code reviews, why care about a PR process? don't protect the branch and just make your commits. The notion of a pull request is you're requesting someone pull in your changes. But you don't want them to review those changes?!

Viewed from a different lens, these achievements seem intended for new GitHub users.

I recall merging my OWN pr into my own new repo. I was surprised with a badge. No harm in that.

Just turn them off in your account settings. I did the day the badges feature went live.

I don't badge hunt. Others do, and it's worth pointing out the toxicity occasionally.

By staying quiet, we're incentivising the following:

https://stackoverflow.com/questions/72662385/how-to-merge-a-...

He could have just created a second account to farm it by himself.

1) That's against the GitHub ToS. Both accounts will be banned and the user will be permanently banned from setting up a new account.

2) Even if it was kosher, how exactly is this improving Open Source?

1. Only if they catch you.

2. What does farming weird achievement have to do with freedom?

Is there a badge for using powers of 2 in the wrong places in an attempt to look nerdy like eyeglasses with window glass lenses?

Powers of 2 are just as arbitrary as any other number.

Why is enabling Discussions "the wrong move"?

Genuinely curious, as I've gotten help from maintainers using Discussions.

(personal opinion)

Last month we had ~25 code contributors and ~2.32 million users. About 100,000 users per code contributor.

As a user-facing app, rather than 'open source infrastructure', we receive a very large number of support queries from end-users. A significant number of these will be users who are entirely non-technical, or don't speak English at all (looking at my last support efforts, ~20% were non-English + resolved via screenshots, videos + Google Translate).

I'd much rather have our community triage via one of: Forum, Discord, Reddit, StackExchange, Google Play, Mailing List, Twitter, or Facebook Messenger and leave GitHub for code/documentation-level discussions.

Opening up GitHub discussions adds another level of distraction to GitHub notifications, and provides little benefit in return given the existing established support channels.

EDIT: I do have GitHub discussions on other repos, but they're not always suitable.

Yes, this is a good summary of how I feel about discussions too. Non-technical users are going to be more comfortable using non-Github platforms anyway, and for technical users issues or chat are probably a better fit in 95% of cases. Not worth opening an entirely separate forum for.

Above needs to be more prominent.

Reply on news.ycombinator.com