Great! Thanks for the feedback. I had something that I thought I could throw over the fence and then get on with my life because I had a solution for myself, but now that you mention it, that's not a good way to approach it. Instead I deleted it and forgot about it until today.
The thing that threw me off was the "Not again. Use search before you implement anything" comment. Ok, so if it's a recurring issue why isn't it fixed? It's not a big fix.
The best approach I've come to over the years is "don't make people think" - so, if you have the time - make something almost zero effort to see that it works and zero effort to apply.
This could mean screenshots - or sometimes something like a youtube video, or just logs of before and after.
Show visually the before and after, and try and write descriptive titles etc.
If it's github, then a PR (instead of just an issue).
Having said that, I don't always have the time.
There are also slightly more dark patterns, like if you are fixing something including "broken" in the description of the bug will grab more attention.
[EDIT]
As an example on this PR:
I would have written a title like:
"Don't fail on filenames over max length on Windows and Linux"
In the description, try and write the thing that is fixed first (you dive into the implementation) so that if someone only reads the first few lines they still know what's up.
Then dive into the implementation.
Imagine the person has very little attention span - maybe they are scanning the bugs while their small child is bugging them, you need the important info first, and you need to grab them (but don't go as far as click bait).
On a similar thing, use hyperlinks when you mention other bugs (e.g. you mention) #15024 - just make everything as little effort for them as possible.
Throwing things over the fence as a drive by is rarely useful. Maintainers are busy people, so dropping off a clue that would take Sherlock Holmes time to solve isn't helpful.
Imagine you're the maintainer being asked to look into something. Would you rather have all of the information provided in as much detail as possible so that you could dive right in and fix it, or do a deep dive into something that may or may not even be a problem but something from a grumpy person on the internet?
I guess it seemed like such a trivial fix. What's to explain? If you know the code you go to where you make the file name and put a limit on it. I guess there are other considerations that I am not aware of. I was not grumpy. I thought I was doing everyone a favor. To be treated like they were doing me a favor induced cognitive dissonance.
Edit: Just to clear I love youtube-dl and use it all the time. I greatly appreciate all the work that went into it. I have no problem with the maintainers. I only posted my original comment because I want to contribute to open source now that I am retired and wondered what went wrong my first time. Now I know and I thank everyone who took the time to comment.
Long ago I created a bug for this (not a PR) myself. IIRC the problem is the author had some grand design for platform neutral filename handling or something, so didn't want some simple fix that would be "temporary."
It's just silly and lacking perspective. Letting the bug sit in there while procrastinating on some larger project. Waiting for some ideal circumstance, but not acting to create it, so nothing happens. But, to do the "temporary fix," you have to admit you're not acting on your goal.
Fitting that the author would abandon the project, if they are making such intentions and not following through.
The thing that threw me off was the "Not again. Use search before you implement anything" comment. Ok, so if it's a recurring issue why isn't it fixed? It's not a big fix.