3 ms·

The problem is, I find I never get lovely clean patches, I just get GitHub PRs that day "hey, your code doesn't work on my weird CPU", or get a patch that fixes

The problem is, I find I never get lovely clean patches, I just get GitHub PRs that day "hey, your code doesn't work on my weird CPU", or get a patch that fixes KettleBSD which breaks Cygwin on windows (which we care much more about supporting). I don't think anyone is complaining about well written fully functioning patches, that break no existing features or OSes.

Hackbraten 4y ago
> I don't think anyone is complaining about well written fully functioning patches, that break no existing features or OSes. While most wouldn’t be complaining, I think any maintainer should absolutely feel free to refuse a well-written, fully working patch for any reason. For example, that patch may be too large or too complex, thus might become a liability at some point in the future. Maybe managing user expectations is a priority for the maintainer. Maybe they wish to reduce support burden because they’d like spend more time with their family. All that should be deemed normal and acceptable. It can feel disappointing (numerous pull requests that I wrote have been denied or ignored), but I think it’s important that we, as a community, normalize that.
johnklos 4y ago
I think part of this could be fixed if Github, which seems to be the most used, lowest common denominator, had bug report mechanisms that were the equivalent of: "This bug report has been reviewed and can't continue without more information. This report is now considered inactive unless you do these prescribed actions and report back with this specific information. Click here to submit this specific information."
- Hackbraten 4y ago
  Some projects seem to be assigning labels such as `needs-response` or `awaiting-user-response`, and have a bot in place that closes the issue if it gets stale.

3 ms·

The problem is, I find I never get lovely clean patches, I just get GitHub PRs that day "hey, your code doesn't work on my weird CPU", or get a patch that fixes

by CJefferson 4y ago

Hackbraten 4y ago
> I don't think anyone is complaining about well written fully functioning patches, that break no existing features or OSes. While most wouldn’t be complaining, I think any maintainer should absolutely feel free to refuse a well-written, fully working patch for any reason. For example, that patch may be too large or too complex, thus might become a liability at some point in the future. Maybe managing user expectations is a priority for the maintainer. Maybe they wish to reduce support burden because they’d like spend more time with their family. All that should be deemed normal and acceptable. It can feel disappointing (numerous pull requests that I wrote have been denied or ignored), but I think it’s important that we, as a community, normalize that.
johnklos 4y ago
I think part of this could be fixed if Github, which seems to be the most used, lowest common denominator, had bug report mechanisms that were the equivalent of: "This bug report has been reviewed and can't continue without more information. This report is now considered inactive unless you do these prescribed actions and report back with this specific information. Click here to submit this specific information."
- Hackbraten 4y ago
  Some projects seem to be assigning labels such as `needs-response` or `awaiting-user-response`, and have a bot in place that closes the issue if it gets stale.