
It's a valid label, I don't even see it as particularly rude. The reason people go to school is literally a skill issue.
gigabased holyyyy
RTFM is not a valid response if the manual contain no information on what the software is or even how to run it (or where to even find the manual, if the manual even exists). Is this a standalone program? A plugin for another program I'm already using? No links to any useful information whatsoever.
Then the guy that sent me the original link tells me "oh yeah, all that info is on youtube". Nope, I'm done. I'll use something else.
Questions for you and your upvoters: when you were growing up, did you climb a lot of trees that were way too high for you or did they have fences to keep you away from them? Were you required to wear a helmet while riding a bike? Were you even allowed to bicycle anywhere on your own? Did you ever have to figure out how something works on your own, or has it always been your default response to give up when someone isn't there spoon-feeding you the answers?
Climbed trees, rode without a helmet, and setup the home network without any documentation whatsoever. Been there, done that.
It's not 2005 anymore. I have a job, a significant other, and other shit to do that's more important than documenting someone else's hobby.
You dont understand manuals? Yikes
Open source is free, but empathy is still a good feature.
How is labeling a bug report that is based on user ignorance a lack of empathy? It's just sometimes factual that users are still learning and make mistakes, and I say this as a low skill FOSS user and enthusiast.
I've seen this on a few repos and it never came across too harsh, the posts tagged with it were deserving. Wish I'd noted the repo names..
I'm fine with it tbh. FOSS devs need to squeeze every bit of enjoyment out of working on the project to keep motivated. If they (or mods) can drop a helpful reply and close an issue as 'skill issue' and get a little chuckle while they give their time for free answering poorly-written queries or bad bug reports then that's a reasonable trade to keep them from burning out.
Sounds like a skill issue on the dev’s part.
Yeah, users might get a bit upset about "abrasive devs" but like, as you said, it's devs that give their free time and energy into developing the project. Users honestly ought to respect that a lot more
You have to have a skill issue before you can have a skill. No shame in it.
Better than PEBKAC.
Pee Easy Bro, Kangaroos Aren't Coming
Propogation of Errors by Bleak Knowledge About Coding
AKA PICNIC
Alarum, Koalas Above!
Please Invert Canopy Now In Case
i'm a classicaly trained IT guy, I still call them "Layer 8 issue"
The good old ID-10-T error
Unfortunately some users are just about bright enough to work that one out.
For those I just attach a note about it being an "IOT Error" in their report. Internet of Things is not, after all, that much different than a Internet of Tools.
I don't work on networking but I'll be adopting this from now on. https://en.wikipedia.org/wiki/Layer_8
I just say the problem is between keyboard and chair.
Oh yes, good old PEBKaC
I swear, i have read some issues...
So, i sometimes help people who have problems with an android CLI launcher
There is a fucking command called, "help" and when you open the launcher one of the first thing you see is "write help to get a command list", you write help and you get a list of all commands and there is even a wiki (not complete though) that explain some commands and they STILL ASK "can you add [command that already exist]?".
So i kinda feel why some people want a skill issue tag
I'd say "sure!" Then amaze them with how good and quick I am by telling them an hour or two later to "try it now "
What you describe sounds more like a "competence" issue than a skill issue - can't have the latter without first having the former.
That way you teach them that
- you are somehow a magician
- they can ask for any stupid thing and you will do it right away for them because what else should you be doing
- it doesn’t matter if this feature even fits into your plans because all you want to do is grant every wish
- a new feature is written and will appear instantly at the users computer. Who cares about testing or of this breaks other features as long as this guy is happy
They are beginner devs, so they should learn to understand how things work.
Who spends their day "browsing around GitHub"?
i agree if anything i would browse codeberg:p
I mean not with GitHub but I do the same thing with mega scans. I have a lot of rocks in my collection.
Good idea.
I shall have to add a "skill issue" label to my git repos.
Here's what I'll say, management taught a generation of devs to ask instead of researching, aka rtfm. If I had a quarter for the number of times I was told to ask for help sooner by a non tech manager I could have retired by now and had a farm.
From personal experience:
One part is manuals / docs being hard to use. Some seem to assume a measure familiarity with the subject, creating a certain entry barrier. They're perfectly usable as reference for people who know the gist but look up details, but for younger devs, it's disheartening to get the sense that you don't understand anything. That's a common issue with FOSS tools, in my experience, where the devs naturally prioritise developing the actual tool. Asking and getting an answer for a specific example can help get a foothold and start climbing that, but it's no guarantee.
A second part is that manuals don't always cover things you can't do (because obviously it's hard to predict what people would come up with wanting to do), but it's hard to tell whether that's just incomplete unless you ask and get an explicit, hard "nope". Bonus points for commercial products documenting what you can do, but not with your current license: You'll diligently read the page for what you want to do, attempt to implement it, then be hit with "please upgrade to Premium for this feature".
A third part is terminology. Just like the non-features, it's impossible to predict all the ways someone might describe what they want to do if they don't know any better way to phrase it. I'd count language barriers into this as well, which is an issue that a smaller, US-heavy software development world wouldn't have had to the same degree as we do today.
And finally, of course, there's convenience, which is where I think the managers have the greatest impact: The less time you have to spend learning how to RTFM or digging through the docs, the less time is "wasted" on things that aren't immediately productive. Particular non-IT-background managers may not appreciate the value of such skills, so they'd rather have you spend someone else's time taking a shortcut than invest your own.
So I think this is an issue arising naturally from several independent factors, which makes it hard to tackle effectively. Managers should plan for and encourage taking time to understand the manual, but I don't see a universal solution to the documentation quality and language barriers.
Also, retiring to have a farm is a mood.
For the first part:
That's why you need and have to be aware of a target group.
It's because for every dev who asks too soon there's another dev somewhere that doesn't ask at all, bills 300 hours their first month without being asked to, delivers nothing because they refused to ask for help and couldn't figure it out either. That dev is why people hate off-shoring to India. They did not work a second month.
That’s preferable to people who don’t ask for help until everything is hopelessly fucked because they kept trying to solve their problem different git commands, none of which they understood.
Programmer Humor
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics