6 ms·

Well, from my perspective it seems common practice in most open source projects which are hosted on GH that maintainers at least consider PRs and typically only

Well, from my perspective it seems common practice in most open source projects which are hosted on GH that maintainers at least consider PRs and typically only reject if the PR is flawed, incomplete or somehow adds feature creep. Of course any maintainer is free to handle it differently, but if going against usual expectations, it would be benefitial for all involved to note reluctance to PRs prominently to the Readme.

virtue3 7y ago
It takes time to validate a PR, to test it, to verify it. He is not being paid for his time, he does not owe -anyone- his time. If you don't like the way a project is being run, fork it and own it yourself. I know that's harsh, and not idealistic, but it's the way people should really think about this. People take FOSS for granted, CONSTANTLY. And maintainers even more so.
- mratsim 7y ago
  The PR contributor was not paid either to investigate the bug, reproduce it, write a patch and test it. However instead of raising a "don't work, please fix" bug s/he took the time to do all that. Anyone that went to such length deserve basic courtesy, whether the code is accepted or refused. Refusing a patch because it is "boring" is not respecting the time people dedicated to your project. I would understand refusing because the patch makes an unwanted compromise on performance and the maintainer considers performance regressions as bug.
  - cerberusss 7y ago
    These are merely your expectations, and this will probably disappoint you in the future. I have replied to logged issues with the question: "I don't work on this, unless you have set aside a budget that pays my hourly rate".
- jhall1468 7y ago
  And when maintainers respond to a significant amount of work involved in a PR for a bug with a note that they aren't interested because it's "boring" then they can be critiqued for being a jerk, because they decided to be a jerk. If the maintainer had said, "Hey, I don't have the time to review/test/verify this PR so I'm closing it for now," the backlash probably wouldn't have been quite so severe.
AlchemistCamp 7y ago
I'm not sure the practice is that common when the maintainer works for one of the largest 5 software companies in the world and that company is using the code.
aspaceman 7y ago
This isn’t true at all. Many projects even say “we won’t accept PRs” in their README. When the code is being used internally at Microsoft, it makes even more sense they wouldn’t take PRs.
- NewsAware 7y ago
  Which is exactly what I suggested - avoid strife over mismatched expectations with a one liner. I would take your first paragraph to actually strengthen my assumption that Kinder treatment of PRs is the norm and that's why the many projects you mention add that line.
- mroche 7y ago
  There's been a request going for several years now to disable Pull Requests on GitHub[0]. They allow project maintainers to disable Issues, they should also be allowed to disable PRs rather than use automation to close any opened PR. Other SCM products (e.g. GitLab) offer the ability to make PRs available only to project members, or disable them completely. [0] https://github.com/dear-github/dear-github/issues/84 https://github.com/dear-github/dear-github/issues/84
iudqnolq 7y ago
I thought basic etiquette was issue to discuss before PR? Starting with a PR seems to me like saying "you have nothing to tell me about how your code works, I know exactly how your code should be changed and if my changes conflict with what you're working on you should throw your code out because mine is better". Is that wrong?
- aprdm 7y ago
  For what its worth I agree with you
- jlokier 7y ago
  I agree that should be the basic etiquette. Perhaps it needs to be said more clearly on project pages and codes of conduct and participation. (Of course, it is not reasonable to demand that an already-overworked maintainer-for-free find extra hours to have the pre-PR discussion either. It needs to be exploratory and respect the maintainers' timescales. Luckily, if you don't get the response you wanted, you can fork and hire someone else or do it yourself, and keep your fixes in the queue for others to review eventually, if they want, at whatever timescale suits them.) Unfortunately, there seem to be quite a lot of people who would, rather than discussing ideas respectfully, instead prefer to bully and shame the maintainer. Such as, for example, calling out perceived issues in the code publically (sometimes incorrectly), and making out how unskilled the maintainer must be, in order to put pressure on the maintainer to sacrifice their personal life and do what the bully wants.
  - iudqnolq 7y ago
    > Of course, it is not reasonable to demand that an already-overworked maintainer-for-free find extra hours to have the pre-PR discussion either. It needs to be exploratory and respect the maintainers' timescales I absolutely didn't mean to imply that. I also think that a pre-PR discussion can be useful because if the maintainer doesn't have time to say they want a PR that's a decent hint they won't have time to handle the PR.
    - jlokier 7y ago
