I found a one-char typo in the docs for Python's typing_extensions library | Hacker News Reader

I found a one-char typo in the docs for Python's typing_extensions library

twitter.com

209 pointsobi1kenobi112 comments

If you think that's bad, try figuring out where to report bugs or even find the original source code for several of the tools and libraries we all use every day. Some of them don't seem to have a web site, only a bunch of unofficial mirrors in various states of disrepair. Some have no way to get to the source code history; only the tarballs for the releases are available. Some have no issue tracker, and, if you're extra unlucky, no mailing list. Even worse, some have buggy mailing list or issue tracker setups, where I'm unable to create a new account, the activation email never arrives, I can't figure out the password requirements, the CAPTCHA refuses to accept any of my answers, or submitting the bug just sends you to an empty/error page, having helpfully cleared the form data from your browser so you can't go back to resubmit. Oh, and some projects won't create a new release for simple bug fixes, so you won't get a fixed version through your package manager anytime soon.

It's no wonder we're still finding critical issues in core projects. What's a real wonder is how someone managed to navigate the maze to trigger the process to get a change all the way through release.

You'll notice how I'm not mentioning how to fix any of these problems, and that's intentional. Each project will need significant effort and/or money to get to a reasonable state, but many people who want to help will give up.

You mean like putty only being served over HTTP until like 2019?

incidental, have you donated to putty?

No, but i haven’t used it pretty much at all since I moved to linux in 2016.

Edit: but I’ve submitted various security vulnerabilities to oss products, real actual issues too, not Nessus output.

Are you implying putty devs didn't serve over httpS b/c they couldn't afford to?

Because they were busy with their paid job.

Perhaps more likely: because they were the sort of people that disliked the certificate authority cartel, and preferred to rely on a GPG signature until letsencrypt came along.

Then why aren't they too busy to develop putty also?

I don't like the idea of security matters being payed extras.

Would you make free cupcakes for people, but refuse to wash you hands while doing so unless someone paid you to?

"Hey, I'm too busy with paid work to make my cupcakes hygienic; you want clean cupcakes, make your own!"

If someone made free cupcakes and didn't wash their hands, I wouldn't eat them. I wouldn't get angry that they spent their free time making cupcakes that I didn't really want.

And the wonderful thing about open source is that you can take the existing code, fork it, and do things the way you think they should be done.

No salary? No obligations.

> I wouldn't eat them

How would you know unless you asked. When someone offers you something for free, do you interrogate them over their process? They aren't paid to answer your questions either. The end result is no one should accept anything that is free.

Well done, Microsoft just won.

> the wonderful thing about open source is..

Are you writing your own OS, prog-lang and compiler from scratch too?

If "you can take the existing code, fork it" is the only way to get secure code, then the real implication is having secure code requires you to "take the existing code, fork it";

This sounds less like the wonderful thing, and more like the terrible thing.

> No salary? No obligations.

Then why can't people give legal/medical advices without licence?

Why can't I see a dying man in the street and choose not to call 999?

Why can't I refuse jury duty, or the draft etc etc?

You sound incredibly entitled. "Give me free things done to my specs, or Microsoft won. No, of course you don't deserve a salary for that."

> Are you writing your own OS, prog-lang and compiler from scratch too?

Yes -- I'm an OpenBSD and 9front committer, and I have built my own language and compiler. My website -- https://orib.dev -- runs code I can commit to all the way down to the hardware.

But that's neither here nor there. I do that because it's fun. You also don't get to demand work from me without paying.

> You sound..

Is sounds entitled b/c you paraphrased it uncharitably.

I didn't ask for "any spec" - there's a big (Hippocratic) difference between dictating what form something comes in, and asking that it do no harm. A poison cupcake, much like a poorly secured software, could wipe out any benefit it brings.

Also, I'm not demanding anything: feel free not to produce anything; But if you do, make it reasonably secure, or clearly/explicitly communicate that is it insecure; in the same way websites are (supposed) to seek permissions for cookies rather than assume them.

The context of "or Microsoft won" is that MS pushed the idea that FOSS could not be trusted without legal liability - this essentially makes that case.

I provided a few example of where people are expected to do things without being paid, do you also refuse to do those things?

Isn't this like some kind of canary, to warn people that putty might be backdoored?

If you have citations on that I’d be curious, but unencrypted http in a vulnerability which mean nodes in the middle can automate injecting malware into binaries, meaning it’s be a weird place to draw a line in the sand as a canary

