3 ms·
> The worst they can do is reject your changes, in which case...well, you're using your fork anyway. Actually the worst result is ignoring the PR for years. I'
by mid-kid 4y ago
> The worst they can do is reject your changes, in which case...well, you're using your fork anyway.
Actually the worst result is ignoring the PR for years. I've seen this happen quite a lot, and it puts me in an uneasy spot where I don't know whether it's something with the PR or the way I communicated it or what.
After having this experience one too many times, I've started opening issues and if I'm really serious about getting it into the project, disucssing with people in the related IRC/forum/whatever before starting to work on it. This helps notify people that hey, I'm doing a bit of effort and I'd love to at least get a "sorry I'm too busy/uninterested in this feature to look at your PR".
- yxhuvud 4y agoOr even ignoring it for a year and then automatically close it for inactivity. Feedback, even negative feedback, I better than that.
- strken 4y agoIt doesn't matter if they ignore the PR. You've got a working fork. Merging your changes back into the upstream is a happy side effect.
- vegetablepotpie 4y agoWe’ll, maybe. It depends on what kind of project it is. What happens when your fork introduces hard to reproduce bugs? What happens when there are security updates to the project that cause merge conflicts with your fork? What happens when the project makes architectural changes that require reimplementing your feature? What happens when you leave the company, and your former coworkers have the responsibility to maintain your fork?