14 ms·

I really don't like how GitHub has turned into a social network of sorts. The gamified elements are encouraging people to work for free and MS probably knows th

I really don't like how GitHub has turned into a social network of sorts. The gamified elements are encouraging people to work for free and MS probably knows this. GitHub should just be a place to host and build code, not to flex your follower or star count. Some examples of gamified elements I find quite toxic: * Achievements on profiles * Highlights on profiles * "Activity overview" which shows an extremely flawed gauge of the work you're doing (Code review, Issues, etc)

MisterTea 4y ago
Use https://sourcehut.org/ https://sourcehut.org/ then. It is against such gamification elements and Drew has been quite vocal abut this issue.
- kixiQu 4y ago
  If you are also down with requiring that your would-be contributors conform to his preference for email patches. https://man.sr.ht/git.sr.ht/send-email.md https://man.sr.ht/git.sr.ht/send-email.md "SourceHut is not GitHub/GitLab/Gitea, and you would be ill-advised to treat it as such." https://news.ycombinator.com/item?id=23038520 https://news.ycombinator.com/item?id=23038520 (And therefore, perhaps, ill-advised to recommend it as such)
  - lupire 4y ago
    Does Drew prefer email, or prefer not doing more work than he already does?
    - smaudet 4y ago
      Hmm - review is not a part of git, in fact it is antithetical to git (concept from cvs/svn with centralized systems). A pull request, literally, need only be moving code from one repo to another. The signaling mechanism etc. are not and shouldn't be specified by git. How code moves around should be dictated by your organism, copyright, access levels, not some guy's interpretation of what "pull request" means. That means, yes in some instances there is no 'master' version of the software, there are multiple flavors with different release characteristics. E-mail I suppose is an adequate communication medium, if people want a specific review mechanism and triggers adding one to source hut (assuming FOSS) shouldn't be hard, perhaps the authors intention is to make it difficult to regress to a centralized model.
      - ddevault 4y ago
        >Hmm - review is not a part of git Email-based review tools are built-in to git. git format-patch, send-email, am, imap-send, etc.
        pferde 4y ago
        Those are tools to facilitate moving the code from one repo to another, not to facilitate a review of that code. So I think the GP's point stands.
        ddevault 4y ago
        I mean, it facilitates code review as well. You just reply to the email. This is how Linux is developed, for instance.
        pferde 4y ago
        Yes, but you do not reply via git. You review the patches in the MUA of your choice (outside of git) or in editor or IDE of your choice, after applying them in your local repository clone (applied maybe by git, maybe by the "patch" command, but viewed and evaluated completely without git), then you compose a reply in your MUA or maybe have a direct chat with someone about it (again, outside of git). Git only comes in play when the review is finished, and it's time to commit the changes to your repository. So I claim that git does not have tools for reviewing pull requests or patch sets, only for managing them on either end of the pipeline - creating them, sending them, and applying them. Which, to be clear, is not a criticism of git, as I do not think git should grow such review tools.
        ddevault 4y ago
        Alright, sure, but you're picking nits and I'm not sure what your underlying point is.
        4y ago
  - ddevault 4y ago
    SourceHut author here. Not sure what you're trying to say. The opposite is also true: using GitHub requires that your would-be contributors conform to the pull request workflow instead -- and many people prefer emails. If anyone is skeptical about the email workflow, here's a write-up from another skeptic: https://blog.brixit.nl/git-email-flow-versus-github-flow/ https://blog.brixit.nl/git-email-flow-versus-github-flow/
    - kixiQu 4y ago
      What I am saying is that, both in what I've seen and what you've stated, SourceHut is emphatically not trying to be "Github but just without the gamification elements", so if that's what people are looking for, they probably want to look elsewhere.
      - cxr 4y ago
        > "Github but just without the gamification elements" Where did this quote come from? You just made it up? You're obviously trying to offer a retort/rebuff of some argument. But whose? Which argument?
        kixiQu 4y ago
        No, I am not trying to retort/rebuff, and this thread seems unexpectedly confrontational. The quotation paraphrases the context of the exchange, which I will again summarize in case it is not adequately clear in itself: There was a commenter that said that they don't like how GH has introduced gamification elements, id 33310374. Then there was a commenter that said that the first commenter should therefore use SourceHut, because it stands in opposition to gamification, id 33311082. This exchange positions SourceHut as "Github, but without gamification elements", which I am putting in quotes to indicate it is a single coherent concept. I am pointing out that SourceHut is not designed to be a Github-like, as with its opinionated design choices around PRs, and I quote Drew being pretty explicit about that.
        cxr 4y ago
  - notpushkin 4y ago
    SourceHut is very modular though. Could we make a separate app that implements pull requests? :thinking:
  - MisterTea 4y ago
    > conform to his preference for email patches How is a time tested method of sending patches conforming? If you don't like the method or cant be arsed to learn it then find something else or roll your own.
    - kixiQu 4y ago
      Right – something else like Github, the component under discussion, which is dissimilar to SourceHut in more ways than the gamification elements under discussion.
- bluedino 4y ago
  If I start pestering them now, the security team at my LARGE_CORP employer might allow me access to sorucehut.org in about 3-4 months. Part of using Github is that it's from Microsoft therefore on the 'approved' list.
walrus01 4y ago
If you don't like how GitHub has become a social network of sorts, you really won't like how LinkedIn is apparently the new Facebook. I have even seen a number of creepy screenshots from horny single men on LinkedIn sending unsolicited messages to women they think are attractive, trying to use it as a dating website. GitHub and linkedin are both owned by MS and trying really hard to be social networks, so the follow on social consequences of mass adoption seem almost inevitable.
- theteapot 4y ago
  Wow that's a tangent.
  - smaudet 4y ago
    Seems on point to me, another example of how everything Microsoft touches turns sour... Just focus on fixing your nightmare OS and maybe stop building nonsense everywhere...
abledon 4y ago
my first "wtf" was seeing the "pull shark" badge... really? I do like that they give you the option to disable showing your achievements in the settings.
- Gigachad 4y ago
  The badges are just not that compelling. Feels like an "everyone gets an award" thing. You shouldn't get an award for making a PR.. Show an award when your repo reaches 10,000 stars or something.
scrollaway 4y ago
… turned into? GitHub’s motto VERY EARLY ON was “social coding”. They kept that motto for a long time.
- jiayo 4y ago
  Yes, one of the earliest archive.org snapshots from 14 years ago shows this: https://web.archive.org/web/20080906001759/http://github.com/ https://web.archive.org/web/20080906001759/http://github.com...
  - fxtentacle 4y ago
    Love that self-presentation from 2008: https://web.archive.org/web/20080905195808/http://logicalawesome.com/ https://web.archive.org/web/20080905195808/http://logicalawe...
- c7DJTLrn 4y ago
  Yes. And it did that perfectly well five years ago before they bolted on all this bloat nonsense.
- qbasic_forever 4y ago
  Yep, many people forget GitHub was trying to be Facebook but for coders from the very start. Back in late 2000s when FB was the hottest startup everyone was trying to do "the Facebook of X" knockoffs.
  - MonkeyMalarky 4y ago
    Now we need a Facebook for sharing photos, videos, events and posts with our friends and adjacent social circles.
    - genewitch 4y ago
      Fediverse on a curated homeserver is getting there. Or having importable killfiles
    - 4y ago
armchairhacker 4y ago
IMO this is the main thing GitHub has over GitLab. Most platforms which support GitHub also support GitLab, GitLab has equivalents for many of GitHub's features like actions, and GitLab even has comparable free tier storage (as they've decided not to delete inactive free projects [1]) If someone just wants to host and build code there are many alternatives (like Sourcehut). The only reason GitHub is so dominant is because of its already huge following and exploration / networking which relies on said following. [1] https://news.itsfoss.com/gitlab-inactive-projects-policy/ https://news.itsfoss.com/gitlab-inactive-projects-policy/
- lupire 4y ago
  GitLab is most known, most trusted, most featureful, most funded. It may be politically suspect, but that's not a priority for most people.
  - bmitc 4y ago
    Did you mean GitHub?
- remram 4y ago
  There have been a lot of red flags with GitLab recently. This (aborted) plan to delete projects was one of them, but the recent limits on CI they impose on open-source projects get in the way quickly compared to GitHub: 2,000 minutes per month. Personally I am planning to move to GitHub soon. The CI limit is very small for an active project testing across a few different Python versions, I am reaching it just with a couple pushes per day.
  - smaudet 4y ago
    Consider sinking capital or asking for donations for your own CI then - sure you might get something for "free", but if you aren't paying anything then you might just be the product. Serious downsides to being the product include: * No means of production - whatever profit you hoped to have can simply be taken away from you. * No control over your likeness, IP * Limited legal protections * Finding yourself being sold in ways you find unethical. I'd reconsider your planned move, unless I guess you really just don't care about your project longevity...