It's a dangerous thing to do as an adversary. Many organisations will automatically hash and collect all binaries before they execute on any of their machines.

Finding a putty.exe that is different to every other putty.exe in the network sure sounds like a red flag worthy of someone uploading to virustotal and then project zero getting their hands on it....

I don't think GP was talking about replacing all downloads with malware, just key ones, like individual targets.

It was just a weird idea I had. Not a canary, but a way to say "we cannot guarantee that exe is not compromised because of things we can't talk about, so there is no need to provide https to secure it, so here is just http".

You wouldn't even need to serve actual malware, just give people an old version of PuTTY with either a known vulnerability or insecure defaults.

You might want to consider how much the people who are (not) paid to maintain them make.

That's a cheap barb. First, I maintain a bunch of (small, to be fair) FOSS projects, mostly with zero payment over many years. Second, I've supported several projects with actual money. Third, if I can't reach anyone at the project, how am I supposed to support them with time or money?

That's irrelevant. Just like how nobody should have expectations from you, we can't have them from anyone who donated her free time once upon a time.

It's not irrelevant. When a community project depends on another project, it depends on it, (both factually and tautologically.) If the original maintainer evaporates, the community project needs to adapt by either moving somewhere else or forking away and adopting the project. Else the community is in a broken state, all other expectations aside!

That's not to say the original author owes any debt to the community, but when pay is the only motivation you wind up with chronically broken communities optimized for rent extraction. (And I'm definitely not saying that OSS authors shouldn't be paid either...) authors can walk away from their creations, but it doesn't make the result of doing that without any concern any less important or relevant here.

You're not really suggesting that OP's concerns are somehow irrelevant because code owners need to be protected from bad actors by annoying/bugged-out or broken gatekeeping robots, are you?

If only they provided a way to give them money without doxxing myself. If I have to register a Paypal/Stripe account or otherwise give a third-party sensitive information, it's a no-go. There are several times when I've started the process of donating, only to abort because whatever payment processor they use blanket-403 Tor.

GH Sponsors works great when you're sponsoring as a company; I can't use it as an individual.

An easy way to provide this is to put up a BTC address (and potentionally ETH if the recipient is willing to deal with the potential managerial overhead of that).

> only to abort because whatever payment processor they use blanket-403 Tor

If the only page blocked is the donation page, it's not that bad! Many supposedly tech-friendly websites block Tor as soon as the homepage... But i share your sentiment. More than once, i've found a snail mail address for a project i cared about and arranged to send some cash in a letter along with a thank-you note. That has always triggered friendly interactions that Stripe/Paypal never provided as part of their offering :-)

On a side-note, i'm always glad when some NGO serves as a front for donations to smaller projects. Setting up a bank account with Stripe (or whatever) as a maintainer is a burden. But thanks to liberapay.com or opencollective.com making and receiving donations is much easier. Another one worth mentioning fdn2.org maintained by LaQuadrature, which also enables you to donate to April (FLOSS NGO), Framasoft (libre culture/software NGO), Wikileaks (no introductions necessary), Nos Oignons (Tor operators NGO) and Exodus privacy (static analyzing of trackers/malware in Android apps).

Worse than that, many would block any VPNs. Worse yet, they won't just say "we see you value your privacy, we hate folks like you, go away" - their site just starts spewing random errors or timing out. Eventually you'd guess "oh, they hate VPNs, that's why!" but it takes time and experience to learn.

> An easy way to provide this is to put up a BTC address

The barrier of stripe or paypal (neither of which require accounts for payment) is _far_ far lower than the barrier of going and fetching some bitcoin.

The barrier is still close-to-0 to accept donations - the recipient doesn’t need any existing cryptocurrency in order to generate a wallet and start accepting funds.

That aside...

Maybe for you, not for me.

PayPal and Stripe do require accounts, nondeterministically based on various factors like IP address. For example, I can not use PayPal from my residential IP. Several attempts to address this via phone and email yielded nothing but frustration and lost hours.

Not to mention that both are subject to US sanctions laws and thereby legally prohibited from serving individuals and entities who happen to be in or from “the wrong countries”.

Having a wallet that can be sent bitcoin doesn't really qualify as "accepting donations" unless you have a way to convert that bitcoin in usable fiat. Thus the barrier is definitely not "close-to-0", especially once you consider potential tax reporting implications.

Besides that I disagree with that "easily converting to fiat" is a disqualifier, read on: Assuming that you as recipient don't mind centralized finance and are just interested in getting out fiat: Open account at e.g. Coinbase. Send in crypto. Convert to fiat (e.g. USD). Wire everything to your account. Report the amount you cashed out as if you had received the corresponding amount in fiat directly.

This can be done later, or ahead of time.

Alternatively, if you really want the full legacy finance experience a la paypal, you can set up an account that auto-converts it to e.g. USD and sends it straight to your account. For you as a recipient, this is pretty much the same experience you would get from say a normal cc provider. IMO it's preferable that individuals control their own keys but to each their own.

Yes, this setup doesn't give you as a recipients all the benefits of the crypto-economy - except that you can now receive funds from it, and provide those benefits to your donors.

> disagree with that "easily converting to fiat" is a disqualifier,

You can't (generally) pay rent or buy groceries with bitcoin. Donations that can't be spent aren't really useful as donations.

> Open account at e.g. Coinbase. Send in crypto. Convert to fiat (e.g. USD). Wire everything to your account. Report the amount you cashed out as if you had received the corresponding amount in fiat directly.

Which is more work than setting up a PayPal account and is certainly not a "close to 0 barrier" as claimed.

> Donations that can't be spent aren't really useful as donations.

And my employer-sponsored 401k account isn't useful to me either... seriously you may not believe in "Bitcoin is sound money" or whatever crypto flavor of the day, but I actually think it might be OK if it necessarily takes most people even a bit longer than a year to figure out how to "cash out" their Bitcoins.

I mean that you honestly have to be pretty obtuse to believe (today) that someone who received a bitcoin donation in any year before 2021 (and kept it) received what amounts to a "not really useful donation." Year-on-year, even in a bear market, yada yada – none of these are good reasons for you to BUY bitcoin, but as someone receiving a donation from a human who thought you did a good job, I think maybe "try not to look a gift horse in the mouth" is a valid adage here?

You, as someone who likes BitCoin and wants more of it, are perfectly free to have a wallet people can send donations to.

You are insisting that people with no interest in owning bitcoins set up wallet, figure out tax rules etc... Just so you can do the the favor of sending them bitcoin.

> you honestly have to be pretty obtuse to believe that someone who received a bitcoin donation in any year before 2021 received what amounts to a "not really useful donation."

I believe there are tons of people, pre-2021, who received useless bitcoin donations and lost the key before they converted it to an actually useful currency. I don't believe this because "obtuse" or whatever other names you want to call me.

> received useless bitcoin donations and lost the key

It happens? But at least you avoided the tax accounting, right...

> Which is more work than setting up a PayPal account and is certainly not a "close to 0 barrier" as claimed.

Not only that, you don't actually need an account to pay with paypal or stripe. You can do checkout as guest, and enter a card number and be done with it.

> especially once you consider potential tax reporting implications

Do you think the issue of tax reporting for donations is dismissed when you avoid crypto? Unless your project is incorporated as a 501c3 or other non-profit entity (which has its own set of onerous reporting requirements, this is not a backdoor escape hatch) I don't see how that's any less of an issue without cryptos.

You can avoid capital gains reporting, but your cash donations are still income and must be counted. They will be taxed.

The Python Software Foundation is a registered charity so https://www.every.org/python might work for you. Every.org wants you to type in a name and email though even if you use cryptocurrency, I hope they fix that

Consequential would be not using these projects, or adopting them if you need to use them.

Nobody wants to work on those things. There's no glory. You'd have to be paid to struggle with maintenance. A fundamental issue with open source to be sure.

Now try doing all that but without a properly functioning search engine or good docs while navigating multiple layers of bureaucracy for a 1 line bugfix. Welcome to working at a megacorp.

(Python core dev here.)

Python is well into the process of transitioning from bugs.python.org to GitHub issues. See PEP 581[1] for the rationale. Ezio Melotti is leading the project, and one may follow the progress on the psf/gh-migration GitHub repo[2] where the work is being managed (including specifically the Projects tab).

Hopefully, that should help make things smoother and more accessible for potential contributors.

[1] https://www.python.org/dev/peps/pep-0581/

[2] https://github.com/psf/gh-migration

I am very much in favor of making contributions easier, but doesn't Github seem short-sighted?

It seems to be veering in a direction of some kind of weird cloud IDE thing, which is fine in and of itself, but what happens if/when it is no longer suitable as a general dev platform?

Python has full and total control over bugs.python.org, whereas Github is a proprietary platform. Might it not be a mistake to cede control over the issue tracker? It seems like the main problem in the article is the CLA-signing process anyway, not BPO.

It’s fantastic that Python is moving to github. It’s so frustrating that projects like django, emacs, python, etc have insisted on using these antiquated development workflows and that some of the old timers even insist that they are better and that github is for “mindless kids who put PRs up thoughtlessly”.

Sounds like you should go and read PEP 581 before criticizing their decision!

I admit I only skimmed the PEP, and I think their rationale is mostly sound. It's a concession to practicality, given the surprisingly limited resources of the Python core development group.

I certainly don't think the problem with GH is that it's for "mindless kids". I hate mailing lists and I hate old-school bug trackers that don't support code markup or rich linking. In the short and medium term, I'm grateful that things will become a lot easier. The long term is what worries me.

But I'm also probably being a bit too cynical. If and when in 5-10 years they want to move off of GH, they will be able to do so. I'm not envisioning some kind of catastrophic "rug pull" from Microsoft where suddenly the Github API disappears and the issue tracker becomes locked-in.

Right, exactly. It's moving to issues and PR-based workflows that's the important thing. If GitHub becomes problematic in the future, they can switch to some other provider of similar functionality, and all the millions of programmers around the world who are familiar with issues and PR-based workflows can follow them.

I am personally someone who only knows PR-based workflows and is somewhat ignorant about other workflows. There are the mailing lists and old-school bug trackers which I am pretty sure I don't like. But I know that several (most/all?) big US tech companies use non-PR-based workflows via tools like Gerrit and Phabricator. I am not at all clear yet on the pros and cons of those workflows versus PRs.

> “mindless kids who put PRs up thoughtlessly”.

Sorry, I wasn't accusing you of holding that position. Some embarrassing idiot on the emacs-devel mailing list said it.

Github isn't setup to stop your from moving your project to other hosting providers. You can export GitHub to other git hosting setups (like a self-hosted GitLab.)

Including the issues?

Yes, and other things, see: https://docs.gitlab.com/ee/user/project/import/github.html

Does github provide a way to redirect the URLs for individual issues to the corresponding issues on a new bugtracker?

Probablu not, but you could probably find or write a script to close all the github issues with a final comment linking to the duplicated issue on the new tracker.

Without meaning to seem hostile, what about comments like this one:

https://news.ycombinator.com/item?id=29837405

Please drop the stupid CLA crap. You don't need it, and you need to fire whatever idiot lawyer told you that you did.

Talking aggressively like this is exactly the reason why we need CLAs.

CLAs are the reason for the harsh language. There's no reason to make contributors create and link a half-dozen accounts and read seven hundred pages of legalese to contribute to your project. It's a real barrier to contributions (see: the linked article), not to mention the time projects waste setting up these broken automated CLA systems, just to justify some lawyer getting a paycheck.

What do comments, aggressive or otherwise, have to do with a licensing agreement?

Are you confusing CLAs with CoCs?

For a one-character typo, I would probably have just reported it as an issue. An issue is sufficient to say what fix is needed, and in some ways it's easier for a maintainer to make such a fix themselves than to verify a change made by an external contributor, correct the commit message, verify their CLA status, etc.

However my experience of reporting Python documentation issues has been frustrating for other reasons. I reported a lack of detail in the multiprocessing.Process.exitcode documentation in October:

    https://bugs.python.org/issue45554

Nearly three months later, no-one has commented on the bug report -- not even to triage it. Fair enough, it is a minor issue, people are overstretched particularly with the current world situation, and perhaps proposed fixes would be of more interest.

So in late November I set about improving this documentation myself. I found the CLA process relatively straightforward, though I was unimpressed that the online signing via Adobe Sign refused to work in an incognito window. Emailing a scanned signed paper form was an effective and straightforwardly handled alternative.

I filed a PR with a proposed documentation improvement in mid December:

    https://github.com/python/cpython/pull/30142

Apart from one drive-by comment from a non-core contributor, no-one has commented on the pull request -- not even to approve running the remaining basic workflows. Also fair enough, it has only been a couple of weeks outside the holiday period, and it is a minor issue.

By now the PR is on page 4 of the cpython repo's list of open PRs, so it is difficult to imagine anyone getting back to it except by accident. The Doc-SIG mailing list appears to be mostly moribund, so doesn't appear to be a good place for a nagging message.

