6 ms·

But besides the review it is also free code. I don't get this sentiment of disallowing pull requests or issues. Just because one gets bunch of useless issues

by krzyk 6y ago

But besides the review it is also free code. I don't get this sentiment of disallowing pull requests or issues. Just because one gets bunch of useless issues or PRs doesn't mean that he/she won't receive a valuable one. If you close those, you are basically closed-source with an option to peak at the code.

pessimizer 6y ago
> If you close those, you are basically closed-source with an option to peak at the code. No, you are completely open source. FOSS doesn't have anything to do with the right to contribute upstream. It gives you rights over the code, not the servers that house the code.
jabbany 6y ago
This is not the case and the maintainer outlines why. (1) FOSS means you (the "licensee") can do what you want with the code, not that I (the "licenser") am somehow obliged to take your input on it. If the maintainers find that code contributions are reducing their maintenance effort, which is often the case, then sure. But if on the other hand reviewing the contributions themselves _increases_ effort, then it literally is a net-negative to accept PRs. (2) It's also very possible that PRs create extra work. Sometimes reading and understanding someone else's solution to a problem is harder than coming up with your own! Of course, one could take a laissez faire approach to maintenance and just assume good intent and do light reviews, but that doesn't necessarily make for a better codebase.
jeroenhd 6y ago
Reviewing, testing and maintaining code takes up development time that could be used more productively. If there's something wrong with the PR (say, code style issues or mistakes) then you need to run through the cycle all over again. The project is open source in that you're free to use it, sell it and go through its code. Open source does not, however, imply that someone must put in the work for you if you want to apply changes to the code yourself. If you'd like a version of the project that takes pull requests, then you can always create a fork that accepts pull requests and comments. This puts the burden go testing, merging and quality control on you, but most of the work you'll be doing is what you're expecting the developers of a product to do for you anyway. If your energy pays off and your fork has less bugs, more features and becomes more popular, the original developers may turn around and cooperate with you instead.
- krzyk 6y ago
  > Reviewing, testing and maintaining code takes up development time that could be used more productively. If there's something wrong with the PR (say, code style issues or mistakes) then you need to run through the cycle all over again. OK, so your argument here is that maintainer doesn't want to create CI checks because it takes time and he knows the code style and doesn't need those. > The project is open source in that you're free to use it, sell it and go through its code. Open source does not, however, imply that someone must put in the work for you if you want to apply changes to the code yourself. But why close yourself to others? It is like throwing mic, or as if you would mark this thread as closed and no one would be allowed to comment - antisocial behavior. You don't need to merge PRs, but come one, if you are a sole maintainer of a project, this project is not that big, and you for sure aren't getting that many PRs. And also, one could consider PRs because you could find another person that understands your project goals and would be your co-maintainer. Why such strange attitude here on HN? I found this place as very open and what I see in this thread praising of close-minded people. Most projects seek contributors not alienate them.
  - ozim 6y ago
    For me it is open-closed principle I am open to hearing people but I am closed to including their work into mine unless I feel like it. Notice that it is "mine" work not theirs. Whole discussion here is about toxic behavior of people whose PR's are closed. It is not about closing yourself to contributions, idea is that everyone can still make a feature requests. One can still propose changes but there should be less pressure on integrating piece of code on maintainer, option to remove PR's on repo would do that. I see why GH would not consider option to disable PR's because it is a killer feature of GH and it would be bad for their marketing when a lot of repositories would become 'read-only'.
    - Aeolun 6y ago
      Yeah, having that feature would prevent a lot of misunderstandings. I’m absolutely open to that (also so I don’t waste time creating PR’s).
mschuetz 6y ago
Reviewing and testing multiple PRs is an enormous amount of work for anything but the most simple one liner changes.
- bacongobbler 6y ago
  To be fair, simple one-liner changes can be just as impactful as an entire package rewrite. I've reviewed a few one-liners that seemed innocent at the time, but had massive impact downstream. As the project and the userbase grows, small conditional changes can be the most difficult to test because they require a very specific setup to test and verify. Often times the only person that can reproduce the issue is the person submitting the PR.
