3 ms·

> 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 pu

> 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.

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.