Palomides 4y ago
you can turn them all off, at least for your own profile
thrown_22 4y ago
It was but people want more. Everyone should be forced to read the Linux mailing lists to see how git is meant to be used.
hoten 4y ago
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...
- david_allison 4y ago
  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.
  - urthor 4y ago
    Above needs to be more prominent.
  - derekbaker783 4y ago
    Why is enabling Discussions "the wrong move"? Genuinely curious, as I've gotten help from maintainers using Discussions.
    - david_allison 4y ago
      (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.
nimbius 4y ago
if i may be so bold, this is an encroaching effort from multiple large players, FAANG included. its a pretty ham-fisted, transparent attempt to get the kids excited about code in much the same way your spanish teacher tried to pump the kids up to learn with a fiesta. The idea is to increase the number of programmers, decrease the median pay rate of the average programmer, and recapture the excess capital lost from the past 60 years of nerd-shaming that led us to consume more code and tech than we produce. the only people whining about code not being fun and pushing gamification are the very people who shouldnt be doing it.
- noobermin 4y ago
  What does "consume more code and tech than we produce" mean?
  - lupire 4y ago
    Parent thinks there is a fix amount of code needed in the world, and the only reason (some) programmers earn a lot of money is that a relatively small number of people produce that code. They ignore that the cast majority of code generates demand for more code.
    - MikePlacid 4y ago
      Exactly! A successful software project creates a building block. A basic human desire is a) to modify the successful design to perform some other task, and/or 2) to use an existing building block to build something bigger and more complex.
    - ls612 4y ago
      The “Lump of Code” fallacy
r3trohack3r 4y ago
This is the social commentary where OSS and freedom respecting software intersect. It was called upfront when the split happened. Don't build FOSS for others. Build it for yourself and package it for others. Expect contributions. It's okay to expect your users to contribute. It's okay to push back and expect them to contribute. It's okay to say no to PRS because you don't have time to review them. It's okay to not have the time to say you don't have the time. Personally, package management solutions fall short of the FOSS goal for me. Hard to start with a package and float my own changes. Hard to fork and maintain my own version. The whole push for staying on mainline and pushing that burden of the original author is a symptom IMO.
- mikepurvis 4y ago
  Maybe this is a hijack, but IMO current packaging tools/workflows are a big part of the problem here. Forking a Python package to give it a new name is a giant pain, and if you don't rename it and only release it to a private pypi, you're inviting angst and confusion from your internal users. The only alternative is to put your git url and branch directly in a requirements.txt file, which is not remotely scalable. These kinds of issues exist across npm, homebrew, apt, etc as far as I'm aware. In contrast, Nix overrides allow patching in fixes at varying degrees of locality, making it trivially easy to maintain a long term fork or just apply unmerged fixes in the short term.
  - geerlingguy 4y ago
    Composer also has a fairly robust patches plugin, I hate other ecosystems that basically require a full fork.
    - mikepurvis 4y ago
      I feel like a fundamental issue is around human-assigned package names and linearly incrementing version numbers. Anyone who graduated from SVN to git understands about using hashes for true object identification, but it seems it's not nearly as widespread in the packaging world, other than for caches and lock files that most users never interact with directly, and rarely-if-ever for enabling nonlinear package evolutions. Anyway, I haven't used PHP in fifteen years, but it's great to know that it at least attempts to address this in a better way. Certainly project/dependency-level package managers should have a major advantage over distro package managers in terms of being able to address this kind of thing, but it seems that many of them still ended up with distro-packaging conventions and concepts baked deep into the design.
spacechild1 4y ago
Personally, I haven't even noticed any of these...
- saurik 4y ago
  FWIW I don't notice it in my usage of GitHub... but yet I've still noticed it because projects I've been involved in which happen to use GitHub end up with people showing up who clearly just want the badges or who explicitly admit they are wasting my time trying to get a "contributor" status on the project so their icon shows up somewhere and while at the end of the day the problem can of course be blamed on these people who fall for this stuff, GitHub knows what they are doing as these features have no legitimate use case other than to gamify their platform.
gumby 4y ago
I saw it today in someone who announced a package and in their README had a gif of a mouse clicking to add a "star" to the repo. Like the youtube videos that ask you to "like and subscribe".
- ronsor 4y ago
  "Star and watch for more great software"
  - trinovantes 4y ago
    I'm glad we don't see this in npm post-install hooks... yet
    - xigoi 4y ago
      Don't give them ideas.
      - DemocracyFTW2 4y ago
        Let me take this opportunity to thank today's sponsor, Whatever dot org. Yadda yadda yadda.
        endre 4y ago
        .org is for the 90s. we live .io era these days (sadly)
        account42 4y ago
        .io is already so yesteryear. There is/was .ai for a bit but its less generic.
        gumby 4y ago
        I promise to leave more high-value comments if you can get me a deal with Whatever.
LtWorf 4y ago
I've always seen the activity overview as a way to see if the account is abandoned and nothing else.
hermanradtke 4y ago
I don’t disagree that GitHub should tone down the gamification. However, I do disagree with this: > which shows an extremely flawed gauge of the work you're doing (Code review, Issues, etc) Reviewing code and triaging issues is real work.
- lupire 4y ago
  Isn't designing and programming also real work?
qudat 4y ago
Star count has some interesting side effects. On one hand, it incentivizes people to produce something popular — and by proxy something useful. On the other hand it can be cause addictive behaviors. What’s even worse is the notion that my employer requires me to use a social networking site for my day to day operations. https://bower.sh/github-as-social-network https://bower.sh/github-as-social-network
- deleted 4y ago
  [deleted]
- bombolo 4y ago
  Popular and good are only loosely related.
- rikroots 4y ago
  Star counts on a repo are both essential for devs who need to assess a range of libraries/products for possible use in their own product (as indirect indicators of support, community, etc), and yet also toxic for anyone trying to build a new library/product in an established niche (everyone ignores repos with low star counts). Clearly if I was serious about marketing/promoting my library then asking people to star the repo would be high on the list of asks. Sadly I am not that person.
  - scajanus 4y ago
    On the other hand, having starring a repo made into a game will skew the stars' usability in gauging a project's popularity or quality. Maybe the "most starred repo for X" is just made by someone who's really into collecting badges or marketing.
oxff 4y ago
I think it is fine. If you lack consciousness to notice when you are, as you suggest, tricked to working for free, you have much worse issues. I started my programming due to a social network need in the first place.
- cjsawyer 4y ago
  Don’t blame the users for wanting to change a predatory system. They’ve already identified the problem — telling them to simply ignore it is dismissing their humanity. We’re not machines and need to work inside those constraints

MisterTea 4y ago

Use https://sourcehut.org/ https://sourcehut.org/ then. It is against such gamification elements and Drew has been quite vocal abut this issue.

kixiQu 4y ago
If you are also down with requiring that your would-be contributors conform to his preference for email patches. https://man.sr.ht/git.sr.ht/send-email.md https://man.sr.ht/git.sr.ht/send-email.md "SourceHut is not GitHub/GitLab/Gitea, and you would be ill-advised to treat it as such." https://news.ycombinator.com/item?id=23038520 https://news.ycombinator.com/item?id=23038520 (And therefore, perhaps, ill-advised to recommend it as such)
- lupire 4y ago
  Does Drew prefer email, or prefer not doing more work than he already does?
  - smaudet 4y ago
    Hmm - review is not a part of git, in fact it is antithetical to git (concept from cvs/svn with centralized systems). A pull request, literally, need only be moving code from one repo to another. The signaling mechanism etc. are not and shouldn't be specified by git. How code moves around should be dictated by your organism, copyright, access levels, not some guy's interpretation of what "pull request" means. That means, yes in some instances there is no 'master' version of the software, there are multiple flavors with different release characteristics. E-mail I suppose is an adequate communication medium, if people want a specific review mechanism and triggers adding one to source hut (assuming FOSS) shouldn't be hard, perhaps the authors intention is to make it difficult to regress to a centralized model.
    - ddevault 4y ago
      >Hmm - review is not a part of git Email-based review tools are built-in to git. git format-patch, send-email, am, imap-send, etc.
      - pferde 4y ago
        Those are tools to facilitate moving the code from one repo to another, not to facilitate a review of that code. So I think the GP's point stands.
        ddevault 4y ago
        I mean, it facilitates code review as well. You just reply to the email. This is how Linux is developed, for instance.
        pferde 4y ago
        Yes, but you do not reply via git. You review the patches in the MUA of your choice (outside of git) or in editor or IDE of your choice, after applying them in your local repository clone (applied maybe by git, maybe by the "patch" command, but viewed and evaluated completely without git), then you compose a reply in your MUA or maybe have a direct chat with someone about it (again, outside of git). Git only comes in play when the review is finished, and it's time to commit the changes to your repository. So I claim that git does not have tools for reviewing pull requests or patch sets, only for managing them on either end of the pipeline - creating them, sending them, and applying them. Which, to be clear, is not a criticism of git, as I do not think git should grow such review tools.
        ddevault 4y ago
        Alright, sure, but you're picking nits and I'm not sure what your underlying point is.
        4y ago
