4 ms·

Sometimes you can just go fix the software yourself. Maintainers always seem to say you should file an issue before working on a PR. However, I find for featur

by strken 4y ago

Sometimes you can just go fix the software yourself. Maintainers always seem to say you should file an issue before working on a PR. However, I find for features you really need, you should just fork the software yourself[0] and implement what you need, then put up a quick PR with your changes. The worst they can do is reject your changes, in which case...well, you're using your fork anyway. [0] Github forks are lightweight, easy(ish) to keep up to date, and integrated into a lot of package managers.

rglullis 4y ago
Yes, and when for the times that you can't fix yourself should work as a reminder that you should be paying to support those who can.
philliphaydon 4y ago
A couple of times I’ve come across issues in OSS and gone to raise a bug report while digging through the code to see if I can fix it or propose a solution. But when I opened the issue and saw it required me to write a novel I’ve just closed it, worked around or patched it and moved on. It’s too much of a hassle.
- nijave 4y ago
  The ones that demand reproduction always get me. I get it: reproduction instructions make it infinitely easier to repair software. On the other hand, there are many cases like race conditions that can be very hard to reproduce and sometimes you can get enough context from stack traces/logs/debug info to figure out and fix the problem anyway.
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 ago
  Or even ignoring it for a year and then automatically close it for inactivity. Feedback, even negative feedback, I better than that.
- strken 4y ago
  It 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 ago
    We’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?
dessant 4y ago
Your quick PR becomes the maintainer's burden, and rejecting a pull request can also come with a substantial time cost. It's best to conform to the contribution process described by the maintainer to avoid wasting their time as much as possible.
- Aeolun 4y ago
  > It's best to conform to the contribution process described by the maintainer to avoid wasting their time as much as possible. It’s not their prerogative to waste my time, just as it’s not mine to waste theirs. If they’re not happy with a PR they’re welcome to reject it, ask me to fix it, or completely ignore it. When they make a project public they’re explicitly condoning the fact they may get a PR (and nothing else).
  - dessant 4y ago
    > When they make a project public they’re explicitly condoning the fact they may get a PR I don't think that's true. It appears you just assume that because pull requests cannot be disabled on GitHub. Sending unsolicited pull requests to people that clearly told you to open an issue first is disrespectful. You don't have to engage with a project or a community, but if you decide to participate by submitting a pull request, you should follow their contribution guidelines.
    - deleted 4y ago
      [deleted]
    - Aeolun 4y ago
      > Sending unsolicited pull requests to people that clearly told you to open an issue first is disrespectful. You do you. I do not think it is, and so far nobody has made an issue out of it. > It appears you just assume that because pull requests cannot be disabled on GitHub. It’s more that people that make a public repo on Github and expect no pull requests on even mildly popular software are living in fairyland. Don’t make a repo on Github when you know PR’s can’t be disabled. Or I dunno, install a bot that automatically rejects everything.

by strken 4y ago

rglullis 4y ago

Yes, and when for the times that you can't fix yourself should work as a reminder that you should be paying to support those who can.

philliphaydon 4y ago

A couple of times I’ve come across issues in OSS and gone to raise a bug report while digging through the code to see if I can fix it or propose a solution. But when I opened the issue and saw it required me to write a novel I’ve just closed it, worked around or patched it and moved on. It’s too much of a hassle.

nijave 4y ago
The ones that demand reproduction always get me. I get it: reproduction instructions make it infinitely easier to repair software. On the other hand, there are many cases like race conditions that can be very hard to reproduce and sometimes you can get enough context from stack traces/logs/debug info to figure out and fix the problem anyway.

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 ago
Or even ignoring it for a year and then automatically close it for inactivity. Feedback, even negative feedback, I better than that.
strken 4y ago
It 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 ago
  We’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?

dessant 4y ago

Your quick PR becomes the maintainer's burden, and rejecting a pull request can also come with a substantial time cost. It's best to conform to the contribution process described by the maintainer to avoid wasting their time as much as possible.

Aeolun 4y ago
> It's best to conform to the contribution process described by the maintainer to avoid wasting their time as much as possible. It’s not their prerogative to waste my time, just as it’s not mine to waste theirs. If they’re not happy with a PR they’re welcome to reject it, ask me to fix it, or completely ignore it. When they make a project public they’re explicitly condoning the fact they may get a PR (and nothing else).
- dessant 4y ago
  > When they make a project public they’re explicitly condoning the fact they may get a PR I don't think that's true. It appears you just assume that because pull requests cannot be disabled on GitHub. Sending unsolicited pull requests to people that clearly told you to open an issue first is disrespectful. You don't have to engage with a project or a community, but if you decide to participate by submitting a pull request, you should follow their contribution guidelines.
  - deleted 4y ago
    [deleted]
  - Aeolun 4y ago
    > Sending unsolicited pull requests to people that clearly told you to open an issue first is disrespectful. You do you. I do not think it is, and so far nobody has made an issue out of it. > It appears you just assume that because pull requests cannot be disabled on GitHub. It’s more that people that make a public repo on Github and expect no pull requests on even mildly popular software are living in fairyland. Don’t make a repo on Github when you know PR’s can’t be disabled. Or I dunno, install a bot that automatically rejects everything.