4 ms·

Asking the maintainer if you are allowed to provide a fix is an option? Open pull requests are better than no pull requests. If the maintainers don't want them

Asking the maintainer if you are allowed to provide a fix is an option? Open pull requests are better than no pull requests. If the maintainers don't want them merged to their code base, other users can still merge them to their base.

deleted 6y ago
[deleted]
imtringued 6y ago
The real problem is that pull requests are the wrong form of communication. By the time someone sends a pull request they already put a significant amount of effort into their message and thus will rightfully get angry when their efforts are being rejected. You need to contact the maintainers directly and talk with them, preferably in an informal format where it is okay for things to be forgotten or thrown out. The fact that things are written down and recorded forever with an expectation of work is what is causing all the problems.
- cies 6y ago
  rightfully -> understandibly
- mitjak 6y ago
  i dont think anyone submitting an unsolicited PR should be expecting it to be merged in. it's a way to convey a complete idea, not a guarantee of merging.
  - anticristi 6y ago
    I do that. I sometimes prefer PRs to discuss my improvements. By the time I answer questions such as "how intrusive would this change be", "what exactly needs to be changed", "how would I test my change", I'm already halfway through the PR. I agree that sending a PR should not be considered a guarantee of merging. Rather an issue that is discussed with a mixture of prose and code.
  - kelnos 6y ago
    No, they shouldn't be expecting anything, but a lot of people will. And that's just how it is. If we don't want people to waste their time and potentially get upset, we should write out up-front what our contribution policy is. Note that I'm not talking about how the world should be. I'm talking about how it is. I agree that people shouldn't just write up a PR without any prior communication with the maintainer and then expect it to get merged. But people do; that's just reality.
    - mitjak 6y ago
      absolutely. im on the side of documenting and reiterating to get this across.
- phkahler 6y ago
  >> By the time someone sends a pull request they already put a significant amount of effort into their message and thus will rightfully get angry when their efforts are being rejected. I'd prefer if they open an issue - or use an existing one - as a forum to discuss what they'll be doing in a PR. That way we can either reject an idea prior to someone putting in the effort, or talk about implementation so the resulting PR is more likely to be accepted. Drive by PRs are fine if they're simple, but the ones of higher impact need more consideration. Even more than PRs, I have mixed feelings about feature requests. Many of them are legit things that would make the software better, but with limited resources they're likely to sit for years. Is it better to let them pile up or close them? Maybe a new tag - Deferred.
- jabbany 6y ago
  Putting in effort unfortunately doesn't mean creating positive value (https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://en.wikipedia.org/wiki/The_Mythical_Man-Month). The good thing with FOSS is that the effort isn't _wasted_ since that code is still around in a fork, if not in upstream.
- ufmace 6y ago
  Yes this. These days, I'm not gonna bother without communication directly from a maintainer that a PR to do whatever I'm interested in doing would be welcome and can be reviewed and merged in a decent timeframe.
  - Phil-bitplex 6y ago
    This is the approach I want to take as well - but I give up so many times because I can’t track down a method of communicating with that person. I looked a while ago and I couldn’t find a way to send a message to a user on GitHub. Any recommendations on effective ways of reaching out to project owners?
    - ufmace 6y ago
      It's usually fine to open an issue on the repo. It should have a detailed description of what's wrong, reproduction steps if appropriate etc, basically enough to show that you know what you're doing, have put some effort into it, and care about the project. Perhaps you'll get a response from a project maintainer, and can ask if they're open to a PR to fix it. IME, there's pretty good chances of positive engagement and eventual PR merge if you're fixing an actual bug in a good way, and not trying to add some massive new feature or completely change the way the thing works or something. If it's excessively difficult to find a way to communicate with a project maintainer, well, maybe there's your sign that this is not a good project to contribute to.
- throwawayboise 6y ago
  > rightfully get angry Why? You've taken the time to fix a problem you are having in code that you are using. You've made that patch available to the upstream maintainer, but if they don't accept it that doesn't stop you (or anyone else) from doing what you want to do with the code. I don't see how you're any worse off.
  - AmericanChopper 6y ago
    I contract for a lot of large enterprise, and I’ve written a lot of patches for open source projects in that capacity (to fix issues my large enterprise customers were having). My default position for this has always been that I’m going to get the benefit of fixing the problem regardless of whether my changes are merged. If the project maintainer chooses to merge my changes, then that’s even better, because that’s a tacit commitment from the project maintainer to maintain my changes into the future.
    - ghaff 6y ago
      > a tacit commitment from the project maintainer to maintain my changes into the future Sometimes. Depends on the norms of the project. Depends on the scope of the changes.
      - AmericanChopper 6y ago
        Of course. A lot of the time there’s not even a commitment that the project isn’t going to be entirely abandoned at some point in the future. But if you make your improvements available for other people to benefit from, you’re greatly increasing the chances that other people are also going to help maintain them (or maybe just devote some effort to avoid breaking them).
- emidln 6y ago
  Pull requests are the best form of communication. Have you ever had a user propose a feature, agree to contribute it, and go dark? A pull request says "I did this work, I think you might want to use it". Even for repos that aren't accepting contributions, it's better to have pull requests so that users can fork and apply PRs themselves than not have anything. Even if the original organization isn't interested in open collaboration and just wants to code dump, the community can still fix their own bugs and if it becomes frequent enough a maintained fork might appear.
  - didibus 6y ago
    That's fair, but I think there should be another feature for this that lists out the forks and the change they bring. Or at least there should be a clear way to indicate on a repo, PRs are not looked at and won't be merged. So if you make a PR you understand all you're doing is just advertising your fork.