- ddevault 4y ago
  SourceHut author here. Not sure what you're trying to say. The opposite is also true: using GitHub requires that your would-be contributors conform to the pull request workflow instead -- and many people prefer emails. If anyone is skeptical about the email workflow, here's a write-up from another skeptic: https://blog.brixit.nl/git-email-flow-versus-github-flow/ https://blog.brixit.nl/git-email-flow-versus-github-flow/
  - kixiQu 4y ago
    What I am saying is that, both in what I've seen and what you've stated, SourceHut is emphatically not trying to be "Github but just without the gamification elements", so if that's what people are looking for, they probably want to look elsewhere.
    - cxr 4y ago
      > "Github but just without the gamification elements" Where did this quote come from? You just made it up? You're obviously trying to offer a retort/rebuff of some argument. But whose? Which argument?
      - kixiQu 4y ago
        No, I am not trying to retort/rebuff, and this thread seems unexpectedly confrontational. The quotation paraphrases the context of the exchange, which I will again summarize in case it is not adequately clear in itself: There was a commenter that said that they don't like how GH has introduced gamification elements, id 33310374. Then there was a commenter that said that the first commenter should therefore use SourceHut, because it stands in opposition to gamification, id 33311082. This exchange positions SourceHut as "Github, but without gamification elements", which I am putting in quotes to indicate it is a single coherent concept. I am pointing out that SourceHut is not designed to be a Github-like, as with its opinionated design choices around PRs, and I quote Drew being pretty explicit about that.
        cxr 4y ago
- notpushkin 4y ago
  SourceHut is very modular though. Could we make a separate app that implements pull requests? :thinking:
- MisterTea 4y ago
  > conform to his preference for email patches How is a time tested method of sending patches conforming? If you don't like the method or cant be arsed to learn it then find something else or roll your own.
  - kixiQu 4y ago
    Right – something else like Github, the component under discussion, which is dissimilar to SourceHut in more ways than the gamification elements under discussion.
bluedino 4y ago
If I start pestering them now, the security team at my LARGE_CORP employer might allow me access to sorucehut.org in about 3-4 months. Part of using Github is that it's from Microsoft therefore on the 'approved' list.

walrus01 4y ago

If you don't like how GitHub has become a social network of sorts, you really won't like how LinkedIn is apparently the new Facebook. I have even seen a number of creepy screenshots from horny single men on LinkedIn sending unsolicited messages to women they think are attractive, trying to use it as a dating website. GitHub and linkedin are both owned by MS and trying really hard to be social networks, so the follow on social consequences of mass adoption seem almost inevitable.

theteapot 4y ago
Wow that's a tangent.
- smaudet 4y ago
  Seems on point to me, another example of how everything Microsoft touches turns sour... Just focus on fixing your nightmare OS and maybe stop building nonsense everywhere...

abledon 4y ago

my first "wtf" was seeing the "pull shark" badge... really? I do like that they give you the option to disable showing your achievements in the settings.

Gigachad 4y ago
The badges are just not that compelling. Feels like an "everyone gets an award" thing. You shouldn't get an award for making a PR.. Show an award when your repo reaches 10,000 stars or something.

scrollaway 4y ago

… turned into? GitHub’s motto VERY EARLY ON was “social coding”. They kept that motto for a long time.

jiayo 4y ago
Yes, one of the earliest archive.org snapshots from 14 years ago shows this: https://web.archive.org/web/20080906001759/http://github.com/ https://web.archive.org/web/20080906001759/http://github.com...
- fxtentacle 4y ago
  Love that self-presentation from 2008: https://web.archive.org/web/20080905195808/http://logicalawesome.com/ https://web.archive.org/web/20080905195808/http://logicalawe...
