I actually find that hugely helpful that so many people are actually actively expressing they are hitting this. It's not easy to be able to get an idea what issues people are actually hitting with anything you have made. An issue being bumped with essentially "me too" is a highly valuable signal.

Do you really think the maintainers don't understand that "doesn't work with Python 3.13" isn't going to affect tons of people?

There's some bozo asking "any news? I cant downgrade because another lib requirement" just two days after the maintainer wrote several paragraphs explaining how difficult it is to make it work with Python 3.13. This adds no value for anyone and is just noise. Anyone interested in actual useful information (workarounds, pointers on how to help) has to wade though a firehose of useless nonsense to get at anything remotely useful. Any seriously discussions of maintainers wanting to discuss things is constantly interrupted by the seagulls from Finding Nemo: "fix? fix? fix? fix? fix?""

Never mind the demanding nature of some people in that thread.

Just upvote. That's why this entire feature was added.

After seeing "Jigar Kumar" cognitive exploits on xz mailing list a maintainer would be excused (and I'd even say, encouraged) to just ignore pressure tactics altogether. It's an open source project - if it works great, if it breaks, you get to keep both pieces.

To the non-technical founder, this is doing something.

They will not move to ~~mocking up~~ sketching a wireframe of something.

>Do you really think the maintainers don't understand that "doesn't work with Python 3.13" isn't going to affect tons of people?

I had trouble parsing this sentence. Claude simplified it for me as follows. AI to the rescue!

"Do you really think the maintainers fail to realize that Python 3.13 compatibility issues will affect many people?"

Considering the python ecosystem is not keen on staying updated anyway, I wouldn't be surprised a maintainer doesn't realize a new python version not working is that important.

Reactions, though.

It’s not just that, it’s people commenting “this is unacceptable” and “I hate this library” that add very little value.

Also, you can upvote issues as well / leave reactions without leaving comments. It ensures a better signal:noise ratio in the actual discussion.

That's why github added emoji reactions many years ago, so you can express "me too" without spamming the notification systems.

https://github.blog/news-insights/product-news/add-reactions...

We shouldn’t rely on emojis for stuff like this, this is not about anime shows or anything similar. More to the point, I instinctively ignore all “emoji”-related “communications” on pages like these, which most probably are related to day-to-day work and to putting food on the table, I only look at actual text. Infantilization of Western society is partially responsible for why we’re in all this mess.

Maybe then GitHub should add a text-based expression for people like you.

Like Google does in Gmail, where you can turn off the icons for the "archive", "report spam" actions so that the text is shown instead.

I'm sure this would add a lot of value to GitHub /s

Or you ask your OS vendor (or each website operator) to also ship an optional set of emoticons with less childish images. Start a petition and I'll sign it.

Emoji being associated with infancy is a thing that only exists in your brain and only because young people were early adopters of emoji about 15 years ago. Emoji are just as valid a means of communication as any other.

It's definitey not only in their brain, it's in my brain, too.

On a related note: Emoticon > Emoji.

Bring back B~), get rid of those silly newfangled unicode monstrosities.

Element and discord and the Samsung default keyboard try to :coloncode: any emoticons you type.

This is on desktop and mobile, since the two apps are electron.

\>. <

Good thing I don't use Element as my Matrix preferred client. Discord and all Samsung software are more or less indistinguishable from spyware the way I see it, as most closed-source proprietary software is. That's a major if not primary reason why it's closed source: it's doing naughty stuff against the interests of the user that the developers want to conceal from their victims.

It doesn't matter how many other people prefer to throw their own privacy off a cliff, irrational and self-harming group conformity concerns don't afflict me the way they seem to afflict neurotypical people. One of the blessings of being on the spectrum.

The point is that for the typical older HN denizen, emojis were legitimately a sort of counterculture element associated with trivial conversations in the counterculture of our youth.

That's not what they are anymore. They have a rich meaning - ask a young person what :) means and you'll have your example.

Emojis are, like it or not, part of the lexicon now.

You can use whatever dialect of language that you want. I'll keep using the same as the people commenting above, which doesn't include emojis.

>typical older HN denizen, emojis were legitimately a sort of counterculture element associated with trivial conversations in the counterculture of our youth.

Emojis didn't exist in the youth of the typical older HN denizen. They are the exclusive purview of Gen Alpha, Gen Z, and younger millennials.

Huh? Emojis have existed since BBSs

I think emojis are easily overused, but I certainly don't mind when they're used to convey simple, universally understood meaning (such as reacting with a "me too" in a bug report).

