4 ms·

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

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.
    - dessant 4y ago
      It's one thing to stumble upon a repository that does not have contribution guidelines and submit a pull request, that is obviously fine. But you're advocating against respecting the wishes of strangers, and disregard their request to coordinate with them before submitting your work. You have the option to walk away and not contribute if you don't like the rules for interaction that have been set by the people that manage the project. Or just follow the rules. Those are your only two sane options, unless you become a maintainer yourself at that project, and modify the contribution guidelines. To be very clear, you have to understand what NO means in this context, and realize that "I don't like bureaucracy" is not a valid reason to push forward on your own terms.
  - samatman 4y ago
    No, I think it's fair to work backward: GitHub doesn't offer a way to disable PRs, the service is explicitly 'social coding', therefore those using it should not be disgruntled about PRs showing up. The healthy maintainer-side attitude is that these impose no obligation whatsoever to review, apply, or even look at, the fork in question.
    - dessant 4y ago
      GitHub is indeed a platform that can be used for social coding, and it is also a service that encourages the use of contribution guidelines. If the maintainer asks you to open an issue to discuss your contribution before submitting a pull request, you are expected to follow their wishes. https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors https://docs.github.com/en/communities/setting-up-your-proje...
      - samatman 4y ago
        Which of course I do. The emotional side of the burden of closing PRs which don't follow guidelines is the part which can be set aside. It's just a bit of housecleaning, it's seldom done from malice, English is not everyone's first language, etc. Getting upset that a mechanism which exists and won't change gets used is not healthy.
        dessant 4y ago
        The issue wasn't an occasional mistake done in good faith. The commenter has decided to explicitly dismiss contribution guidelines, and for that the healthy response is to call out their lack of respect for the time of open source maintainers. The focus wasn't on emotional burden either, it can simply take a lot of time to sort out issues and pull requests that do not follow contribution guidelines when you maintain a popular project. It isn't a bit of house cleaning, but hours wasted every week, depending on the project.
- jrochkind1 4y ago
  I assume the PR describes the thing you are fixing anyway? (It better if you want it to have a chance of getting reviewed/merged!) I don't see why you couldn't just file an issue with the copy-paste of that description, and then immediately file the PR too with a proposed solution. I don't understand this issue/dispute. I don't understand the problem with filing an Issue to correspond to the PR, it doesn't seem to be any significant extra work or change to the desired workflow of the person who "just" wants to file a PR. Am I misunderstanding the issue?
  - Aeolun 4y ago
    > I don't understand the problem with filing an Issue to correspond to the PR I positively detest pointless bureaucracy? I can live with it when someone is paying me 200k/year for it. Not when I’m trying to give my work away for free. I’m honestly a bit surprised about how strongly I feel about this.
    - jrochkind1 4y ago
      OK, I wasn't missing anything. As a favor for the the person giving you free labor who finds it easier to organize things that way, even if to you it seems like pointless beurocracy, we all have different organizational styles and they find it useful to make sure bugs/scopes/requirements are in Issues with the solutions in Projects? Yeah, I think you're being unreasonably weird, and on further reflection I don't think this is even a generalizable enough problem to be worth talking about, it's just some weird idiosyncracy of yours to refuse on principle to do trivial organizational work that the maintainers of the project you'd like to contribute to have said makes it easier for them to deal with your contribution. (trivial work; you aren't even saying it would be a burden in terms of time/energy, just that it's a weird principle you have not to do anything you don't want to do even if it makes things easier on other people). It's kind of just a true-ism of any kind of work we do collaboratively (and submitting a patch to a project that others maintain is such) that you need to do sometimes do things out of consideration for what works for the other people. I guess I am curious why you are insisting on sending a PR that you know doesn't follow the process the maintainers have asked for -- instead of just not submitting the PR at all though? If you're worried about your time being wasted, wouldn't it be best not to submit the PR at all? Make your own fork that meets your purposes, don't interact with them at all. Now you don't risk wasting the 30 seconds it took to make the PR, when they just close it for not following their procedure since you didn't want to waste the 30 more seconds it might take to do so.