aprdm 7y ago
I worked with a person who happens to have one of the most popular OSS Packages of my industry. He has a kid and works 8hs a day like all of us... some merge requests are two years old, he doesn't have time for all the feedback / suggestions he receives and just keeps coding in his very limited time because is what he is passionate about... people keep using it.

virtue3 7y ago

It takes time to validate a PR, to test it, to verify it. He is not being paid for his time, he does not owe -anyone- his time. If you don't like the way a project is being run, fork it and own it yourself. I know that's harsh, and not idealistic, but it's the way people should really think about this. People take FOSS for granted, CONSTANTLY. And maintainers even more so.

mratsim 7y ago
The PR contributor was not paid either to investigate the bug, reproduce it, write a patch and test it. However instead of raising a "don't work, please fix" bug s/he took the time to do all that. Anyone that went to such length deserve basic courtesy, whether the code is accepted or refused. Refusing a patch because it is "boring" is not respecting the time people dedicated to your project. I would understand refusing because the patch makes an unwanted compromise on performance and the maintainer considers performance regressions as bug.
- cerberusss 7y ago
  These are merely your expectations, and this will probably disappoint you in the future. I have replied to logged issues with the question: "I don't work on this, unless you have set aside a budget that pays my hourly rate".
jhall1468 7y ago
And when maintainers respond to a significant amount of work involved in a PR for a bug with a note that they aren't interested because it's "boring" then they can be critiqued for being a jerk, because they decided to be a jerk. If the maintainer had said, "Hey, I don't have the time to review/test/verify this PR so I'm closing it for now," the backlash probably wouldn't have been quite so severe.

AlchemistCamp 7y ago

I'm not sure the practice is that common when the maintainer works for one of the largest 5 software companies in the world and that company is using the code.

aspaceman 7y ago

This isn’t true at all. Many projects even say “we won’t accept PRs” in their README. When the code is being used internally at Microsoft, it makes even more sense they wouldn’t take PRs.

NewsAware 7y ago
Which is exactly what I suggested - avoid strife over mismatched expectations with a one liner. I would take your first paragraph to actually strengthen my assumption that Kinder treatment of PRs is the norm and that's why the many projects you mention add that line.
mroche 7y ago
There's been a request going for several years now to disable Pull Requests on GitHub[0]. They allow project maintainers to disable Issues, they should also be allowed to disable PRs rather than use automation to close any opened PR. Other SCM products (e.g. GitLab) offer the ability to make PRs available only to project members, or disable them completely. [0] https://github.com/dear-github/dear-github/issues/84 https://github.com/dear-github/dear-github/issues/84

iudqnolq 7y ago

I thought basic etiquette was issue to discuss before PR? Starting with a PR seems to me like saying "you have nothing to tell me about how your code works, I know exactly how your code should be changed and if my changes conflict with what you're working on you should throw your code out because mine is better". Is that wrong?

aprdm 7y ago
For what its worth I agree with you
jlokier 7y ago
I agree that should be the basic etiquette. Perhaps it needs to be said more clearly on project pages and codes of conduct and participation. (Of course, it is not reasonable to demand that an already-overworked maintainer-for-free find extra hours to have the pre-PR discussion either. It needs to be exploratory and respect the maintainers' timescales. Luckily, if you don't get the response you wanted, you can fork and hire someone else or do it yourself, and keep your fixes in the queue for others to review eventually, if they want, at whatever timescale suits them.) Unfortunately, there seem to be quite a lot of people who would, rather than discussing ideas respectfully, instead prefer to bully and shame the maintainer. Such as, for example, calling out perceived issues in the code publically (sometimes incorrectly), and making out how unskilled the maintainer must be, in order to put pressure on the maintainer to sacrifice their personal life and do what the bully wants.
- iudqnolq 7y ago
  > Of course, it is not reasonable to demand that an already-overworked maintainer-for-free find extra hours to have the pre-PR discussion either. It needs to be exploratory and respect the maintainers' timescales I absolutely didn't mean to imply that. I also think that a pre-PR discussion can be useful because if the maintainer doesn't have time to say they want a PR that's a decent hint they won't have time to handle the PR.
  - jlokier 7y ago

aprdm 7y ago

I worked with a person who happens to have one of the most popular OSS Packages of my industry. He has a kid and works 8hs a day like all of us... some merge requests are two years old, he doesn't have time for all the feedback / suggestions he receives and just keeps coding in his very limited time because is what he is passionate about... people keep using it.