3 ms·

I think a lot of people treat the merge of a PR as their god-given right. Because they spent time on it. But if they spent the time without discussing with the

by ay 5y ago

I think a lot of people treat the merge of a PR as their god-given right. Because they spent time on it. But if they spent the time without discussing with the maintainer first, why would they be obliged to merge it ? It is like spending a ton of money on a big, bulky, but useless to a recipient present, giving it to someone and then complaining that they don’t take it - you had spent all this money! The way out of this is to be more proactive and discuss first and then get to coding. Oh, and be prepared you would need to code an approach different from what you wanted. And there is absolutely no shame in forking the repo, doing the changes you could not get merged, and keeping it around for your own/your org use. It is all about tradeoffs.

c7DJTLrn 5y ago
>I think a lot of people treat the merge of a PR as their god-given right I've never seen this at work or in open source, and I've done quite a bit of open source. Contributors will get frustrated if their PR is simply ignored and I think for good reason. But I've never seen anyone say or even imply that their PR must be merged.
- elithrar 5y ago
  I have seen this “non-zero” times - not common, but it exists. Some folks are insistent that their PR and their specific problem be addressed by your project, and the effort they put into writing code before discussing it just increases their attachment.
  - ay 5y ago
    The analogy that popped up in my head reading these threads is someone buying expensive and bulky yet useless for the recipient gift and then being upset when it is rejected. “But i paid a lot for it!”
- ay 5y ago
  I am judging it by the comments. I have been on both sides of this situation over the years, but it was never too extreme. On the maintainer side: I have a small project that has picked up some pace recently, though is still rather small, and there has been only two situations where i said “this feature is not going in no matter what”. Because it will increase my burden as a maintainer and main author. On the contributor side: If the maintainer in a timely fashion suggests some changes that seem reasonable, I am happy to spend the time doing them. Often they will give an “outside” view that will make a patch better. Sometimes I saw them being quite selective about what they want to merge, whereas for me “just that bit” solves a real need and I see the request as too much work - then I just leave my fork as is and use that for what I needed. I see their rationale, and I am thankful for what they have done. And I leave my modifications in the fork in case someone needs them or wants to pick them up and improve. The freedom with open source always should go both ways.
- YorickPeterse 5y ago
  I've run into this myself: a contributor submitted a pull request that didn't follow a bunch of guidelines, and the changes they introduced were very different from the rest of the code in the same file. I asked them to keep things consistent with the existing code, and they basically argued "This fixes the problem, so you must merge it".
- whimsicalism 5y ago
  Literally this article?

by ay 5y ago

c7DJTLrn 5y ago

>I think a lot of people treat the merge of a PR as their god-given right I've never seen this at work or in open source, and I've done quite a bit of open source. Contributors will get frustrated if their PR is simply ignored and I think for good reason. But I've never seen anyone say or even imply that their PR must be merged.

elithrar 5y ago
I have seen this “non-zero” times - not common, but it exists. Some folks are insistent that their PR and their specific problem be addressed by your project, and the effort they put into writing code before discussing it just increases their attachment.
- ay 5y ago
  The analogy that popped up in my head reading these threads is someone buying expensive and bulky yet useless for the recipient gift and then being upset when it is rejected. “But i paid a lot for it!”
ay 5y ago
I am judging it by the comments. I have been on both sides of this situation over the years, but it was never too extreme. On the maintainer side: I have a small project that has picked up some pace recently, though is still rather small, and there has been only two situations where i said “this feature is not going in no matter what”. Because it will increase my burden as a maintainer and main author. On the contributor side: If the maintainer in a timely fashion suggests some changes that seem reasonable, I am happy to spend the time doing them. Often they will give an “outside” view that will make a patch better. Sometimes I saw them being quite selective about what they want to merge, whereas for me “just that bit” solves a real need and I see the request as too much work - then I just leave my fork as is and use that for what I needed. I see their rationale, and I am thankful for what they have done. And I leave my modifications in the fork in case someone needs them or wants to pick them up and improve. The freedom with open source always should go both ways.
YorickPeterse 5y ago
I've run into this myself: a contributor submitted a pull request that didn't follow a bunch of guidelines, and the changes they introduced were very different from the rest of the code in the same file. I asked them to keep things consistent with the existing code, and they basically argued "This fixes the problem, so you must merge it".
whimsicalism 5y ago
Literally this article?