7 ms·

I had a conversation with my coworkers when I worked there about being upfront with folks that we wouldn't review or accept their PR and stop leaving people han

I had a conversation with my coworkers when I worked there about being upfront with folks that we wouldn't review or accept their PR and stop leaving people hanging (this was on the TFE provider). I'm glad this was added. I stand by my statement then and now: there is nothing worse than contributing to something open source and then have your PR completely ignored.

jdavis703 5y ago
I’ve made PRs because I need the change for my day job. By the time I’ve traced an issue down to a third party library the cost of making a PR is minimal. But if they don’t want to take the changes, it doesn’t bother me. Of course I don’t work on open source out of passion, so I could imagine this is different for the true believers.
- mrtweetyhack 5y ago
  If you spent the time and effort to hunt down the problem for them, the least they could do is look into it. repos that don't care enough are a waste of time.
  - makeitdouble 5y ago
    TBF, even if your PR solves an actual issue a number of users have, it still might not be a good fit for the project's future, and starting a discussion about it might not be worth anyone's time. More importantly, as you disclosed your solution, other affected by the issue can rely on your code in the meantime (= the rest of the project's life in some cases. I've been there). If it really is a critical issue that isn't solved, your fix can always be used in a different fork with better maintenance. All in all, the upstream repo not responding to a PR isn't the end of the world I think, and the openness of the system makes it an acceptable state in many ways IMHO.
- mwaitjmp 5y ago
  Out of interest then how do you proceed? Do you fork the code and run your own patched version?
  - jdavis703 5y ago
    Yes, just use our own forked version.
    - arthurcolle 5y ago
      So then when your upstream repo diverges would you just rebase and manually add in anything you want from the forked development tree on the upstream side? Not sure what's best practice so... just curious how people have handled this - I usually leave my forks of stuff pretty stale and focus on my own little sub-pieces to achieve what I want but not too much else.
      - rad_gruchalski 5y ago
        I usually have my own branch which can be used to get a diff and maintain the diff on any major code structure change. Most often there is not much hassle but can be annoying.
      - dharmab 5y ago
        Yes, we would branch from upstream again and apply the patch set against the new branch. Normally it is trivial but once in a while there are manual changes necessary.
      - acidbaseextract 5y ago
        Maintaining the fork as a stack of patches using something like Stacked Git can make it a little easier than rebasing: https://stacked-git.github.io/ https://stacked-git.github.io/
    - don-code 5y ago
      I do this. I wish I didn't. First of all, building a provider isn't straightforward. The best way I've found to do this is to wrap `terraform init`, and have it `docker run` a build process for a plugin version that never existed - then dumping the built provider into the `.terraform` directory for the project. It's prone to failure; new users of the Terraform project complain that the build eats 8GB of RAM and takes many minutes. Second, providers are constantly changing, and it's not always possible to cleanly rebase a set of community changes on top of master. Part of the trouble with letting PRs wither on the vine is that they themselves become stale - in one case, the code still compiles, but the end result is completely wrong. For what it's worth: my use case was needing to use Terraform with some more "unusual" features of CloudFront and ALBs. The 80% use case for support is great. There's a remaining 15% that's well implemented by unmerged PRs, and another 5% entirely that's completely unsuppored. I've kept it IaC by using the `null_resource` provisioner to shell out to the AWS CLI where absolutely necessary.
qbasic_forever 5y ago
I don't understand why people think that just doing unsolicitied work and pressing a button means the people on the other side are obligated to spend time reviewing and integrating it. GitHub has weirdly unbalanced open source contributions with a heavier burden and burnout on maintainers. Contributing to a project doesn't mean just slinging code and calling it good. Communicate--talk to the people maintaining the code. Ask them, hey I have an idea and want to add this feature/fix this bug/etc.--do you have bandwidth for that change? Mailing lists, discussion forums, chat rooms, e-mails, etc. are the place to sort this out, not snarky or even angrier and angrier replies to an unsolicited pull request that goes unreviewed.
- leetrout 5y ago
  To be explicit: I agree. But I still think it's basic decency to close the PR and tell them No. Or if you plan to leave it around make a comment to that effect.
  - geerlingguy 5y ago
    There are many projects where just doing that would be the equivalent of a full time position. Even saying no requires a skilled review.
    - amyjess 5y ago
      Is there no way to just have a script add a comment on every new PR saying "Due to insufficient staff, your PR may not be reviewed for a considerable amount of time."?
      - tmp538394722 5y ago
        Your code is important to us. Please stay on the line, and the next available reviewer will answer your code. Due to unusually high code volumes, this response may take longer than usual. Something like that?