Stuff like gitmoji, though, drive me nuts. Talk about ambiguous and easily misused. Faster for everyone if you just say what you mean.

It is a button that let's people say "me too". It really doesn't matter if it is labeled with a thumbs-up emoji, the text "me too" or Rick Astley dancing. Don't think you are better than others because you are too "proud" to click a button with a thumbs up image on it.

but in a way that's easily ignorable, for convenience.

I very rarely use emojiis on github. If I can't add anything to the discussion / issue, I post nothing. So if there's enough people like me, an issue can languish.

However the barrier to entry for a lot of issues reporting is pretty tall - requiring triplicate documentation of everything. It's like an overreaction to the sort of people that need to be told to unplug something for 30 seconds to continue the support call.

And that's if they even "allow" issues.

I was posting in issues note frequently 1-3 years ago. I'm sure I'd be sheepish about some posts.

You're missing

5) Do 1, 2, and 3

6) Submit a a tested pull request with a fix

Except when you do 6 the maintainer rejects the request and says that it wasn’t a bug at all, and everyone is stuck with the bug.

Pull requests should not be normalized. The guy in charge of the code base has complete knowledge of it and can always do a better job than randoms making ad hoc changes to quick fix their own problems. Complaining about bugs and missing features is much easier. It's less of a headache and requires less effort and time investment.

The truth is developers don't want to end up maintaining other people's code until the end of time. It's gotten to the point I roll my eyes whenever I see people saying "patches welcome". Chances are they're not as welcome as you would think. "Show us the code", and when you do... Nothing.

Submitting a pull request is no guarantee that they'll accept it. Hell, it's no guarantee they'll even give you the time of day. You can put in a whole lot of effort and still end up getting refused or even straight up ignored.

Even if it's an unambiguous improvement on the status quo. They'll commit code that literally returns "not implemented" directly to master and actually ship it out to users. Your pull request will certainly be held to much higher standards though. And that's if they engage with you in an attempt to get your patches merged. They might just decide to ignore your patch and redo all the work themselves, which is exactly what all the complainers wanted them to do in the first place! If they're really nice they'll even credit you in the commit message.

Boo to you. I've up-streamed patches to scipy and a few other python packages. Nobody ever said no to genuine high quality bug reports that were coupled with good fixes. Not saying that will happen every time, but if you're unsure, ask how receptive they are.

I've upstreamed patches too and I increasingly feel like it's a waste of time and that it requires far more effort than it's worth. Good maintainers who work with you are rare. I remember the ones who did that.

> Nobody ever said no to genuine high quality bug reports that were coupled with good fixes.

Uhuh.

> ask how receptive they are

Doesn't really help much. It's entirely possible for people to tell you it's fine then change their minds after you actually do it and send the code in. Seriously hope you never have to experience anything of the sort.

Truth.

We should normalise GOOD pull requests. And possibly avoid making garbage ones that fail 100% of the testsuite.

Oh please. You can put effort into all that, observe all the best practices, follow all the rules, try your very best and still end up with literally nothing to show for it simply because the other guy doesn't want to.

Always fork the project and customize it for yourself. Don't argue with others, don't try to convince them, make your version work better for you. It doesn't matter if they want it or not.

Eh, most of the time you do have to publish it. MIT/BSD/Apache allows you not to, but most big projects are using LGPL or another share-alike license. With those, if you're making a project that you do publish (e.g. a commercial product that uses that library/language/etc.) you do kinda legally have to share that modified source code. It's of course different if you're scripting for your own sake, but the moment you publish anything using them you also have to publish your modified versions of libraries and other stuff.

I do agree with the "fork and make it better for you", but I also think it's common courtesy to throw up issues for the bugs or missing features you encounter, as well as pull requests. If for no other reason then as "prototypes" or "quick fixes" that others can cherry-pick into their own forks. They may get rejected, they may get closed, but you still don't have to sit there arguing about it since you have your own version. From a slightly Kantian angle you have your working version and you've now fulfilled your social duty by offering solutions to problems. You've got no need to campaign for the solutions if they get rejected.

It's virtuous and you get to ignore the github flame wars. There's really no downside beyond taking 5 minutes to be nice and at least put your solution out there. Also fulfills your reciprocal legal duty under LGPL and such.

If you don't distribute to others you don't need to distribute your own changes even for copyleft licenses. That's why the AGPL license was written, because if you're doing something as a service you won't need to distribute any sources even with GPL license.

