Clarification: none of these were achievements rejected by GitHub, simply humorous ideas from a developer known as "flet" with no affiliation to GitHub.
Not very obvious considering some of the comments in this thread.
Some people are reading the title of the post as if GitHub had received proposals from their employees to include some of these achivements into the final feature set, and then decided to reject them, but the reality is that none of them were proposed by any GitHub employee at all. They are all “joke submissions” from the development community, making fun of the gamification of the platform.
Congrats on earning the "Adding Value" achievement:
Pointing out something obvious, then having someone else point out that what you pointed out is obvious, then defending the obvious thing that you pointed out by stating that it in fact is not obvious
I agree with you and don't necessarily think this is "bad," but GitHub probably isn't the best place to just dump a ton of feature requests. And if that's the only easy way to contact the author, there's always a decent chance that's a deliberate choice.
Nah that one should go to the user who proposes massive and sweeping architectural changes, complete with diagrams and over engineering in every facet-regardless of whether the project needs it, but never makes any attempt to do it.
When working alone remotely from home, I simulate pair programming with a methodology I call "The Stranger". I sit on one of my hands until it becomes numb and tingly, and then it feels like somebody else is typing and moving the mouse!
"The Novelist": Opens an issue or replies to a thread with only the words "doesn't work" with no indication of what they tried, how they know it doesn't work, or any error messages.
"Captain Obvious": Opens a very aggressive and angry issue about the project not installing, when the maintainer responds to double-check that you didn't miss a critical and well-documented note in the docs, you disappear, never to reply again.
There's a legitimate reason for posting low information issues - finding out if it's a known limitation or issue (that didn't come up in a search) before putting in extra effort to document something that's already been documented and discussed elsewhere. Maybe not "doesn't work" (two words) exactly, but "This doesn't work for me with the X234 hardware" (... with an implied "is this expected?").
It's very common for people new to projects or with limited technical skills to assume that the problems they face are common/well known or that other people know much more than them.
The frustration responders face is due to the mismatch of assumptions, if the issue is in fact not common or well known, but IMO a simple "I haven't seen that before, please post full diagnostics" is an easy and reasonable boilerplate response.
> "This doesn't work for me with the X234 hardware"
The problem with that phrase is that you didn't state what is not working. I don't expect - although highly welcome - a complete diagnostics from the reporter, but please at least write the steps to reproduce your issue.
> "The Novelist": Opens an issue or replies to a thread with only the words "doesn't work" with no indication of what they tried, how they know it doesn't work, or any error messages.
> a screenshot of a terminal instead of copy and pasting the text
No. Please, no!
For some reason, I get screenshots of text regularly from technical people. Log files, error messages, everything. It is like they forget Slack can send anything more than images and emojis.
No, I'm not typing out keywords from 3 pages of Java exception, nor am I typing an encoded AWS authorization message.
I've tried using it for this exact thing, and it doesn't work that well with terminal screenshots. You have to carefully read the output and fix it manually, but at least it's better than typing it all out by hand.
> "The Filmmaker": posted an animated GIF of their terminal session instead of writing out what they did
I love videos and GIFs when trying to debug something. They're usually much better at catching small details than people's descriptions. Very often, the bug will hinge on an action that you can do in multiple ways, or some action that the user took directly before triggering the bug that they don't realise is necessarily part of the problem. Or maybe the bug only triggers on certain screen sizes or something, or if certain terminal colours are used, or if the user is using a touchscreen or something.
Having a video makes it a lot easier to notice these sorts of things. It's not always perfect, and a detailed description alongside the video is best, especially if you also have any errors or important text copied there so I can copy it myself, but given the choice, I often prefer video over text.
So yes, I genuinely love filmmakers in this context. Send me screenshots, send me videos!
mpv will also play gifs and allow you to pause them. It also knows how to stream web resources.
I have a keyboard shortcut bound to run mpv with the content of the clipboard, so right click on gif, "Copy Image Link", hit the keyboard shortcut and wait for the gif to open in mpv where I can pause, speed up, speed down, scroll etc.
Also useful for any video or audio on the web, since mpv is (for me) much nicer than any built-in player.
"The problem solver": asks how to solve a specific error while also posting the stacktrace/error which already contains a message about how to solve the error
I love this one. We’ve all missed something plain as day at some point. I pride myself on RTFM before I start working with something, but I’ve earned this medal a few times.
Can we also start handing out achievements to repos and/or orgs?
I have a few where “Clear As Molasses” is a good one for the README: “Documents something useful in an entirely opaque manner.” (Edit: Maybe requiring you read the code to understand what the README failed to articulate about something basic?)
And it is no surprise that the behaviour of The Artists clashes with expectations of people that rely on accessibility. It is very telling if I read a blog where the content is about terminal stuff, and each and every example is a plain image. Unfortunately, this is spreading.
The social Justice Warrior: demands the project stop using some terminology they deem "problematic" while already having forked the project with a new name, just in case maintainers don't comply within 15 minutes.
The real shocker: one of those was merged after the two year mark. There wasn't any back-and-forth about the PR or anything like that, either. It was a low-activity project, and it had gone unnoticed. I had given up and pointed my `requirements.txt` at my own fork.
Someone else filed an issue about the same problem my long-pending PR fixed, I replied to that issue saying that would fix it, and that activity finally got it noticed.
I maintained a fork of a project for a while where I just grabbed all useful PRs from the "network" tab of the original repo and merged them / resolved conflicts. Fortunately at some point it was joined back to the original repo, but... yes, there's definitely a lot of similar opportunities.
There's a Firefox extension called something like "lovely forks" that shows the most starred fork for every repo on github. I find it useful for finding these kind of forks.
GitHub achievement badges seem a little juvenile and cringy and even if they successfully gamify GitHub, is that really a good thing? Are more commits and more issues necessarily a good thing? At best they draw focus to the wrong things, and at worst could become the basis of social-media style boastfulness.
Nope, it's really not a good thing. The github main page when you go there now is a "feed" page similar to other social media (twitter, facebook) that allows you to see stuff and tweak what the stream should show you. It's not a useful direction to go IMO. I don't want another feed/follow site.
Depends on the project, but I've contributed to a few big-name projects (podman being the latest) where I found a typo in their documentation, and they happily accepted it. I did talk to them in their IRC channel first, so YMMV.
One would hope all of the achievements period were rejected and this ridiculous idea of adding a gamerscore to a version control system wouldn't go past a round of laughter at the ones responsible, sadly it did go past.
"The Grandfather": you made your account in 2008 with a rage comic era meme handle and no associated email address and now it's completely broken and trashed by backward incompatibility bugs from all of the upgrades and changes and acquisitions made by github corporate and its various owners
I dunno if this applies to every case but I'll point out that doing that preserves the repo at a point in time from deletion but using GitHub's disk space, which is why there's a storm of them for any socially problematic repo. I'm aware the DMCA takedowns can easily target the forks but it's easy to take your chances
Interesting. That doesn't seem like a complete clear cut case of it though, more the git-fu of the repo maintainer there might not be all that great. :(
Even though they fucked up the author name on the commit itself, they at least attempted to credit you in the commit title:
Merge PR 7 from theodorejb; Add missing type declarations and fix incorrect PHPDoc types
While that's not fantastic as it screws up proper attribution with pretty much every automated git tool... it doesn't seem like a case of them trying to claim credit for someone else's work.
That's just my impression anyway. Could be wrong. :D
I mean in the end I'm not jammed up about it because my objective was to contribute back the local patches I made to scratch my itch, but it means I have to remember the PR number because that's the only evidence of my authorship
135 comments
[ 2.8 ms ] story [ 186 ms ] threadSome people are reading the title of the post as if GitHub had received proposals from their employees to include some of these achivements into the final feature set, and then decided to reject them, but the reality is that none of them were proposed by any GitHub employee at all. They are all “joke submissions” from the development community, making fun of the gamification of the platform.
Pointing out something obvious, then having someone else point out that what you pointed out is obvious, then defending the obvious thing that you pointed out by stating that it in fact is not obvious
Isn't this the entire point of having a feature request tag for issues?
This is not in a cynical way it's just likely not urgent.
"The Artist": posted a screenshot of a terminal instead of copy and pasting the text
"The Filmmaker": posted an animated GIF of their terminal session instead of writing out what they did
Maintainers _love_ artists and filmmakers!
"Captain Obvious": Opens a very aggressive and angry issue about the project not installing, when the maintainer responds to double-check that you didn't miss a critical and well-documented note in the docs, you disappear, never to reply again.
It's very common for people new to projects or with limited technical skills to assume that the problems they face are common/well known or that other people know much more than them.
The frustration responders face is due to the mismatch of assumptions, if the issue is in fact not common or well known, but IMO a simple "I haven't seen that before, please post full diagnostics" is an easy and reasonable boilerplate response.
The problem with that phrase is that you didn't state what is not working. I don't expect - although highly welcome - a complete diagnostics from the reporter, but please at least write the steps to reproduce your issue.
"The Shrug Reporter" might be a better name [0]
[0] https://www.computer-dictionary-online.org/definitions-s/shr...
"The Art Critic": posted a screenshot of a diff containing a suggested code change instead of sending a PR
I've actually done something like this exactly once when I was much newer to GitHub and git (and probably wanted to save some of my time).
No. Please, no!
For some reason, I get screenshots of text regularly from technical people. Log files, error messages, everything. It is like they forget Slack can send anything more than images and emojis.
No, I'm not typing out keywords from 3 pages of Java exception, nor am I typing an encoded AWS authorization message.
It isn’t just one thing that goes wrong with my team members.
I love videos and GIFs when trying to debug something. They're usually much better at catching small details than people's descriptions. Very often, the bug will hinge on an action that you can do in multiple ways, or some action that the user took directly before triggering the bug that they don't realise is necessarily part of the problem. Or maybe the bug only triggers on certain screen sizes or something, or if certain terminal colours are used, or if the user is using a touchscreen or something.
Having a video makes it a lot easier to notice these sorts of things. It's not always perfect, and a detailed description alongside the video is best, especially if you also have any errors or important text copied there so I can copy it myself, but given the choice, I often prefer video over text.
So yes, I genuinely love filmmakers in this context. Send me screenshots, send me videos!
I have a keyboard shortcut bound to run mpv with the content of the clipboard, so right click on gif, "Copy Image Link", hit the keyboard shortcut and wait for the gif to open in mpv where I can pause, speed up, speed down, scroll etc.
Also useful for any video or audio on the web, since mpv is (for me) much nicer than any built-in player.
Can we also start handing out achievements to repos and/or orgs?
I have a few where “Clear As Molasses” is a good one for the README: “Documents something useful in an entirely opaque manner.” (Edit: Maybe requiring you read the code to understand what the README failed to articulate about something basic?)
Edit: typo
"Internet famous": your repo had a bug so severe you got news articles written about it.
Both were from thinking about https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue... …
“Social distancer”: submitted a commit that just adds spacing.
“Edgycat”: contributed or suggested a badge for this repo (I’m earning this badge right now!).
“Duct tape”: sent three commits in a row that contain text “fix tests”
- Procrastinator for at least one vague memory of some high-faluting idea which never went anywhere beyond creating the repo.
- Monkey Wrench was sort of inevitable back when working without feature branches.
- Patient Skeleton: Sometimes I've pinged people ~yearly for a good while before realising it's just not happening.
[1] https://github.com/Flet/rejected-github-profile-achievements...
That award has my name all over it.
Full list of real achievements here: https://github.com/Schweinepriester/github-profile-achieveme...
The real shocker: one of those was merged after the two year mark. There wasn't any back-and-forth about the PR or anything like that, either. It was a low-activity project, and it had gone unnoticed. I had given up and pointed my `requirements.txt` at my own fork.
Someone else filed an issue about the same problem my long-pending PR fixed, I replied to that issue saying that would fix it, and that activity finally got it noticed.
The other one is still pending.
"Deadbeat": open at least 100 PRs in other people's repositories, without taking any action on comments or reviews
"I will raise with the team": (im-hiding-gif) An issue or PR with over 100 thumbs-up-emoji that has been open for over a year
"For legal reasons": (judge-emoji) A PR was opened with a fix to an issue, but because the CYA was not signed, the PR was auto-closed
"Business Model Blues": (bars-over-source-code-emoji) A License file has over 50% of its text changed
"Back from the dead": (zombie-emoji) You comment on an issue or PR that was opened over a year ago
- Vital contributor
- Sith Lord
- Secret Santa (twice even!)
- Monkey Wrench
- Patient Sceleton (still waiting)
- works on my machine
Not bad!
There’s gotta be a better name for this one, but I couldn’t come up with it.
So you have to clone the repo (forked or not) somewhere instead for it to be effective.
So many large corporate-run projects do this and, while I’m sure there are some compliance reasons, it just looks dodgy.
Ouch, that's pretty bad. Any stand out projects doing this that you'd care to mention?
Saying that from looking at your PR:
https://github.com/duosecurity/duo_universal_php/pull/7
Then looking at the commit which eventually got into their repo:
https://github.com/duosecurity/duo_universal_php/commit/c69e...
Even though they fucked up the author name on the commit itself, they at least attempted to credit you in the commit title:
While that's not fantastic as it screws up proper attribution with pretty much every automated git tool... it doesn't seem like a case of them trying to claim credit for someone else's work.That's just my impression anyway. Could be wrong. :D
I mean in the end I'm not jammed up about it because my objective was to contribute back the local patches I made to scratch my itch, but it means I have to remember the PR number because that's the only evidence of my authorship
"The useless": posted a message like 'x is broken'. No screenshots, no error logs, nothing.