sergiotapia 5y ago
I disagree, when someone opens a PR on my project it's an imposition of my time. I appreciate the help but I will review when I have time and feel like it's a good time to do it.
junon 5y ago
> I stand by my statement then and now: there is nothing worse than contributing to something open source and then have your PR completely ignored Really? Nothing worse?
- raffraffraff 5y ago
  Jock itch is pretty bad. Might even be worse.

jdavis703 5y ago

I’ve made PRs because I need the change for my day job. By the time I’ve traced an issue down to a third party library the cost of making a PR is minimal. But if they don’t want to take the changes, it doesn’t bother me. Of course I don’t work on open source out of passion, so I could imagine this is different for the true believers.

mrtweetyhack 5y ago
If you spent the time and effort to hunt down the problem for them, the least they could do is look into it. repos that don't care enough are a waste of time.
- makeitdouble 5y ago
  TBF, even if your PR solves an actual issue a number of users have, it still might not be a good fit for the project's future, and starting a discussion about it might not be worth anyone's time. More importantly, as you disclosed your solution, other affected by the issue can rely on your code in the meantime (= the rest of the project's life in some cases. I've been there). If it really is a critical issue that isn't solved, your fix can always be used in a different fork with better maintenance. All in all, the upstream repo not responding to a PR isn't the end of the world I think, and the openness of the system makes it an acceptable state in many ways IMHO.
mwaitjmp 5y ago
Out of interest then how do you proceed? Do you fork the code and run your own patched version?
- jdavis703 5y ago
  Yes, just use our own forked version.
  - arthurcolle 5y ago
    So then when your upstream repo diverges would you just rebase and manually add in anything you want from the forked development tree on the upstream side? Not sure what's best practice so... just curious how people have handled this - I usually leave my forks of stuff pretty stale and focus on my own little sub-pieces to achieve what I want but not too much else.
    - rad_gruchalski 5y ago
      I usually have my own branch which can be used to get a diff and maintain the diff on any major code structure change. Most often there is not much hassle but can be annoying.
    - dharmab 5y ago
      Yes, we would branch from upstream again and apply the patch set against the new branch. Normally it is trivial but once in a while there are manual changes necessary.
    - acidbaseextract 5y ago
      Maintaining the fork as a stack of patches using something like Stacked Git can make it a little easier than rebasing: https://stacked-git.github.io/ https://stacked-git.github.io/
  - don-code 5y ago
    I do this. I wish I didn't. First of all, building a provider isn't straightforward. The best way I've found to do this is to wrap `terraform init`, and have it `docker run` a build process for a plugin version that never existed - then dumping the built provider into the `.terraform` directory for the project. It's prone to failure; new users of the Terraform project complain that the build eats 8GB of RAM and takes many minutes. Second, providers are constantly changing, and it's not always possible to cleanly rebase a set of community changes on top of master. Part of the trouble with letting PRs wither on the vine is that they themselves become stale - in one case, the code still compiles, but the end result is completely wrong. For what it's worth: my use case was needing to use Terraform with some more "unusual" features of CloudFront and ALBs. The 80% use case for support is great. There's a remaining 15% that's well implemented by unmerged PRs, and another 5% entirely that's completely unsuppored. I've kept it IaC by using the `null_resource` provisioner to shell out to the AWS CLI where absolutely necessary.

qbasic_forever 5y ago

I don't understand why people think that just doing unsolicitied work and pressing a button means the people on the other side are obligated to spend time reviewing and integrating it. GitHub has weirdly unbalanced open source contributions with a heavier burden and burnout on maintainers. Contributing to a project doesn't mean just slinging code and calling it good. Communicate--talk to the people maintaining the code. Ask them, hey I have an idea and want to add this feature/fix this bug/etc.--do you have bandwidth for that change? Mailing lists, discussion forums, chat rooms, e-mails, etc. are the place to sort this out, not snarky or even angrier and angrier replies to an unsolicited pull request that goes unreviewed.

leetrout 5y ago
To be explicit: I agree. But I still think it's basic decency to close the PR and tell them No. Or if you plan to leave it around make a comment to that effect.
- geerlingguy 5y ago
  There are many projects where just doing that would be the equivalent of a full time position. Even saying no requires a skilled review.
  - amyjess 5y ago
    Is there no way to just have a script add a comment on every new PR saying "Due to insufficient staff, your PR may not be reviewed for a considerable amount of time."?
    - tmp538394722 5y ago
      Your code is important to us. Please stay on the line, and the next available reviewer will answer your code. Due to unusually high code volumes, this response may take longer than usual. Something like that?

sergiotapia 5y ago

I disagree, when someone opens a PR on my project it's an imposition of my time. I appreciate the help but I will review when I have time and feel like it's a good time to do it.

junon 5y ago

> I stand by my statement then and now: there is nothing worse than contributing to something open source and then have your PR completely ignored Really? Nothing worse?

raffraffraff 5y ago
Jock itch is pretty bad. Might even be worse.