yawaramin 6y ago
> Asking the maintainer if you are allowed to provide a fix is an option? It is (or should be) a standard practice to file an issue on the repo and ask there before starting work.
- vorpalhex 6y ago
  Even if the repo is open to PRs, you want to make sure you're not duplicating work someone else is doing and that you have all the requirements.

deleted 6y ago

[deleted]

imtringued 6y ago

The real problem is that pull requests are the wrong form of communication. By the time someone sends a pull request they already put a significant amount of effort into their message and thus will rightfully get angry when their efforts are being rejected. You need to contact the maintainers directly and talk with them, preferably in an informal format where it is okay for things to be forgotten or thrown out. The fact that things are written down and recorded forever with an expectation of work is what is causing all the problems.

cies 6y ago
rightfully -> understandibly
mitjak 6y ago
i dont think anyone submitting an unsolicited PR should be expecting it to be merged in. it's a way to convey a complete idea, not a guarantee of merging.
- anticristi 6y ago
  I do that. I sometimes prefer PRs to discuss my improvements. By the time I answer questions such as "how intrusive would this change be", "what exactly needs to be changed", "how would I test my change", I'm already halfway through the PR. I agree that sending a PR should not be considered a guarantee of merging. Rather an issue that is discussed with a mixture of prose and code.
- kelnos 6y ago
  No, they shouldn't be expecting anything, but a lot of people will. And that's just how it is. If we don't want people to waste their time and potentially get upset, we should write out up-front what our contribution policy is. Note that I'm not talking about how the world should be. I'm talking about how it is. I agree that people shouldn't just write up a PR without any prior communication with the maintainer and then expect it to get merged. But people do; that's just reality.
  - mitjak 6y ago
    absolutely. im on the side of documenting and reiterating to get this across.
phkahler 6y ago
>> By the time someone sends a pull request they already put a significant amount of effort into their message and thus will rightfully get angry when their efforts are being rejected. I'd prefer if they open an issue - or use an existing one - as a forum to discuss what they'll be doing in a PR. That way we can either reject an idea prior to someone putting in the effort, or talk about implementation so the resulting PR is more likely to be accepted. Drive by PRs are fine if they're simple, but the ones of higher impact need more consideration. Even more than PRs, I have mixed feelings about feature requests. Many of them are legit things that would make the software better, but with limited resources they're likely to sit for years. Is it better to let them pile up or close them? Maybe a new tag - Deferred.
jabbany 6y ago
Putting in effort unfortunately doesn't mean creating positive value (https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://en.wikipedia.org/wiki/The_Mythical_Man-Month). The good thing with FOSS is that the effort isn't _wasted_ since that code is still around in a fork, if not in upstream.
ufmace 6y ago
Yes this. These days, I'm not gonna bother without communication directly from a maintainer that a PR to do whatever I'm interested in doing would be welcome and can be reviewed and merged in a decent timeframe.
- Phil-bitplex 6y ago
  This is the approach I want to take as well - but I give up so many times because I can’t track down a method of communicating with that person. I looked a while ago and I couldn’t find a way to send a message to a user on GitHub. Any recommendations on effective ways of reaching out to project owners?
  - ufmace 6y ago
    It's usually fine to open an issue on the repo. It should have a detailed description of what's wrong, reproduction steps if appropriate etc, basically enough to show that you know what you're doing, have put some effort into it, and care about the project. Perhaps you'll get a response from a project maintainer, and can ask if they're open to a PR to fix it. IME, there's pretty good chances of positive engagement and eventual PR merge if you're fixing an actual bug in a good way, and not trying to add some massive new feature or completely change the way the thing works or something. If it's excessively difficult to find a way to communicate with a project maintainer, well, maybe there's your sign that this is not a good project to contribute to.
throwawayboise 6y ago
> rightfully get angry Why? You've taken the time to fix a problem you are having in code that you are using. You've made that patch available to the upstream maintainer, but if they don't accept it that doesn't stop you (or anyone else) from doing what you want to do with the code. I don't see how you're any worse off.
- AmericanChopper 6y ago
  I contract for a lot of large enterprise, and I’ve written a lot of patches for open source projects in that capacity (to fix issues my large enterprise customers were having). My default position for this has always been that I’m going to get the benefit of fixing the problem regardless of whether my changes are merged. If the project maintainer chooses to merge my changes, then that’s even better, because that’s a tacit commitment from the project maintainer to maintain my changes into the future.
  - ghaff 6y ago
    > a tacit commitment from the project maintainer to maintain my changes into the future Sometimes. Depends on the norms of the project. Depends on the scope of the changes.
    - AmericanChopper 6y ago
      Of course. A lot of the time there’s not even a commitment that the project isn’t going to be entirely abandoned at some point in the future. But if you make your improvements available for other people to benefit from, you’re greatly increasing the chances that other people are also going to help maintain them (or maybe just devote some effort to avoid breaking them).
emidln 6y ago
Pull requests are the best form of communication. Have you ever had a user propose a feature, agree to contribute it, and go dark? A pull request says "I did this work, I think you might want to use it". Even for repos that aren't accepting contributions, it's better to have pull requests so that users can fork and apply PRs themselves than not have anything. Even if the original organization isn't interested in open collaboration and just wants to code dump, the community can still fix their own bugs and if it becomes frequent enough a maintained fork might appear.
- didibus 6y ago
  That's fair, but I think there should be another feature for this that lists out the forks and the change they bring. Or at least there should be a clear way to indicate on a repo, PRs are not looked at and won't be merged. So if you make a PR you understand all you're doing is just advertising your fork.

yawaramin 6y ago

> Asking the maintainer if you are allowed to provide a fix is an option? It is (or should be) a standard practice to file an issue on the repo and ask there before starting work.

vorpalhex 6y ago
Even if the repo is open to PRs, you want to make sure you're not duplicating work someone else is doing and that you have all the requirements.