c7DJTLrn 4y ago
Yes. And it did that perfectly well five years ago before they bolted on all this bloat nonsense.
qbasic_forever 4y ago
Yep, many people forget GitHub was trying to be Facebook but for coders from the very start. Back in late 2000s when FB was the hottest startup everyone was trying to do "the Facebook of X" knockoffs.
- MonkeyMalarky 4y ago
  Now we need a Facebook for sharing photos, videos, events and posts with our friends and adjacent social circles.
  - genewitch 4y ago
    Fediverse on a curated homeserver is getting there. Or having importable killfiles
  - 4y ago

armchairhacker 4y ago

IMO this is the main thing GitHub has over GitLab. Most platforms which support GitHub also support GitLab, GitLab has equivalents for many of GitHub's features like actions, and GitLab even has comparable free tier storage (as they've decided not to delete inactive free projects [1]) If someone just wants to host and build code there are many alternatives (like Sourcehut). The only reason GitHub is so dominant is because of its already huge following and exploration / networking which relies on said following. [1] https://news.itsfoss.com/gitlab-inactive-projects-policy/ https://news.itsfoss.com/gitlab-inactive-projects-policy/

lupire 4y ago
GitLab is most known, most trusted, most featureful, most funded. It may be politically suspect, but that's not a priority for most people.
- bmitc 4y ago
  Did you mean GitHub?
remram 4y ago
There have been a lot of red flags with GitLab recently. This (aborted) plan to delete projects was one of them, but the recent limits on CI they impose on open-source projects get in the way quickly compared to GitHub: 2,000 minutes per month. Personally I am planning to move to GitHub soon. The CI limit is very small for an active project testing across a few different Python versions, I am reaching it just with a couple pushes per day.
- smaudet 4y ago
  Consider sinking capital or asking for donations for your own CI then - sure you might get something for "free", but if you aren't paying anything then you might just be the product. Serious downsides to being the product include: * No means of production - whatever profit you hoped to have can simply be taken away from you. * No control over your likeness, IP * Limited legal protections * Finding yourself being sold in ways you find unethical. I'd reconsider your planned move, unless I guess you really just don't care about your project longevity...

Palomides 4y ago

you can turn them all off, at least for your own profile

thrown_22 4y ago

It was but people want more. Everyone should be forced to read the Linux mailing lists to see how git is meant to be used.

hoten 4y ago

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...

david_allison 4y ago
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.
- urthor 4y ago
  Above needs to be more prominent.
- derekbaker783 4y ago
  Why is enabling Discussions "the wrong move"? Genuinely curious, as I've gotten help from maintainers using Discussions.
  - david_allison 4y ago
    (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.

nimbius 4y ago

if i may be so bold, this is an encroaching effort from multiple large players, FAANG included. its a pretty ham-fisted, transparent attempt to get the kids excited about code in much the same way your spanish teacher tried to pump the kids up to learn with a fiesta. The idea is to increase the number of programmers, decrease the median pay rate of the average programmer, and recapture the excess capital lost from the past 60 years of nerd-shaming that led us to consume more code and tech than we produce. the only people whining about code not being fun and pushing gamification are the very people who shouldnt be doing it.

noobermin 4y ago
What does "consume more code and tech than we produce" mean?
- lupire 4y ago
  Parent thinks there is a fix amount of code needed in the world, and the only reason (some) programmers earn a lot of money is that a relatively small number of people produce that code. They ignore that the cast majority of code generates demand for more code.
  - MikePlacid 4y ago
    Exactly! A successful software project creates a building block. A basic human desire is a) to modify the successful design to perform some other task, and/or 2) to use an existing building block to build something bigger and more complex.
  - ls612 4y ago
    The “Lump of Code” fallacy

r3trohack3r 4y ago

This is the social commentary where OSS and freedom respecting software intersect. It was called upfront when the split happened. Don't build FOSS for others. Build it for yourself and package it for others. Expect contributions. It's okay to expect your users to contribute. It's okay to push back and expect them to contribute. It's okay to say no to PRS because you don't have time to review them. It's okay to not have the time to say you don't have the time. Personally, package management solutions fall short of the FOSS goal for me. Hard to start with a package and float my own changes. Hard to fork and maintain my own version. The whole push for staying on mainline and pushing that burden of the original author is a symptom IMO.