UncleMeat 6y ago
Code is never free. Code that exists in a project continuously costs energy in maintenance. This is why deleting code is valuable.
- krzyk 6y ago
  PR is not always about adding code.
  - UncleMeat 6y ago
    If the argument is "well, the PR comes with free code so you should be thankful" then a PR that deletes code or whatever isn't super relevant.
    - krzyk 6y ago
      OK, for me code = diff, it can add lines and it can remove lines. My point is that one shouldn't be close minded on others. Disalowwing PRs is just like closing your ears because you don't want to hear the other person arguments - IRL you avoid such peoples, in virtual one you should avoid them too.
      - UncleMeat 6y ago
        Why is this an unacceptable choice? Yes, accepting PRs from the broader community and spending time on them has a good chance of making the product superior over time. But just like how it is probably good for me to understand the impact of my purchasing choices on the environment, I can't listen to it all the time. I don't think it is unreasonable to say "in this context, I do not have the bandwidth to manage unsolicited advice from others". That isn't "being close minded". It isn't saying that nobody else has good ideas. It is saying that you are busy right now.
jrochkind1 6y ago
> If you close those, you are basically closed-source with an option to peak at the code. Oh no. Closed-source with an option to peak the code does exist. This is not it. Because it is licensed GPL. Which means you have the option to copy the code into your own project. In whole, or just looking at particular parts that are useful. You have the option to fork it and do whatever you want to it. If you got some people together that thought "gee, we like this, but we wish it took PR requests", you are legally allowed to copy the code into a different project (ie fork it) that takes PR requests, and become the maintainers of that project. This is *HUGE*. You can't do that with closed source even if they let you see the code. There is a very big difference between "closed source that lets you see the code" (which does exist, but this isn't it) and "open source". And it's not whether they take PR's -- closed source can take PR's too. The a proprietary company will let you volunteer your time to submit improvements to their code does not make it open source. It's about who (if anyone) controls the code and can decide who is allowed to use it or not, not just see it.It's about the license. It is important that we as developers and decision-makers about what code to use understand this difference.

by krzyk 6y ago

pessimizer 6y ago

> If you close those, you are basically closed-source with an option to peak at the code. No, you are completely open source. FOSS doesn't have anything to do with the right to contribute upstream. It gives you rights over the code, not the servers that house the code.

jabbany 6y ago

This is not the case and the maintainer outlines why. (1) FOSS means you (the "licensee") can do what you want with the code, not that I (the "licenser") am somehow obliged to take your input on it. If the maintainers find that code contributions are reducing their maintenance effort, which is often the case, then sure. But if on the other hand reviewing the contributions themselves _increases_ effort, then it literally is a net-negative to accept PRs. (2) It's also very possible that PRs create extra work. Sometimes reading and understanding someone else's solution to a problem is harder than coming up with your own! Of course, one could take a laissez faire approach to maintenance and just assume good intent and do light reviews, but that doesn't necessarily make for a better codebase.

jeroenhd 6y ago

Reviewing, testing and maintaining code takes up development time that could be used more productively. If there's something wrong with the PR (say, code style issues or mistakes) then you need to run through the cycle all over again. The project is open source in that you're free to use it, sell it and go through its code. Open source does not, however, imply that someone must put in the work for you if you want to apply changes to the code yourself. If you'd like a version of the project that takes pull requests, then you can always create a fork that accepts pull requests and comments. This puts the burden go testing, merging and quality control on you, but most of the work you'll be doing is what you're expecting the developers of a product to do for you anyway. If your energy pays off and your fork has less bugs, more features and becomes more popular, the original developers may turn around and cooperate with you instead.

