Gamification affects software developers: Cautionary evidence from GitHub
arxiv.org
arxiv.org
* Achievements on profiles
* Highlights on profiles
* "Activity overview" which shows an extremely flawed gauge of the work you're doing (Code review, Issues, etc)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.
Just focus on fixing your nightmare OS and maybe stop building nonsense everywhere...
GitHub’s motto VERY EARLY ON was “social coding”. They kept that motto for a long time.
https://web.archive.org/web/20080906001759/http://github.com...
https://web.archive.org/web/20080905195808/http://logicalawe...
- photos :: instagram
- videos :: tiktok, youtube
- posts :: HN, reddit, dev.to, substack, mailing lists (yes, people still use those)
- events :: messengers (telegram, whatsapp, etc), email.I.e. what Facebook used to be, before the "great social network unbundling".
> "social coding"
Social coding is not Github's primary function and it's hasn't been promoted in earnest, this way because it's secondary at best. Ostensibly, it's hosted git. That's the naming, the function, and most developers think of it as such. The vast majority of users are either corporate developers who work for some company and can't care less about the "social" aspects of it or insular developers with projects that never see the light of day.
Notably, this paper only sourced public repositories, where many people use it as an element of their work portfolio. This doesn't speak to "all of github".
hub /həb/
noun
1.
the central part of a wheel, rotating on or with the axle, and from which the spokes radiate.
Look at the article:
> We find that the unannounced removal of daily activity streak counters from the user interface (from user profile pages) was followed by significant changes in behavior.
> Long-running streaks of activity were abandoned and became less common.
> Weekend activity decreased and days in which developers made a single contribution became less common.
> Focusing on a set of software developers that were publicly pursuing a goal to make contributions for 100 days in a row, we find that some of these developers abandon this quest following the removal of the public streak counter.
Look at this bullshit. People doing work just to maintain their streaks. People making literally one contribution just to keep it up. That's fucked up and needs to be fixed. Nobody deserves this operant conditioning stuff.
The name is irrelevant. The vast majority use it for hosting. What someone wants or doesn't want has already been decided in the market.
Git is absolutely trivial to use in a fully decentralized fashion. GitHub and GitLabs success shows how much people don't want to run their own servers.
financial hubs don't _host_ financial institutions and their assets?
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/
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.
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...
I don't know what you mean by "taken away from you" or "control over likeness" or even "legal protections". Code is intangible, it can be multiple places. If you're referring to Copilot, my code can already be taken whether I use GitHub as my base of operations or not, because it is public and GitHub feels the thing is "fair use"...
You throw around big words that apply to other industries, but what specifically do you think I lose with software?
Tools are not made all equal, and there's this fallacy that just because it is a tool it is probably OK and as easy to use as abuse.
To borrow from the medical industry - yes, opiate drugs are absolutely useful _in specific cases of extreme acute pain_, but that doesn't make them good tools for dealing with a headache.
A tool can be bad, even if it can be used well, likewise a tool can be good even if it can be used for bad.
"Code is intangible, it can be multiple places" - you should study law, especially wrt existing legal precedents. If this were true, things like software patents would not be a problem, and I would evaluate how much you really can lay claim to your code, especially now Microsoft has played their hand here...
In a world where digital media and electronics remain an important part of every industry, and large rich tech companies exist, these are absolutely concerns, this is not some idle ideological patter. Your IP matters, (F)OSS has IP as well, that's part of why any of this matters.
Choose your blade wisely lest it cut you.
"SourceHut is not GitHub/GitLab/Gitea, and you would be ill-advised to treat it as such."
https://news.ycombinator.com/item?id=23038520
(And therefore, perhaps, ill-advised to recommend it as such)
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.
Email-based review tools are built-in to git. git format-patch, send-email, am, imap-send, etc.
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.
Isn't that what discussion board is for? I agree that this particular topic is not life-and-death important, but still worth discussing, IMHO. If you think otherwise, just walk away, you do not owe anybody anything.
It matters because where you assign your responsibilities is the difference between spaghetti code/architecture and a well designed one. If you think this is nitpicking, I encourage you to (re)view the general sofware concepts of cohesion and coupling.
(Part of) gits success is it is a tool focused on doing one thing well - I believe Linus is on record as saying the other tooling (commercial/svn) largely failed because they were not really focused on source control i.e. patch management. Its part of the reason he constructed it in the first place, the tool he was using was overcomplex and bad at doing simple things.
Github's success until this point has been largely that it focused on building review infrastructure. It's based on git, giving it flexibility akin to being based on e.g. http, but it's core is review and facilities in support of that e.g. code search. It's a very particular type of review aimed at a specific audience, but it's not git, nor should it be.
If anyone is skeptical about the email workflow, here's a write-up from another skeptic:
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?
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.
No, it doesn't, and it's dishonest to try to make that move—just as it is dishonest to manufacture quotes (that are, in this case, designed to provide the opportunity for that attempt).
"Github but just without the gamification elements" does not appear anywhere outside of your own comments and is, in fact, much stronger than what was claimed in the original comment you responded to; the person to whom you responded and to whom you were being needlessly confrontational pointed to SourceHut as an option for people who dislike gamification and are looking for a provider that is just "a place to host and build code". There was no claim about the suitability of SourceHut for anyone who doesn't meet that description, let alone anyone who requires/seeks/prefers(/whatever) "Github, but without gamification elements".
Please stop manufacturing quotes, and please stop defending their use by pleading that "[t]he quotation paraphrases". That word sequence alone is a dense contradiction. Making up false quotes is especially troublesome when they are freely mixed into discussions where a person has otherwise already previously made use of genuine quotes (such as the way you did when quoting the creator's remarks that "SourceHut is not GitHub/GitLab/Gitea[...]"). To do so is pernicious, and the entire practice is against HN's rules.
I still think you're reading a lot into this thread that is not there, and ratcheting this up to the level of accusations of dishonesty is a pretty interesting/illuminating choice. However, I don't actually have a dog in the fight; consider all points ceded.
> I still think you're reading a lot into this thread that is not there
To reiterate the background for this discussion: a participant in this thread went a step further than what you're saying here and literally* wrote things in that weren't really there.
* literally literally, not the other kind
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.
Part of using Github is that it's from Microsoft therefore on the 'approved' list.
Everyone should be forced to read the Linux mailing lists to see how git is meant to be used.
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...
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.
Genuinely curious, as I've gotten help from maintainers using Discussions.
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.
By staying quiet, we're incentivising the following:
https://stackoverflow.com/questions/72662385/how-to-merge-a-...
2) Even if it was kosher, how exactly is this improving Open Source?
2. What does farming weird achievement have to do with freedom?
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.
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.
This exactly proves the central point of the article - gamification affects software developers.
I recall merging my OWN pr into my own new repo. I was surprised with a badge. No harm in that.
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.
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.
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.
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.
apt-get source xxxx
put patch in debian/patches
dch --increase
dpkg-buildpackage.
Copy the patch and rebuild next time a new version comes out.
Easy on Gentoo - https://wiki.gentoo.org/wiki//etc/portage/patches
we live .io era these days (sadly)
There is/was .ai for a bit but its less generic.
--
[0] - https://www.infoq.com/news/2019/08/npm-bans-package-ads/
I'm very much not a fan of ambient authorization.
Should we limit the # of likes/stars one gets per period of time? Scarcity?
> which shows an extremely flawed gauge of the work you're doing (Code review, Issues, etc)
Reviewing code and triaging issues is real work.
What’s even worse is the notion that my employer requires me to use a social networking site for my day to day operations.
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.
Getting an achievement in recognition of the open source work that I've done feels great, and honestly it's more positive recognition then I would normally receive for that same effort.
I also appreciate the activity chart and graph, since they double as a way to monitor my productivity and therefore my energy. If I've felt that I had a bad week and the charts contradict this, then it's easier to stop myself from feeling down on myself.
I am just a social mammal, after all; and a life long gamer. This works for me, but maybe not everyone.
At the same time I'm glad it's gone as it seemed to cause more harm than good for other developers.
I guess we'll know if/when github has gone the way of FB/YT/IG is if/when people pay for fake/compensated followers to star a repo. I don't think we're there yet.
Maybe a more constructive way to have this discussion is to subdivide github's social features into those that are good vs those that are open to be abused.
github24.com for example.
I guess, also users to agreeing to mutually star/follow each other would be a bad development.
[1]: https://superuser.com/a/1402013/1109910
[2]: https://support.mozilla.org/en-US/kb/address-bar-autocomplet...
Why? I've done that and it has been amazing for me. I don't want other people telling me what's good or not. Absolute statements like this is just social malaise and not based in objectivity in the slightest.
The current social bandwagon can be summarized as: “Work is bad. Hard work is toxic. Perseverance is not healthy”.
HN is just reflecting r/antiwork ethics.
Complete and utter social non-sense. People have just stopped thinking for themselves.
Well one might start to excessively think like a computer!
For example, most humans can account for the imprecise nature of language and understand that "for anyone" doesn't necessarily mean every individual human on earth, but rather a sizeable portion of people. And "isn't good" is speaking relative to the poster's ideas rather than them claiming to have determined an absolute measure of the term "good".
-
But a computer struggles with such fuzzy constraints and falls back to the most literal interpretation of any statement.
At which point the GPT-3 model the computer is running might regurgitate some overreaction by jumping from someone essentially saying: "everything in moderation" to interpreting it as an attack on hard work and good work ethics.
(A better ending sentence from martin might've been "We don't want to incentivize 100-day streaks." But that has its own, orthogonal downsides--oh, GitHub's in the business of setting incentives? Uh oh... So all in all, I think I understand his choice of phrasing.)
I thought this is “Hacker News”. The tone here has slid significantly in last 5 years. Folks like Martin apologizing indirectly.
I think you vastly misunderstand the entire point of antiwork. Its not saying go sit on a couch all day. Its to recognize you have a life outside of work and its okay if work isn't your driving factor in life.
You can learn to persevere and push yourself many many ways. Work is not the only way. Not excelling at your job does not mean you are lethargic and resentful.
Success is measured many different ways, by many different people. You seem to measure it by how hard you work, that's great. Doesn't mean everyone has too.
> Not a single comment on HN in last few years encourage hard work and mentally exhausting yourself.
I am astounded that not pushing yourself to mental exhaustion is what you consider anti-work. If I'm not willing to abuse my own body for the good of a company I'm destined to be lethargic and smoke weed all day? What the hell kind of scale is that?
Pushing yourself to mental exhaustion, is stupid and pointless. It's been thoroughly studied, by the time you've hit mental exhaustion you are not doing anywhere near your best work. Hell I've seen it myself. I noticed my code quality and code output fell drastically the more exhausted I became. I can not stress enough how much better you are not doing that.
Looking through your own post history I see clear signs of trying to work while exhuasted.
> it takes me forever to make anything with code. Like hours to do something simple.
This was literally me until I learned to not push myself so hard. I had the exact same problem and it turns out for me at least trying to learn programming while exhausted did me no favors. I worked all day came home and tried to learn and struggled the exact same way you are. It wasn't until I was able to learn more during the day while not exhausted that it really started to click with me.
You more then anyone need to really reconsider what I posted earlier. Please for you own health.
I find too many people mistaking velocity for progress to be an almost insolvable organization problem. if you want to end up with mega lines of code that are all part of a useless of incomprehensible solution that is certainly a job, but might fail as a life's contribution.
I am no longer an eager youth, but when i was, the thing that hooked me to push on past limits, was my excitement and joy about solving real problems, at scale, with software, with a simple yet powerful idea. It was not any history of frequent commits or risong to rhe 95th %ile or the barren useless of a streak. It was having an idea born out of real needs and made simple enough to need almost no comlexity to implement. Having that novel simplicity go into production and be used was motivation for a lifetime of work.
I certainly have periods of stillness and more restful learning than prodigious output, but they are, for me at least, completely necessary. they may be fairly lethargic as well.
> The current social bandwagon can be summarized as: “Work is bad. Hard work is toxic. Perseverance is not healthy”. HN is just reflecting r/antiwork ethics. Complete and utter social non-sense. People have just stopped thinking for themselves.
This is generally not even-keeled behavior.
"Everything in moderation" dates back to 6 BC. This was clearly an reinterpretation of that basic idea. No reason to hop into a tirade into the death of hard work or something.
I work 5 days per week. I may not commit every day. Typically I will, except when I'm ill, or my close family is seriously ill, or there's a funeral, wedding, holiday, etc. So, life gets in the way, I guess.
If you're compelled to work all the time, every day, for months on end, good for you I guess. But I wouldn't skip my life to satisfy any KPI.
I will, however, persevere. I work hard. I do not give up easily. I learn something new all the time. I try to get better every day. I do my best to contribute to my family, my company, my society, and humanity at large.
However, life, I've realized, is long. My priorities have shifted over time. In the past, the value I've created in my work has not always ended up where I'd like.
If you have all this figured out 100%, then yes, go for it! Don't stop! The rest of us are still figuring it out.
Oh, also, I don't work with GitHub at all. Imagine that.
Like, you should do what works for you, but you should do it for better reasons than getting a streak counter on github.
I see the opposite. People are thinking for themselves and are looking at empirical evidence like TFA to boot.
Edit: your other comment about needing targets makes me suspect you'd benefit from using a personal task manager that can clearly and tangibly visualize progress if you aren't using one already.
I learnt early to task things out, in my head/notes.
Graphical representation seems like a crutch to me.
Specifically regarding 100 days of coding - with truly zero breaks yes this is ridiculous. Defined as design instead, it's not - I work best in periods of long productivity, but I also require time to focus on different activities, else I suffer in ways that affect my performance. If you can't write code, that's fine, maybe look at the problem a different way or build that tool which helps you succeed in your 100 day goal.
That's the opposite of poor work ethic, IMO, and that's exactly what is required (mental breaks) in order to succeed, at least in my experience.
It's fairly factual, just because you have a way you might like to work or think is best doesn't mean it's the only one. People are very different, perhaps there is some psychological profile which behaves differently than another, regardless just as there are extroverts and introverts, people don't all work best in one way.
I suspect most people can benefit from breaks, and the studies seem to back this up. Perhaps you are the special one - not the other way around.
> Complete and utter social non-sense. People have just stopped thinking for themselves.
Yes, absolute statements are a problem - including your comment. There's context around antiwork, there's context around grind culture - everything can be taken to an unhealthy extreme.
A colleague once showed me a tool to produce back dated commits in bogus git repos so you can draw pictures on your commit graph. You should know that people are gaming the gamification.
also time off is just good for you...
No more zero days, so to speak.
Starting is often the hardest part. An easy task makes it harder for you to talk yourself out of it. It also keeps the ball rolling.
I think the OP meant "code" in its purest sense - writing something for themselves, not necessarily pushing the contributions to GitHub as a part of gamification.
You don't have to do it if you're disciplined. I struggle with it and I find tiny daily habits useful.
Just add a random meaningless feature? Bump a version number just because?
Habits have context. I do gardening and I have a habit of checking my garden beds for weeds and diseases every day. I don't do it in winter when it's freezing and nothing is growing. I'll pick it up again in spring.
You don't have to game the system you've created. The habits are for you, not the other way around.
> also time off is just good for you...
Source?
I've been in the industry for a while now and I even use github, but my profile is blank, because all my work is for private companies.
I'm sad that we as an industry use such simplistic and error prone metrics. The closer I get to the hiring side of things, the sadder I get.
Oh, what am I saying, they're mid-level management. Of course a bloated paid solution involving a 3rd party vendor wins over simplicity. Otherwise they'd be out of jobs!
Its not really a great idea, in my opinion, to say "you have a hobby, so you probably dont have a job".
It seems like it can be a resume builder for some people though. I've seen resumes where people list their open-source repos and display "Over 500 stars on github" as one of the line-items.
No, most people wont without being "invited" unless it's exceptional. Good just ain't good enough by itself. People ask because it works.
I used to not be able to: I set my bar to #000000, which is the same color as the text. And unless I'm imagining things, somewhere along the way it changed to #222222
I can set the topbar to #222222, but then everything else shows up in an annoying low-contrast shadow
You can't, period. There used to be a comment-level counter years ago, but it was removed as part of an experiment to see if not having it improves overall discussion quality. Apparently the experiment concluded positively, since the counter hasn't been brought back.
this crap makes my life harder as I do this stuff from my spare time. Doing comprehensive review takes me 30min to 1h sometime more couple of hours to provide alternatives with examples etc.
I have not seen almost no rise of useful PRs that add features or fix bugs since that change in early 2022. Only rise of trivial nononse PRs.
We have a robust test and linting suite on both, so we often don't need much human engagement for reviews — code looks reasonable, tests pass, smash "Merge".
Out of interest — do you find they're not actually improving the code? Or it's just not worth the time to review it?
or typo check tests.
I do not reject these PRs. I review these and merge but I feel annoyed.
This non-sense started somewhere around start of 2022. Before that I rarely ever see PRs like that.
I'd echo the sibling comment re adding what is / isn't appreciated into a CONTRIBUTING.md. My guess is people are doing it to get their feet wet with the repo, being helpful on the margin, and would not do it if they thought it was unhelpful on the margin.
Here's PRQL's: https://github.com/prql/prql/blob/main/CONTRIBUTING.md
"By the way, I also fixed a few typos in the documentation" is much better than making that your ONLY change.
Maybe this is too extreme but I cannot remember seeing a PR too small, and I've merged thousands.
I both try and make these PRs, and appreciate others doing it! That's how things get better.
What makes things worse for everyone is little documentation cobbled together in 5min like the homework of a teen just before class.
Your genius code is useless in isolation.
Frankly, thats terrifying, now that I think about it. What a powerful tool.
We're still competing for food, attention, mates, &c. it's just that technology made it so convoluted and "unnatural" that we somehow don't even make the link anymore
Whatever. The burn out from gamification is of no consequence simply because the economy knows there are fresh bodies to take the place of the torched.
I don't want to be locked in, I also don't want to be manipulated by shiny virtual crap. Activities also is such a poor metric. On many days I have simply one commit, because it's a night of programming followed by one push to the repo... friend of mine wrote a script that makes one-line changes to a file and pushes regularly, so his activity chart looks great... (his first idea was to have it spell something out)
The trend with github seems obvious, it'll be a linkedin dev-hiring social media crap-platform people stay on for visibility and many developers eventually won't know how to use git outside of it... (and we hear the cries of "I'd like to contribute but it's not on github..." and some projects will see it as a feature of being not on github to keep those kind of people away).
So many things are going to sh*t... and people like it, which is the worst. sourcehut.org is a nice alternative (I have an account). I also wish more people would just host their own gitea instances.
Those the least significant aspect of gamification on GitHub. Stars, visits, downloads and maybe forks are what developers are interested in. And - strangely - the article seems to ignore them.
"GitHub has gamification elements in the form of badges for projects."
What, that stupid shark and cat icons? They're just embarrassing and I don't even remember what they mean. I found out I can turn them off and they were gone for good.
It's basically an attempt at hacking brains to get more work for free.
On the other hand, I generally don' tend to get addicted easily.
There is also a selfish argument to be had for why you should be against features targeting addictive behaviour even if your are immune yourself. Take games as an example, modern AAA games have been completely ruined by design chasing addicts for money.
Gamification is significantly more widespread and influential than commonly thought. We’re aware of it in our own corners of life and work, but less aware of how it’s being used on, e.g., truck drivers, gig economy workers, school students, video game players, and more.
Clearly not contributions of very high quality. Must have been Hacktoberfest-quality commits.
https://www.goodreads.com/quotes/795954-quantity-has-a-quali...
“Quantity has a quality all its own.”
― Joseph Stalin
What do you mean unexpected and unwanted? It is the stated purpose of gamification to steer the behavior of the user. And I'm sure that in Github they worked very hard to create the incentives for exactly the type of behaviors they found.
GH is a place that I can store and share my work. It isn't a social media outlet. In fact, this here venue is about the only place I engage folks, nowadays.
I just don't have the stupid cat with the starry eyes.
It is possible because git allows to create and push commit with arbitrary date, using GIT_AUTHOR_DATE env variable or --date flag.
If we can make contributing to open source projects as exciting as playing Factorio or watching TikTok, that's a huge benefit to society.
And even if we don't care about the benefits to society, it's also much better for the developers — they can be part of a community, know they're making an impact on the world, potentially get a better job through their passion.
Is there a potential downside, that people build fewer human connections, spend less time with their family, delay finding a partner — sure. But is it more of a risk than with video games or their job? I can't see how we can draw that conclusion.
So let's give contributors more status, and if that means more badges on GitHub, great.
i would have someone coding with me excited by seeking knowledge rather than trying to reach level 75 on Github…
not even mentioning what is gamification? are levels based on dark patterns on video-games, created with the intention of making players waste more time or get more addicted?
and then what is the end point of having someone full of badges and trophies on their profile? to compare oneself with others and feel bad? have benefits over others that a hierarchical system has?
append: i am not typing levels were created specifically for a dark-pattern introduction but nowadays, even if the game is not free, these practices are done to make players addicted. and i can not feel how someone really interested into get better at coding, would care
If you suck at Factorio or waste time on TikTok, it doesn't really affect anyone else other than yourself and your direct friends/family. If you're contributing to OSS to earn points based solely on participation and not quality/value, you're having a negative effect on the signal-to-noise ratio and quality of the OSS community. That is NOT a huge benefit to society. Simple participation isn't inherently beneficial if that participation is just a source of noise.
I speak as someone who has had to sift through and reject pull requests and issues from incompetent developers. I'd rather they not be encouraged to waste my time.
Adding streak counters steers behavior towards maintaining streaks. That’s unexpected?
Gamification transforms that generally open-ended benefit into KPIs of various sorts -- rather than present overall value as a contributor, you get badges for _how_ you develop.
Dark times.