"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.
> "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.
> 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 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.
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
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
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.
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
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!
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.
I get that Kubernetes is a hugely popular repo, and they obviously have lots of issues opened frequently, but my god, the stale-bot they have in that repo is the worst for that.
Gitlab also. It's a great way to externalise your prioritisation process, but if they have product managers they should probably be manually closing/deprioritising issues.
"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
I would say the "thumbs up" on a comment is one of the most helpful things on Github, it telegraphs that a comments is usually the fix for something, if we didn't have loads of people doing the "thumbs up" reaction on comments, we wouldn't effectively have stack overflow style answers in comments.
Side note - it would be if Github squished all of those down into reactions and next to the reaction added a line saying "we squished the following comments to reactions (show squished comments)".
YouTrack kind of has support for that https://www.jetbrains.com/help/youtrack/server/Workflow-One-... and I thought they muted the notification email for the comment, but I couldn't find any evidence to support my recollection. Similarly, I thought they had a whole series of "low value comment" handlers but also similarly I wasn't able to find any evidence of my hallucination
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.
It's been a joke among 2 of my friends (and collaborators) that no matter what code they write, a "cleanup" commit by me would refactor/prettify everything.
I deserve the Tee Hee (and some professional help).
"What changes?": As a maintainer, you accidentally update a committer's branch with main instead of your local changes, which closes the PR and drops your access to push to the committer's branch.
I have gone years working on projects completely solo. Probably 99% of my commit messages are just the word "update". I also tend to do it excessively, like I am afraid the hard drive is about to crash or something (so far it hasn't).
Not sure what you would call that. Maybe "The Saver", or "The Save Scummer", or "The Scummer", or maybe just "Scum". (I can see the last one if anyone else was actually looking at these commit messages, but that almost never happens, and on the rare occasion when I know they will, such as for a PR or something, I rebase and write something descriptive).
Honestly the fact that we're too scared or sensitive to flag anti-patterns like these, is a disservice to the evolution of the practice of software development.
Most people would benefit from this feedback... maybe if it was not public-facing, it could be palatable as a legitimate feature.
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.
"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!