The social aspect to GitHub is very much not front and center, so it seems very innocuous. How are badges toxic?
It certainly seems like a waste of their development time. I looks at these badges for a moment and think "neat" but nothing else. And profiles I just ignore, especially the ones people Myspace-ify...
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.
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.
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.
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?!
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.
It certainly seems like a waste of their development time. I looks at these badges for a moment and think "neat" but nothing else. And profiles I just ignore, especially the ones people Myspace-ify...