12 ms·

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

209 points by obi1kenobi 5y ago

albertzeyer 5y ago
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...
- Sander_Marechal 5y ago
  Do you mean `apt-get source <package>`? https://www.cyberciti.biz/faq/how-to-get-source-code-of-package-using-the-apt-command-on-debian-or-ubuntu/ https://www.cyberciti.biz/faq/how-to-get-source-code-of-pack...
  - albertzeyer 5y ago
    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".
    - therealjumbo 5y ago
      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.
- dmurray 5y ago
  Hang on, I'll just make a small PR porting all Linux desktop software to Smalltalk.
Cthulhu_ 5y ago
Sounds like a legalese process that e.g. github could help out with, make a quick and easy flow to read & accept CLAs.
deleted 5y ago
[deleted]
mdaniel 5y ago
https://threadreaderapp.com/thread/1478782546624360453.html https://threadreaderapp.com/thread/1478782546624360453.html
theHIDninja 5y ago
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.
cozzyd 5y ago
I'd probably just file a bug for a typo...
jamesboehmer 5y ago
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.
- marssaxman 5y ago
  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.
- nerdponx 5y ago
  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."
l0b0 5y ago
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.
- JoeAltmaier 5y ago
  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.
- faizshah 5y ago
  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.
- hsbauauvhabzb 5y ago
  You mean like putty only being served over HTTP until like 2019?
  - cblconfederate 5y ago
boffinism 5y ago
Honestly, the process didn't sound _that_ onerous to me...
- masklinn 5y ago
  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.
  - Tepix 5y ago
    Just waiting for the email can take 20 minutes due to greylisting.
    - masklinn 5y ago
      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.
- reidrac 5y ago
  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.
  - ghayes 5y ago
    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.
notreallyserio 5y ago
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).
smcl 5y ago
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.
- smcl 5y ago
  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
- Chris2048 5y ago
  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.
chrismorgan 5y ago
I tried to correct something minor in the HTML spec a couple of years ago <https://github.com/whatwg/html/pull/5156 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 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.)
CyberRabbi 5y ago
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.
Znafon 5y ago
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.
- sshine 5y ago
  I don't think the part where signing the CLA is sometimes not necessary is apparent.
AussieWog93 5y ago
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.
- jlengrand 5y ago
  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.
- edflsafoiewq 5y ago
  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".
- taleinat 5y ago
  (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.
zoomablemind 5y ago
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.
- swiftcoder 5y ago
  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.
  - zoomablemind 5y ago
    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.
    - faho 5y ago
      > 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.
lancebeet 5y ago
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.
taleinat 5y ago
(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/ https://www.python.org/dev/peps/pep-0581/ [2] https://github.com/psf/gh-migration https://github.com/psf/gh-migration
- coldpie 5y ago
  Please drop the stupid CLA crap. You don't need it, and you need to fire whatever idiot lawyer told you that you did.
  - simlevesque 5y ago
    Talking aggressively like this is exactly the reason why we need CLAs.
    - coldpie 5y ago
      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.
    - yjftsjthsd-h 5y ago
      What do comments, aggressive or otherwise, have to do with a licensing agreement?
      - deleted 5y ago
        [deleted]
    - 5y ago
jomar 5y ago
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.
- k_sze 5y ago
  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.
- karlding 5y ago
  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).
globular-toast 5y ago
Is there a project as important as Python that is much easier than this and could be considered a gold standard?
- obi1kenobi 5y ago
  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.
SideburnsOfDoom 5y ago
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?

209 points by obi1kenobi 5y ago

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...

Sander_Marechal 5y ago
Do you mean `apt-get source <package>`? https://www.cyberciti.biz/faq/how-to-get-source-code-of-package-using-the-apt-command-on-debian-or-ubuntu/ https://www.cyberciti.biz/faq/how-to-get-source-code-of-pack...
- albertzeyer 5y ago
  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".
  - therealjumbo 5y ago
    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.
dmurray 5y ago
Hang on, I'll just make a small PR porting all Linux desktop software to Smalltalk.

Cthulhu_ 5y ago

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

deleted 5y ago

[deleted]

mdaniel 5y ago

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

theHIDninja 5y ago

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.

cozzyd 5y ago

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

jamesboehmer 5y ago

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.

marssaxman 5y ago
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.
nerdponx 5y ago
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."

l0b0 5y ago

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.

JoeAltmaier 5y ago
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.
faizshah 5y ago
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.
hsbauauvhabzb 5y ago
You mean like putty only being served over HTTP until like 2019?
- cblconfederate 5y ago

boffinism 5y ago

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

masklinn 5y ago
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.
- Tepix 5y ago
  Just waiting for the email can take 20 minutes due to greylisting.
  - masklinn 5y ago
    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.
reidrac 5y ago
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.
- ghayes 5y ago
  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.

notreallyserio 5y ago

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).

smcl 5y ago

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.

smcl 5y ago
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
Chris2048 5y ago
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.

chrismorgan 5y ago

I tried to correct something minor in the HTML spec a couple of years ago <https://github.com/whatwg/html/pull/5156 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 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.)

CyberRabbi 5y ago

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.

Znafon 5y ago

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.

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

AussieWog93 5y ago

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.

jlengrand 5y ago
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.
edflsafoiewq 5y ago
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".
taleinat 5y ago
(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.

zoomablemind 5y ago

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.

swiftcoder 5y ago
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.
- zoomablemind 5y ago
  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.
  - faho 5y ago
    > 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.

lancebeet 5y ago

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.

taleinat 5y ago

(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/ https://www.python.org/dev/peps/pep-0581/ [2] https://github.com/psf/gh-migration https://github.com/psf/gh-migration

coldpie 5y ago
Please drop the stupid CLA crap. You don't need it, and you need to fire whatever idiot lawyer told you that you did.
- simlevesque 5y ago
  Talking aggressively like this is exactly the reason why we need CLAs.
  - coldpie 5y ago
    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.
  - yjftsjthsd-h 5y ago
    What do comments, aggressive or otherwise, have to do with a licensing agreement?
    - deleted 5y ago
      [deleted]
  - 5y ago

jomar 5y ago

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.

k_sze 5y ago
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.
karlding 5y ago
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).

globular-toast 5y ago

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

obi1kenobi 5y ago
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.

SideburnsOfDoom 5y ago

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?