6 ms·

> Github really needs to allow people to disable the "Pull Request" tab on repos, to reduce the stigma around not accepting pull requests. I'm not the one to d

> Github really needs to allow people to disable the "Pull Request" tab on repos, to reduce the stigma around not accepting pull requests. I'm not the one to defend GitHub, but what's the big deal about not accepting pull requests? If you clearly state that you won't accept PRs and somebody still sends them, then you can close them right away and problem solved. Am I missing anything? Another issue is that the github pull request model is not very "gitonic". There are much saner systems like sourcehut.

darkwater 6y ago
> Am I missing anything? Yes. The "reduce the stigma" part. Having users open a PR to just get it automatically closed by a bot (which also needs to be set up) it's far less welcoming than NOT having at all a "Pull requests" tab where you can open said PR.
- enriquto 6y ago
  > it's far less welcoming Oh please, only somebody with a ridiculously thin skin would be offended by seeing rejected his PR to a project that clearly states that does not welcome outside contributions.
  - onion2k 6y ago
    only somebody with a ridiculously thin skin... People like that are very common and often very vocal.
  - DangitBobby 6y ago
    Depends on how much work they put in, doesn't it?
    - tombot 6y ago
      Surely someone invested enough to submit a PR would have read the readme which explains they won’t accept a PR
      - folkrav 6y ago
        Reading stories from open-source maintainers, I have 0 difficulty believing many would not.
      - qhwudbebd 6y ago
        I really wish that were true!
  - afarrell 6y ago
    You are free to disbelieve the answer, but it still stands.
  - gregoriol 6y ago
    The other day I opened an issue on a project to mention that the project is not respecting some powerful convention (by dumping stuff when the user's configuration is to not dump stuff), and the project maintainer replied by saying that he doesn't care... that he thinks his choice is better. I'm quite angry because I spent time investigating this problem and now it won't be fixed and it is not logical and I've lost my time.
    - jerf 6y ago
      Don't underestimate that "fork" button. If the software otherwise does what you want, but you need some particular change, fork away. Obviously one needs to be judicious with this, but I've scored some big wins from this. In addition to bypassing projects who don't want to accept the (IMHO) perfectly reasonable contributions, I've also some cases where the upstream project shouldn't accept my changes and I shouldn't submit them. I've got one case where I forked a package and essentially twisted it so hard that it destroys it for its original purpose, even though it now does exactly what I need. A couple of others where the upstream is obviously dead. Another case I can think of where in principle the upstream could accept it, but it adds a subtle and easy-to-misuse feature to the package that I understand fairly well having written it, but would really encourage users to mess themselves up and is hard to document properly, so I probably won't ever submit it. It's not something I do all the time by any means... the above paragraph describes nearly all the cases where I've done it. It's 3 or 4 in as many years. But each of them was a fairly large win.
      - MaxBarraclough 6y ago
        > If the software otherwise does what you want, but you need some particular change, fork away. You'll then have to maintain the fork, re-applying your changes whenever the upstream repo is updated
        dialamac 6y ago
        Microsoft or Oracle will be glad to sell you something then. Geeze the babies around here.. not every project maintainer is going to agree with you as was apparently the crux of the original complaint. You don’t always get your way. And Apparently just having the ability to fork the source and do whatever the fuck you want is not enough for these pratts.
  - deleted 6y ago
    [deleted]
- alkonaut 6y ago
  Most projects should have a readme and most readme's on github should have a constributing section that everyone hopefully reads before creating a PR. Failing to do so tbh means that person probably failed to comply with coding standards or whatever else is in there. It's just as likely to have the PR closed for those reasons as for the reason "No PR's please". That said, I agree with the idea of simply removing the possibility to make external PR's. The possibility to view (internal) PR's must be there though, so that external viewers can see PRs from the mainainer(s).
  - TheRealPomax 6y ago
    You can't enforce a readme. If it says "PRs are not accepted", and you create a pull request template that says "please be aware your PR will get closed automatically", folks will still file PRs in the hopes that their work is special enough to consider, and they still get their hopes crushed when that their PR gets closed without ever having been looked at.
    - filmgirlcw 6y ago
      If someone either willfully or through purposeful negligence both doesn’t read a README or PR template that outline PRs aren’t welcome and submits a PR hoping against hope for a different outcome, I think we can assume that absolutely nothing will prevent them from having their hopes crushed. I don’t think optimizing for that edge case makes a ton of sense. Having the ability to hide PRs might be a nice feature, but some people use that for stuff other than straight pull requests.
      - TheRealPomax 6y ago
        Then maybe those folks should get a better feature for that, too. More than one thing can be suboptimal about the same feature-as-implemented.
        filmgirlcw 6y ago
        Totally valid, and I'm not opposed to an option to turn it off, I was just saying I can understand why some people might need to keep it on, even if they do have a README and PR template that makes it clear they don't accept PRs. I just think the "crushing the hopes of people that don't read" aspect is probably the lowest priority in that sort of situation.
- Elhana 6y ago
  Why not just leave them open for some other people who might find them useful, but never accepting them?
  - gus_massa 6y ago
    Ten year later someone will post it here, as a proof that the maintainer of the project is not doing his/her "job". Also, I remember a case where after some time someone decided that since the maintainer was not answering, it was fine to add insults and threats.
    - tshaddox 6y ago
      Surely having a disabled or hidden pull request button is also very solid proof that the maintainer is not accepting pull requests.
rectang 6y ago
> Am I missing anything? In order to keep the IP for a project pristine (for the sake of downstream users), I would prefer never to see somebody else's copyrighted solution to a problem. If I see their contribution but I don't want to accept it, I'm forced to come up with a new creative solution that a court would (maybe, hopefully) consider original. This is especially important for CC0/public-domain projects, where many contributors will not fully understand the implications of contributing and may not be in a position to release code into the public domain.
- enriquto 6y ago
  > I would prefer never to see somebody else's copyrighted solution to an issue You are doomed, then. They can always sent a (unrequested) email to you, Cc'd to a public mailing list. The PR interface is just another equivalent way for people to send messages to you, like email.
  - rectang 6y ago
    Somebody's really going to have to go out of their way to email a patch — they might even read the `CONTRIBUTING` document which says "Thanks but no!". The Github Pull Request interface is an attractive nuisance, like an unfenced swimming pool. You can't keep people out with warning signs, they won't read them. Put up a fence, though, and even the obtuse will get discouraged.
Stratoscope 6y ago
> Another issue is that the github pull request model is not very "gitonic". There are much saner systems like sourcehut. That is an interesting observation. Can you elaborate on what you mean? Thanks!
- bmn__ 6y ago
  Read https://blog.brixit.nl/git-email-flow-versus-github-flow/ https://blog.brixit.nl/git-email-flow-versus-github-flow/ and lots of articles by ddevault/sircmpwn about git-send-email on various discussion boards including HN.
kelnos 6y ago
> * If you clearly state that you won't accept PRs and somebody still sends them, then you can close them right away and problem solved. Am I missing anything?* I don't want to have to set up an auto-close bot when I should be able to just untick a checkbox in the project's settings. I don't want to have to click through PR notifications and manually close them when I should be able to just untick a checkbox in the project's settings.

darkwater 6y ago

> Am I missing anything? Yes. The "reduce the stigma" part. Having users open a PR to just get it automatically closed by a bot (which also needs to be set up) it's far less welcoming than NOT having at all a "Pull requests" tab where you can open said PR.

enriquto 6y ago
> it's far less welcoming Oh please, only somebody with a ridiculously thin skin would be offended by seeing rejected his PR to a project that clearly states that does not welcome outside contributions.
- onion2k 6y ago
  only somebody with a ridiculously thin skin... People like that are very common and often very vocal.
- DangitBobby 6y ago
  Depends on how much work they put in, doesn't it?
  - tombot 6y ago
    Surely someone invested enough to submit a PR would have read the readme which explains they won’t accept a PR
    - folkrav 6y ago
      Reading stories from open-source maintainers, I have 0 difficulty believing many would not.
    - qhwudbebd 6y ago
      I really wish that were true!
- afarrell 6y ago
  You are free to disbelieve the answer, but it still stands.
- gregoriol 6y ago
  The other day I opened an issue on a project to mention that the project is not respecting some powerful convention (by dumping stuff when the user's configuration is to not dump stuff), and the project maintainer replied by saying that he doesn't care... that he thinks his choice is better. I'm quite angry because I spent time investigating this problem and now it won't be fixed and it is not logical and I've lost my time.
  - jerf 6y ago
    Don't underestimate that "fork" button. If the software otherwise does what you want, but you need some particular change, fork away. Obviously one needs to be judicious with this, but I've scored some big wins from this. In addition to bypassing projects who don't want to accept the (IMHO) perfectly reasonable contributions, I've also some cases where the upstream project shouldn't accept my changes and I shouldn't submit them. I've got one case where I forked a package and essentially twisted it so hard that it destroys it for its original purpose, even though it now does exactly what I need. A couple of others where the upstream is obviously dead. Another case I can think of where in principle the upstream could accept it, but it adds a subtle and easy-to-misuse feature to the package that I understand fairly well having written it, but would really encourage users to mess themselves up and is hard to document properly, so I probably won't ever submit it. It's not something I do all the time by any means... the above paragraph describes nearly all the cases where I've done it. It's 3 or 4 in as many years. But each of them was a fairly large win.
    - MaxBarraclough 6y ago
      > If the software otherwise does what you want, but you need some particular change, fork away. You'll then have to maintain the fork, re-applying your changes whenever the upstream repo is updated
      - dialamac 6y ago
        Microsoft or Oracle will be glad to sell you something then. Geeze the babies around here.. not every project maintainer is going to agree with you as was apparently the crux of the original complaint. You don’t always get your way. And Apparently just having the ability to fork the source and do whatever the fuck you want is not enough for these pratts.
- deleted 6y ago
  [deleted]
alkonaut 6y ago
Most projects should have a readme and most readme's on github should have a constributing section that everyone hopefully reads before creating a PR. Failing to do so tbh means that person probably failed to comply with coding standards or whatever else is in there. It's just as likely to have the PR closed for those reasons as for the reason "No PR's please". That said, I agree with the idea of simply removing the possibility to make external PR's. The possibility to view (internal) PR's must be there though, so that external viewers can see PRs from the mainainer(s).
- TheRealPomax 6y ago
  You can't enforce a readme. If it says "PRs are not accepted", and you create a pull request template that says "please be aware your PR will get closed automatically", folks will still file PRs in the hopes that their work is special enough to consider, and they still get their hopes crushed when that their PR gets closed without ever having been looked at.
  - filmgirlcw 6y ago
    If someone either willfully or through purposeful negligence both doesn’t read a README or PR template that outline PRs aren’t welcome and submits a PR hoping against hope for a different outcome, I think we can assume that absolutely nothing will prevent them from having their hopes crushed. I don’t think optimizing for that edge case makes a ton of sense. Having the ability to hide PRs might be a nice feature, but some people use that for stuff other than straight pull requests.
    - TheRealPomax 6y ago
      Then maybe those folks should get a better feature for that, too. More than one thing can be suboptimal about the same feature-as-implemented.
      - filmgirlcw 6y ago
        Totally valid, and I'm not opposed to an option to turn it off, I was just saying I can understand why some people might need to keep it on, even if they do have a README and PR template that makes it clear they don't accept PRs. I just think the "crushing the hopes of people that don't read" aspect is probably the lowest priority in that sort of situation.
Elhana 6y ago
Why not just leave them open for some other people who might find them useful, but never accepting them?
- gus_massa 6y ago
  Ten year later someone will post it here, as a proof that the maintainer of the project is not doing his/her "job". Also, I remember a case where after some time someone decided that since the maintainer was not answering, it was fine to add insults and threats.
  - tshaddox 6y ago
    Surely having a disabled or hidden pull request button is also very solid proof that the maintainer is not accepting pull requests.

rectang 6y ago

> Am I missing anything? In order to keep the IP for a project pristine (for the sake of downstream users), I would prefer never to see somebody else's copyrighted solution to a problem. If I see their contribution but I don't want to accept it, I'm forced to come up with a new creative solution that a court would (maybe, hopefully) consider original. This is especially important for CC0/public-domain projects, where many contributors will not fully understand the implications of contributing and may not be in a position to release code into the public domain.

enriquto 6y ago
> I would prefer never to see somebody else's copyrighted solution to an issue You are doomed, then. They can always sent a (unrequested) email to you, Cc'd to a public mailing list. The PR interface is just another equivalent way for people to send messages to you, like email.
- rectang 6y ago
  Somebody's really going to have to go out of their way to email a patch — they might even read the `CONTRIBUTING` document which says "Thanks but no!". The Github Pull Request interface is an attractive nuisance, like an unfenced swimming pool. You can't keep people out with warning signs, they won't read them. Put up a fence, though, and even the obtuse will get discouraged.

Stratoscope 6y ago

> Another issue is that the github pull request model is not very "gitonic". There are much saner systems like sourcehut. That is an interesting observation. Can you elaborate on what you mean? Thanks!

bmn__ 6y ago
Read https://blog.brixit.nl/git-email-flow-versus-github-flow/ https://blog.brixit.nl/git-email-flow-versus-github-flow/ and lots of articles by ddevault/sircmpwn about git-send-email on various discussion boards including HN.

kelnos 6y ago

> * If you clearly state that you won't accept PRs and somebody still sends them, then you can close them right away and problem solved. Am I missing anything?* I don't want to have to set up an auto-close bot when I should be able to just untick a checkbox in the project's settings. I don't want to have to click through PR notifications and manually close them when I should be able to just untick a checkbox in the project's settings.