All in all, I'm not feeling encouraged to spend time making what are intended to be useful (albeit minor so far) contributions.

Yep.. i came here to say the same: It's even worse to get past the red tape only to be ignored.

It's even more annoying when you actually submit a patch and the maintainers end up fixing the issue themselves. All that time you spent exploring the project and studying the code to figure out how to do it yourself? Wasted. The people who already know the code and have all the context can fix whatever issue in minutes and in a better way.

It's also very discouraging (and unfair) for new comers not to get credit for that work.

Yeah that happens quite a bit, too.

(I'm a Python core dev, speaking for myself.)

Python is almost entirely developed and maintained by volunteers. The increasing backlog of issues and PRs is recognized as a problem.

Thanks to a generous donation, the PSF has recently begun employing one "developer in residence", Łukasz Langa. He is specifically tasked with tackling this backlog, and has been doing a mighty good job so far.

Still, with over 1,000 open PRs and many times more open issues, we (the Python devs) could use more helping hands. For example, anyone can confirm that bugs reproduce, review PRs, or test fixes, and those are all meaningful help (when done thoughtfully and thoroughly.)

I, and most core devs, volunteer happily and ask for nothing in return. If you think the situation outlined in the parent post isn't great and begs improvement, you're welcome to help!

I agree with everything you say, and alluded to much of it in the parent post. I myself also volunteer happily on a number of projects, and attempt to keep up with similar deluges on those projects.

For someone like myself who is not already a core Python maintainer, how would you recommend making improvements to things like the Python documentation if not by raising pull requests?

For a specific doc fix, a PR is indeed the way to go. If it's not a simple fix, creating an issue on the tracker may also be called for. Doing so does help and is appreciated, even if it sometimes takes a long time to be addressed by a core dev.

Otherwise, one could help in ways like I mentioned previously: reading existing issues, checking if they are still relevant and commenting accordingly, reviewing PRs and patches, etc.

> For a specific doc fix, a PR is indeed the way to go. If it's not a simple fix, creating an issue on the tracker may also be called for.

That is precisely what I did. As noted, there has been no indication (by activity on the issue or PR) that having filed these helped or is appreciated. Hence discouragement.

It is one of the hard lessons of open source maintainership that, without providing feedback to contributors, there is no demonstration of the project's appreciation. Therefore new contributors will (correctly!) conclude that the project does not appreciate these efforts.

I think the key point that you are making is that projects which need more help should place higher priorities on working through PR and issue backlogs as those are a primary way to taking people who are willing to help and converting them into more dedicated and integrated maintainers. Letting those backlogs languish because you don't have enough volunteers becomes a self a reinforcing cycle that becomes harder and harder to break out of.

Don't get me wrong I'm a huge FOSS fan and proponent, but I think your post illustrates very clearly what is wrong with the state of OSS today. We are talking a language like python that probably underpins profits on the order of tens of billions a year and is largely maintained by volunteers in their free time and the foundation can hire one dev! Somehow companies managed to outsource all the work to "the public" while keeping the profits for themselves.

That's the world we live in. Many banks have custom forks of Python and various other tools but they don't care to release their code. Illegal? Sure, but they're banks, they're kind of exempt as companies are.

A while ago someone posted here a post of Cray/HPE complaining to a bunch of volunteers on the GCC Fortran project that F2018 support was incomplete. The GCC team fully acknowledges its incompleteness, and knows that it is in fact, incomplete. It is not recommended for production applications. There are about 10 other compilers, some by companies such as NVIDIA and Intel, which would work perfectly fine and which have full F2018 support. But instead of using any of these, or seeing as the one complaining is on the committee that created the F2018 specification, going out and fixing it yourself, they complained to like 6 people because their government project was falling behind because of their inability to even comprehend that some group of internet communists will not do free work for them.

Literally idiotic. You're a representative one of the world's largest companies when it comes to this kind of stuff and perhaps one of the most knowledgeable people on Fortran alive. Go fix it or stop using beta products by internet communists for government contracts.

I think the entire point of this post is that people do NOT feel welcome to help, and it is being suggested that their experiences are one reason there is such an unmanageable backlog.

I'd love if someone could solve the problem with package management in Python. Make Pip Great Again - faster and more stable than poetry. Something like a kickstarter campaign would work. I'd give you money.

Creating an issue and getting somebody else to check-in the code for you doesn’t give you the same level of bragging-rights feeling as actually creating a PR and getting merged though, regardless of how trivial a fix it is.

I’m not saying that’s what is driving the OP, but I myself would certainly be driven by that to some extent.

I've submitted a few minor PRs (doc changes, typing changes, test fixes, some small features) over the last few years as a non-core developer. To be fair, some changes were reviewed promptly so the problem of reviews taking a long time doesn't necessarily reflect on Python as a whole.

In my experience, typeshed changes were always reviewed promptly and Mariatta reviewed a bunch of simple doc fixes within a couple of days.

Contributing to libraries that didn't have an established owner definitely took longer to get reviewed (even more so for features that only a subset of developers would use). I sent an email on the mailing list to follow up after a while and Guido ended up merging one of the changes. For another PR (to fix a broken test that had been broken for years) a core developer assigned various reviewers, who all unassigned themselves. After a year of no activity, I then followed up directly with a core developer during their office hours and we walked through the review together.

Being a volunteer-run project means that they work on things during their free time, and during my discussion with one of the core developers they highlighted that since Python is volunteer-run, they can't really force anyone to do reviews—people just work on whatever they want, whenever they want. I think that's fair, but it certainly biases away from people who submit a few contributions outside of the core developer group. We also talked about the recommendations in the dev guide about reviewing code as a non-core developer, since it seemed like a sort of chicken and egg problem where people who aren't core developers won't/aren't able to review code. And even if they do, their review isn't necessarily conclusive to getting a change reviewed and approved by a core developer, who likely will just ignore their review (since there's no credibility).

I tried to correct something minor in the HTML spec a couple of years ago <https://github.com/whatwg/html/pull/5156>, but I couldn’t contribute it individually because I happened at the time to be employed by a company that works on the internet. Which, y’know, is probably most of the people that could contribute individually. (The issue did get sorted out eventually <https://github.com/whatwg/sg/issues/62>, relaxing things for most people, though probably not quite for me under the employer I had at the time.)

I understand the annoyance, especially when the fix is just so right there... I also understand the reasons to have a CLA process for FOSS projects.

Yet, in retrospect, I wonder if the OP considered simply reporting the found issue, then moving on with his own priorities?

After all, it's up to the project maintainers to decide how to prioritize/review any issues/contributions.

If the fix is so trivial, it sure could just be applied by any existing project member.

So, reporting an issue should not require a CLA and, indeed, in this case it was just a login away.

Not really in the spirit of open-source, though, is it? Throwing bug reports over the wall feels icky when it should take the same amount of time to send a PR.

Quite the opposite, the fixes should begin with a proper description of a problem. So the issue should get reported first.

As for the fix, well, it's understandable that we developers have a certain degree of ownership and almost self-imposed duty to 'pitch-in', especially when qualified. Yet, in the open-source or not spirit, it should not really matter whether the issue fix was authored by the reporter, as long as the project/product got better.

Sure, it feels appropriate to get one's own effort attributed, and in case of a sizable issue/PR it's very well important to also account the effort that goes into reviewing such contribution.

> Quite the opposite, the fixes should begin with a proper description of a problem. So the issue should get reported first.

Especially for something as trivial as this, I don't see what value a separate issue adds.

If you want to have something to link to e.g. for your release notes, a PR can also do that job.

As an opensource maintainer, if someone opens an issue "Typo in docs" and a PR "Fix typo in docs #12345" five minutes later, I'll just tell them to not bother with the issue next time because that's just more clicking for me.

The key problem is that a PR can't do the job because of the CLA-related difficulties described in the original article - the submitter can make the issue for the trivial change but not make a PR so the expectation is that the actual trivial change would have to be done by someone who has already handled the CLA overhead.

I'm not sure I see the point for a one character typo. If the bug report is just thrown over the fence and this is what is encouraged, then I hope that the project doesn't start saying "please contribute a fix".

If the project does say this, then the answer will be - I want to, but getting privileges to do so are too hard.

There was a thread earlier today about chatbots basically being designed to frustrate customers and get them to go away, and I can't help but suspect that this system has been set up in a similar way.

I suspect a lot of open-source folk would not appreciate this, but in my experience as a maintainer of a small-ish project, the overwhelming majority of contributions are well-intentioned but not very helpful (of course, the few contributions that are extremely helpful more than make the whole process worth it!).

It creates a fairly awkward situation where the maintainer doesn't want to be rude and reject the contributor's work (which they have spent their own time making and are sharing for free), so they reluctantly take time away from solving real issues and validate the patch instead.

I could see how erecting deliberate roadblocks could avoid a lot of this discomfort.

I really doubt it. CLAs are from lawyers being in control, not something programmers would dream up.

I do think something similar about issue templates though, their main function is to give programmers "cover", so they can say "you didn't fill out the template" instead of "the bug report you wrote is garbage".

I'd argue that most people involved in maintaining / setting up that CLA process simply don't have to experience the pain of the new comer. They have their account set up a long time ago and simply don't have to go through that experience.

(Python core dev here.)

At least for the Python project, there are more than enough inherent "roadblocks" for new contributors to overcome. Work is being actively done to remove some of these, or at least make overcoming them easier.

I know that there had been discussion to improve the CLA process for Python but one issue was that previous signed CLA could not be imported so every contributor would have had to sign the CLA again, which for contributors that need approval by their employer’s lawyers can be a multi-month process. Because of this the current process which has been cumbersome has been kept, but I’m sure the discussion can be revived if someone is willing to do the leg work, the migration and figure out the legal implications.

The CLA is also usually not required for trivial fixes like typo but the bot still asks for it, only a maintainer can bypass it and consider whether it is a trivial fix as far as I know.

I don't think the part where signing the CLA is sometimes not necessary is apparent.

Do folks sign CLAs on a whim? It seems unwise to not have a lawyer look them over first, so you know what you're actually giving up (vs what the text says).

Honestly, the process didn't sound _that_ onerous to me...

It’s not, just a bit long when you go through your first contribution. It’s probably 10mn of activity in total.

Though obviously it can feel outsized when trying to fix a typo.

Just waiting for the email can take 20 minutes due to greylisting.

But the thing's you don't have to wait for anything, you can start the process, it tells you to wait for an email, you do something else, when you see the email you resume the process.

Nothing in there is urgent in any way, or blocking, or prevents you from doing other things.

Yes, I agree there's a bit of hyperbole on those tweets (otherwise we wouldn't be discussing it here).

For example:

> But this contributor UX is holding Python back

As in, fixing one character typos?

If he didn't really want to follow the process to contribute, a bug report would have been fine (which is what finally happened, reading the PR).

He ended the PR with "I unfortunately feel that I've already exhausted the amount of energy I can dedicate to this", but he had some energy left to write that twitter thread.

FWIW, I had something similar happen when I contributed to React. A long CLA, a three-line PR (that was marked as a `easy first issue`), and eventually, after month and dozens of comments, a rebased PR that subsumed the issue. There's nothing inherently wrong with this, but it can turn off getting new contributors to your project who may, one day, become your core maintainers.

I'd probably just file a bug for a typo...

Is there a project as important as Python that is much easier than this and could be considered a gold standard?

Rust's contributor experience is amazingly good. I've contributed small fixes to the Rust compiler and there was no CLA to sign or onerous process to follow.

This is the same Python that you can't even use for any projects at all.

Python dependencies break if you even so much as rub two brain cells together wrong. I have wasted weeks of my life trying to get x python library to work with y and I have come to the conclusion that it is impossible. I have no idea how people use this god forsaken programming language. I guess they just keep everything in one monolithic .py file and pray to God that python doesn't do some shit in the background that makes even that fail (which it has done to me).

It's no surprise that this amount of bureaucracy goes on behind the scenes as well. The entire language is held together with duct tape and Van der Waals forces.

I can relate to this. I found a typo in typescript and gave up on reporting it after 30 minutes or so. These complex systems probably save a lot of maintainer time but they do seem to disincentivize the average user from contributing.

At a guess, this is recapitulation of the old adage:

Q: Why can't we have nice things?

A: because then terrible people would take advantage of it.

Signup requirements might have been put in place after bad actors did something?

This is enlightening, I didn’t know the bar was so high to contribute to python. But imagine a scenario where any unverified bot could spam the python devs with small or malicious PRs. I get that the hoops to jump through here are frustrating, but the process makes sure my production code isn’t built on wild west languages and frameworks.

I doubt that anyone designed this process intentionally, or that anyone involved in everyday Python development is consciously aware of it as a process; this sort of mess typically accumulates organically, through a series of individually-reasonable decisions.

It also seems like a pretty typical procedure for a large software project. Let's not fall into the HN trap of "Python/NodeJS does bad thing (that everyone else also does), therefore Python/NodeJS bad, you must switch to Go."

Python is apparently biased against casual contributors. I see nothing inherently wrong with that. Depends on the resources of the team. Your implicit assumption that it’s net beneficial for all projects to accept casual contributions is wrong. If you want to make a one-off change, just open a bug report and move on.

I see bugs all the time in a lot of the software I use daily. Or maybe missing simple features.

On Linux, when also most of the software is open source, and also myself being a developer who can read and write C++, and when the bug is often also quite obvious in the sense that I have a good understanding of what exactly went wrong, and I would be able to easily fix it, I really wish that this process of actually looking at the code and fixing it could be simplified and unified.

Linux (Ubuntu) can easily link a GUI window or binary to the corresponding package, and that can be linked to the source code. So I wish for some button on the window decoration like "open code in editor" or so. This would then check out the code and open some editor. And maybe even attach with a debugger live to the running application.

Then assuming I can identify and fix the bug, I would like to wrap up this fix automatically in some PR which gets send upstream and to Ubuntu.

Of course, there are many details in this idea, which need to be worked out.

E.g. should it just get the source code tar dump, or should it rather clone some Git repo and then checkout the right commit? The latter gives me the flexibility to also switch to the current main branch, or some other version. But then, not all software has a public Git repo.

And when I did some change to the code, how would I build this? Using the Linux package build system? Or just make or whatever make system the software provides? And is it easy to just stop the app and then start my custom compiled version, or does this need further setup? Or would this replace the system installation? For more system relevant packages like Xorg, systemd or so, this is trickier and riskier, but I'm fine to accept any risks, if there is an easy way to just rollback to the official version.

I did various fixes to various software packages along the years, and each time I do this process in a manual way: Making an initial bug report on Ubuntu, searching for the public repo, making an upstream bug report as well, cloning the repo, looking through the code to find the bug or where to implement some missing feature, then figuring out the software build system and setting this up, then the actual implementation, then preparing a patch, and attaching this to the Ubuntu and upstream bug report.

The point is, the actual fix, and also often finding the problem in the code is often just a couple of minutes, maybe needing 2-3 iterations, and then it's done. But all the other things take so much effort, that I keep just ignoring most bugs I see all the time, if they don't annoy me too much. Also, I need to actual get some other work to be done...

Do you mean `apt-get source <package>`? https://www.cyberciti.biz/faq/how-to-get-source-code-of-pack...

Yes this is one thing, but it misses many of the other things I mentioned, e.g. it would not check out the Git repo, not open an editor and automatically attaching a debugger to the running application, not helping me in preparing an upstream patch, bug report, etc. Ideally I want a single button on the app GUI window for this, sth like "edit this code".

Some day when I'm rich and bored, I hope to help a distro move in this direction. It'd be really really cool to have a fully, very easily, debuggable and then fixable system where you could debug any running code on the system, and patch it, and recompile and debug again, and decide you like your change, and then push the change as a PR to the distro, in a streamlined process. The distro (like arch) would then help/encourage/nudge you to sending your patch upstream also.

Ubuntu et al, know where their sources come from after all, and how to build each package. I wonder if Arch or gentoo wouldn't be a better fit for this. I do have quite a bit of experience with yocto and buildroot, building distros for embedded systems.

I'm joking about the rich and bored, part. I should just jump in and do it.

Hang on, I'll just make a small PR porting all Linux desktop software to Smalltalk.

https://threadreaderapp.com/thread/1478782546624360453.html

Sounds like a legalese process that e.g. github could help out with, make a quick and easy flow to read & accept CLAs.

Yeah for contributing one single character fix, this maybe feels a bit of a slog. If you really just cared about that one issue, you’d report a bug and move on. If you wanted to have this be your first of many Python contributions, you likely wouldn’t care about this one-time process being a bit clunky. You would also probably realise that you were making choices that made this CLA signing process a little more difficult. Honestly that “one business day” delay was the only real weird one during the whole process, for me.

Is this such a problematic comment? I’m curious why it’s at -2, I’d thought you need to say something offensive or inflammatory to get that

Maybe there should be a chatroom for tipping off about simple bugs by users who aren't interested/qualified in proper bug reports.

So simple things like "Docs refer to wrong PR number" which can quickly be verified can be passed to someone already prepped and familiar to raise a PR.

I'd structure it so that documentation bugs where separate room from other kinds, and that way you would burden people to supply python version / run env or irrelevant things like that - just ask for a url link to the relevant doc page as mandatory.

Reply on news.ycombinator.com