strken 4y ago
The best thing is to fork it, use your fork, get as far as you can through their process, but give up quickly if it looks too hard. That way you don't have to deal with overly complicated processes and you still get to use working software.

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.
  - dessant 4y ago
    It's one thing to stumble upon a repository that does not have contribution guidelines and submit a pull request, that is obviously fine. But you're advocating against respecting the wishes of strangers, and disregard their request to coordinate with them before submitting your work. You have the option to walk away and not contribute if you don't like the rules for interaction that have been set by the people that manage the project. Or just follow the rules. Those are your only two sane options, unless you become a maintainer yourself at that project, and modify the contribution guidelines. To be very clear, you have to understand what NO means in this context, and realize that "I don't like bureaucracy" is not a valid reason to push forward on your own terms.
- samatman 4y ago
  No, I think it's fair to work backward: GitHub doesn't offer a way to disable PRs, the service is explicitly 'social coding', therefore those using it should not be disgruntled about PRs showing up. The healthy maintainer-side attitude is that these impose no obligation whatsoever to review, apply, or even look at, the fork in question.
  - dessant 4y ago
    GitHub is indeed a platform that can be used for social coding, and it is also a service that encourages the use of contribution guidelines. If the maintainer asks you to open an issue to discuss your contribution before submitting a pull request, you are expected to follow their wishes. https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors https://docs.github.com/en/communities/setting-up-your-proje...
    - samatman 4y ago
      Which of course I do. The emotional side of the burden of closing PRs which don't follow guidelines is the part which can be set aside. It's just a bit of housecleaning, it's seldom done from malice, English is not everyone's first language, etc. Getting upset that a mechanism which exists and won't change gets used is not healthy.
      - dessant 4y ago
        The issue wasn't an occasional mistake done in good faith. The commenter has decided to explicitly dismiss contribution guidelines, and for that the healthy response is to call out their lack of respect for the time of open source maintainers. The focus wasn't on emotional burden either, it can simply take a lot of time to sort out issues and pull requests that do not follow contribution guidelines when you maintain a popular project. It isn't a bit of house cleaning, but hours wasted every week, depending on the project.
jrochkind1 4y ago
I assume the PR describes the thing you are fixing anyway? (It better if you want it to have a chance of getting reviewed/merged!) I don't see why you couldn't just file an issue with the copy-paste of that description, and then immediately file the PR too with a proposed solution. I don't understand this issue/dispute. I don't understand the problem with filing an Issue to correspond to the PR, it doesn't seem to be any significant extra work or change to the desired workflow of the person who "just" wants to file a PR. Am I misunderstanding the issue?
- Aeolun 4y ago
  > I don't understand the problem with filing an Issue to correspond to the PR I positively detest pointless bureaucracy? I can live with it when someone is paying me 200k/year for it. Not when I’m trying to give my work away for free. I’m honestly a bit surprised about how strongly I feel about this.
  - jrochkind1 4y ago
    OK, I wasn't missing anything. As a favor for the the person giving you free labor who finds it easier to organize things that way, even if to you it seems like pointless beurocracy, we all have different organizational styles and they find it useful to make sure bugs/scopes/requirements are in Issues with the solutions in Projects? Yeah, I think you're being unreasonably weird, and on further reflection I don't think this is even a generalizable enough problem to be worth talking about, it's just some weird idiosyncracy of yours to refuse on principle to do trivial organizational work that the maintainers of the project you'd like to contribute to have said makes it easier for them to deal with your contribution. (trivial work; you aren't even saying it would be a burden in terms of time/energy, just that it's a weird principle you have not to do anything you don't want to do even if it makes things easier on other people). It's kind of just a true-ism of any kind of work we do collaboratively (and submitting a patch to a project that others maintain is such) that you need to do sometimes do things out of consideration for what works for the other people. I guess I am curious why you are insisting on sending a PR that you know doesn't follow the process the maintainers have asked for -- instead of just not submitting the PR at all though? If you're worried about your time being wasted, wouldn't it be best not to submit the PR at all? Make your own fork that meets your purposes, don't interact with them at all. Now you don't risk wasting the 30 seconds it took to make the PR, when they just close it for not following their procedure since you didn't want to waste the 30 more seconds it might take to do so.

strken 4y ago

The best thing is to fork it, use your fork, get as far as you can through their process, but give up quickly if it looks too hard. That way you don't have to deal with overly complicated processes and you still get to use working software.