krzyk 6y ago
> Reviewing, testing and maintaining code takes up development time that could be used more productively. If there's something wrong with the PR (say, code style issues or mistakes) then you need to run through the cycle all over again. OK, so your argument here is that maintainer doesn't want to create CI checks because it takes time and he knows the code style and doesn't need those. > The project is open source in that you're free to use it, sell it and go through its code. Open source does not, however, imply that someone must put in the work for you if you want to apply changes to the code yourself. But why close yourself to others? It is like throwing mic, or as if you would mark this thread as closed and no one would be allowed to comment - antisocial behavior. You don't need to merge PRs, but come one, if you are a sole maintainer of a project, this project is not that big, and you for sure aren't getting that many PRs. And also, one could consider PRs because you could find another person that understands your project goals and would be your co-maintainer. Why such strange attitude here on HN? I found this place as very open and what I see in this thread praising of close-minded people. Most projects seek contributors not alienate them.
- ozim 6y ago
  For me it is open-closed principle I am open to hearing people but I am closed to including their work into mine unless I feel like it. Notice that it is "mine" work not theirs. Whole discussion here is about toxic behavior of people whose PR's are closed. It is not about closing yourself to contributions, idea is that everyone can still make a feature requests. One can still propose changes but there should be less pressure on integrating piece of code on maintainer, option to remove PR's on repo would do that. I see why GH would not consider option to disable PR's because it is a killer feature of GH and it would be bad for their marketing when a lot of repositories would become 'read-only'.
  - Aeolun 6y ago
    Yeah, having that feature would prevent a lot of misunderstandings. I’m absolutely open to that (also so I don’t waste time creating PR’s).

mschuetz 6y ago

Reviewing and testing multiple PRs is an enormous amount of work for anything but the most simple one liner changes.

bacongobbler 6y ago
To be fair, simple one-liner changes can be just as impactful as an entire package rewrite. I've reviewed a few one-liners that seemed innocent at the time, but had massive impact downstream. As the project and the userbase grows, small conditional changes can be the most difficult to test because they require a very specific setup to test and verify. Often times the only person that can reproduce the issue is the person submitting the PR.

UncleMeat 6y ago

Code is never free. Code that exists in a project continuously costs energy in maintenance. This is why deleting code is valuable.

krzyk 6y ago
PR is not always about adding code.
- UncleMeat 6y ago
  If the argument is "well, the PR comes with free code so you should be thankful" then a PR that deletes code or whatever isn't super relevant.
  - krzyk 6y ago
    OK, for me code = diff, it can add lines and it can remove lines. My point is that one shouldn't be close minded on others. Disalowwing PRs is just like closing your ears because you don't want to hear the other person arguments - IRL you avoid such peoples, in virtual one you should avoid them too.
    - UncleMeat 6y ago
      Why is this an unacceptable choice? Yes, accepting PRs from the broader community and spending time on them has a good chance of making the product superior over time. But just like how it is probably good for me to understand the impact of my purchasing choices on the environment, I can't listen to it all the time. I don't think it is unreasonable to say "in this context, I do not have the bandwidth to manage unsolicited advice from others". That isn't "being close minded". It isn't saying that nobody else has good ideas. It is saying that you are busy right now.

jrochkind1 6y ago

> If you close those, you are basically closed-source with an option to peak at the code. Oh no. Closed-source with an option to peak the code does exist. This is not it. Because it is licensed GPL. Which means you have the option to copy the code into your own project. In whole, or just looking at particular parts that are useful. You have the option to fork it and do whatever you want to it. If you got some people together that thought "gee, we like this, but we wish it took PR requests", you are legally allowed to copy the code into a different project (ie fork it) that takes PR requests, and become the maintainers of that project. This is *HUGE*. You can't do that with closed source even if they let you see the code. There is a very big difference between "closed source that lets you see the code" (which does exist, but this isn't it) and "open source". And it's not whether they take PR's -- closed source can take PR's too. The a proprietary company will let you volunteer your time to submit improvements to their code does not make it open source. It's about who (if anyone) controls the code and can decide who is allowed to use it or not, not just see it.It's about the license. It is important that we as developers and decision-makers about what code to use understand this difference.