I think the best way to go (if you're the "Good Samaritan Who Wants to Do His Civic Duty but Also Doesn't Want to End Up Spending the Week in Nerd Court") is to fork it, fix it, and leave a brief comment in the issue thread that says "hey, I fixed this in my fork".

That way, people with the same issue who come in to the issue thread through a search aren't reduced to combing through all the forks to see if one happens to fix the issue. Then instead of spamming up the thread with "me too, this is soo frustrating, fix asap pls", they can spam it up with "merge this fork into the main project asap pls" :-)

> you do kinda legally have to share that modified source code

I'm using the license exactly as intended. Upstream developers literally don't matter. Free software is not about developers, it's about users.

Free software licenses say the user gets the source code. They're about empowering the user, in this case me, with the ability use and modify the software as I see fit. If I customize something for my personal use, then I'm the only user of the fork and license terms are fulfilled. People would only get to demand source code from me if I started distributing compiled executables to other users.

> You've got no need to campaign for the solutions if they get rejected.

I used to feel that need. Caused me significant anxiety. I thought upstreaming patches was the Right Thing to do. Mercifully I've been cured of this misconception.

> There's really no downside beyond taking 5 minutes to be nice and at least put your solution out there.

I have no problem with that. My point is getting involved with upstream is often more trouble than it's worth. Let them do their thing. Just pull from them and rebase your changes. Enjoy life.

People should think twice before trying to cram their unsolicited code down other people's throats. Even when they ask for the code, chances are deep down they don't actually want to deal with it.

Usually better start with small scale fixing typos and improving docs. That’s great canary for me. If it’s accepted within day or so, that’s project which I willing to learn. I would say you can select projects for your value and you would be fine contributing there. Eventually people will learn you and will trust you more

I understand your point and it's good advice. Typos and documentation though? That's boring... I want to do interesting things. Ever wondered why some program can't do something? Surely someone much smarter would have thought of it, right? And then you code it up and it actually works? That's the kind of thing I like to do.

I once tried to retrofit a library system into GNU bash of all things. Let's just say it didn't go well.

Your patch sounds horrible, no wonder people reject them.

Works for me. I can easily organize and reuse functions now. Made scripting much more pleasant. Even made a package out of it so I could install it alongside the upstream version.

That is exactly why I said that that only comes in once you publish something. The legal argument isn't as strong as the moral one is for me anyway, I never publish anything. I think making a PR isn't forcing code on someone, they're not obligated by anything to read and consider it, but if they do want to they can. I'll make one, and then I'll stop responding, because that's where my personal moral obligation ends. Whoever wants the code can now easily discover it, whoever doesn't can throw it away as they like. Including the upstream maintainer.

Those are great guidelines for never achieving anything relevant.

Also, the same ideas applied to dating rather than to code are what we call "incels/redpillers" and so on, so you might want to calm down a bit I think.

> Those are great guidelines for never achieving anything relevant.

Relevant to whom? Everything I've done is extremely relevant to me. I wouldn't have done those things if I didn't care about them.

> Also, the same ideas applied to dating rather than to code are what we call "incels/redpillers" and so on

I'd say it's more like MGTOW.

MGTOW are incels/redpillers though.

They're related but not the same. In this context, an "incel" would be someone who's incapable of contributing to projects despite wanting to. That's not my case.

If your contributions have all been rejected, it could be that they weren't as good as you think they were?

I've certainly made people angry when I rejected their buggy "improvements".

> If your contributions have all been rejected

They haven't.

I see your point though:

> it could be that they weren't as good as you think they were

Who knows. Maybe. Asked myself that question many times. Asked others.

It doesn't matter anymore. Now I only wonder if they are good enough for me.

I wish more people attempted to actually grasp their dependencies by the scruff of their neck and got to know them deeply.

The Refined GitHub extension [1] automatically hides comments that add nothing to the discussion. [2]

[1] https://github.com/refined-github/refined-github [2] https://github-production-user-asset-6210df.s3.amazonaws.com...

Wow, that extension is a gold mine of much needed GitHub functionality

Geez honestly

This seems to be the issue https://github.com/explosion/spaCy/issues/13658#issuecomment...

And you depend on opinionated libraries that break with newer versions. Why? Well because f you that's why! Because our library is not just a tool, it's a lifestyle

Though it seems that Pydantic 1x does support 3.13 https://docs.pydantic.dev/1.10/changelog/#v11020-2025-01-07

What is the passing answer?