"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.
> "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.
> "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!
> 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.
"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
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.
Honestly the "This is fine"-badge for over 1.000 open issues on public repositories is very necessary.
There are so many opensource-projects now as compared to 10 years ago, especially in JavaScript-land, which have an unbelievable number of open bugs.
This is terrible because the majority of these bugs seem to be low-quality, so even if you are a seasoned developer with contribution experience, opening up a bug with the incentive to help simply gets you ignored.
I'm waiting for a bug in next.js at the moment where 404 does not return 404, that has been open for months (https://github.com/vercel/next.js/issues/51021). I don't have the time of writing a PR, but I have written countless PRs and bug-reports and worked on many other open-source projects, so I think I have done my share.
It is elitist, but I wish there was a way for maintainers to sort bugs by the reputation of the reporter, so projects can prioritize high-quality issues.
Yeah, if only there was some way for people to exchange value... Like, you know, paid licenses, support tiers, something that Ancient Romans called running a business. /s
But no, everything must be free, and then shock-and-surprize: open issues are piling up and nobody wants to deal with them.
It's "1000 open issues on public repositories you own", not "1000 open issues created by you on public repositories". Both would be interesting, though.
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
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.
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.
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.
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.
Readit News
"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 Shrug Reporter" might be a better name [0]
[0] https://www.computer-dictionary-online.org/definitions-s/shr...
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!
“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”
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.
"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... …
"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).
"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
There are so many opensource-projects now as compared to 10 years ago, especially in JavaScript-land, which have an unbelievable number of open bugs.
This is terrible because the majority of these bugs seem to be low-quality, so even if you are a seasoned developer with contribution experience, opening up a bug with the incentive to help simply gets you ignored.
I'm waiting for a bug in next.js at the moment where 404 does not return 404, that has been open for months (https://github.com/vercel/next.js/issues/51021). I don't have the time of writing a PR, but I have written countless PRs and bug-reports and worked on many other open-source projects, so I think I have done my share.
It is elitist, but I wish there was a way for maintainers to sort bugs by the reputation of the reporter, so projects can prioritize high-quality issues.
But no, everything must be free, and then shock-and-surprize: open issues are piling up and nobody wants to deal with them.
You are saying people have less time for their projects now as compared to 10 years ago.
Who would be able to open a 1000 issues? Are you referring to trolls?
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?
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
Deleted Comment
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.
That award has my name all over it.
Full list of real achievements here: https://github.com/Schweinepriester/github-profile-achieveme...
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.