mikepurvis 4y ago
Maybe this is a hijack, but IMO current packaging tools/workflows are a big part of the problem here. Forking a Python package to give it a new name is a giant pain, and if you don't rename it and only release it to a private pypi, you're inviting angst and confusion from your internal users. The only alternative is to put your git url and branch directly in a requirements.txt file, which is not remotely scalable. These kinds of issues exist across npm, homebrew, apt, etc as far as I'm aware. In contrast, Nix overrides allow patching in fixes at varying degrees of locality, making it trivially easy to maintain a long term fork or just apply unmerged fixes in the short term.
- geerlingguy 4y ago
  Composer also has a fairly robust patches plugin, I hate other ecosystems that basically require a full fork.
  - mikepurvis 4y ago
    I feel like a fundamental issue is around human-assigned package names and linearly incrementing version numbers. Anyone who graduated from SVN to git understands about using hashes for true object identification, but it seems it's not nearly as widespread in the packaging world, other than for caches and lock files that most users never interact with directly, and rarely-if-ever for enabling nonlinear package evolutions. Anyway, I haven't used PHP in fifteen years, but it's great to know that it at least attempts to address this in a better way. Certainly project/dependency-level package managers should have a major advantage over distro package managers in terms of being able to address this kind of thing, but it seems that many of them still ended up with distro-packaging conventions and concepts baked deep into the design.

spacechild1 4y ago

Personally, I haven't even noticed any of these...

saurik 4y ago
FWIW I don't notice it in my usage of GitHub... but yet I've still noticed it because projects I've been involved in which happen to use GitHub end up with people showing up who clearly just want the badges or who explicitly admit they are wasting my time trying to get a "contributor" status on the project so their icon shows up somewhere and while at the end of the day the problem can of course be blamed on these people who fall for this stuff, GitHub knows what they are doing as these features have no legitimate use case other than to gamify their platform.

gumby 4y ago

I saw it today in someone who announced a package and in their README had a gif of a mouse clicking to add a "star" to the repo. Like the youtube videos that ask you to "like and subscribe".

ronsor 4y ago
"Star and watch for more great software"
- trinovantes 4y ago
  I'm glad we don't see this in npm post-install hooks... yet
  - xigoi 4y ago
    Don't give them ideas.
    - DemocracyFTW2 4y ago
      Let me take this opportunity to thank today's sponsor, Whatever dot org. Yadda yadda yadda.
      - endre 4y ago
        .org is for the 90s. we live .io era these days (sadly)
        account42 4y ago
        .io is already so yesteryear. There is/was .ai for a bit but its less generic.
      - gumby 4y ago
        I promise to leave more high-value comments if you can get me a deal with Whatever.

LtWorf 4y ago

I've always seen the activity overview as a way to see if the account is abandoned and nothing else.

hermanradtke 4y ago

I don’t disagree that GitHub should tone down the gamification. However, I do disagree with this: > which shows an extremely flawed gauge of the work you're doing (Code review, Issues, etc) Reviewing code and triaging issues is real work.

lupire 4y ago
Isn't designing and programming also real work?

qudat 4y ago

Star count has some interesting side effects. On one hand, it incentivizes people to produce something popular — and by proxy something useful. On the other hand it can be cause addictive behaviors. What’s even worse is the notion that my employer requires me to use a social networking site for my day to day operations. https://bower.sh/github-as-social-network https://bower.sh/github-as-social-network

deleted 4y ago
[deleted]
bombolo 4y ago
Popular and good are only loosely related.
rikroots 4y ago
Star counts on a repo are both essential for devs who need to assess a range of libraries/products for possible use in their own product (as indirect indicators of support, community, etc), and yet also toxic for anyone trying to build a new library/product in an established niche (everyone ignores repos with low star counts). Clearly if I was serious about marketing/promoting my library then asking people to star the repo would be high on the list of asks. Sadly I am not that person.
- scajanus 4y ago
  On the other hand, having starring a repo made into a game will skew the stars' usability in gauging a project's popularity or quality. Maybe the "most starred repo for X" is just made by someone who's really into collecting badges or marketing.

oxff 4y ago

I think it is fine. If you lack consciousness to notice when you are, as you suggest, tricked to working for free, you have much worse issues. I started my programming due to a social network need in the first place.

cjsawyer 4y ago
Don’t blame the users for wanting to change a predatory system. They’ve already identified the problem — telling them to simply ignore it is dismissing their humanity. We’re not machines and need to work inside those constraints