4 ms·

If you are writing something to contribute it to a project, then you should discuss the idea with the current committers/maintainer on the project's mailing lis

If you are writing something to contribute it to a project, then you should discuss the idea with the current committers/maintainer on the project's mailing list, or discord, or however they communicate. If you don't, and you submit a PR, you should expect the PR to be closed with a "Unfortunately, this change was not discussed. As a result it may clash with other efforts underway, or our future roadmap. Also, not having discussed it prior to the PR increases the suspicion that you have not followed our coding guidelines. Consequently this PR is closed. Please propose the change on the mailing list and take part in the discussion before revising this patch and resubmitting the PR." Because of this I think an auto-close is fine. I also do think Github should allow disabling the PR tab.

gus_massa 6y ago
I agree, but I'd make an exception for fixing typos, obvious bugs and tiny additional features. Sometimes the change takes less time that discussing in other channels, and sometimes it's easier to explain with code if you are not a native speaker. I think that spending more of a weekend in a PR without checking before with the maintainers is a bad idea, because there is a big risk that is not merged and is a waste of time. Also, each project has it's own weird rules, like code style, space vs tabs, changing whitespace in unrelated lines, adding tests, ... and a long list. Some are written explicitly, and some are just implicit rules. So sometimes it's difficult to make a PR that follows all the rules.
- Communitivity 6y ago
  100% agreed. Things that are obvious to fix and have no design impact should be ok to PR and get accepted quickly. Every rule has exceptions, and this is definitely one for the rule I described. Thank you for pointing reminding me and clarifying.
- phkahler 6y ago
  Yep. We had a PR for a single character typo. The submitter went to a lot of trouble, but the burden to the project really was as small as could be. No discussion, no open issue, just a PR with a one liner that could be reviewed in seconds and accepted with a click. Any other process would have been more work for the maintainers.
matthewmacleod 6y ago
I guess this would probably solve the problem of you getting unsolicited contributions – by making you come off as such a gigantic raging arsehole that nobody would want to work with you again.
- Communitivity 6y ago
  Perhaps? But if someone had that attitude, and couldn't be bothered to discuss design impacting changes with the devs who are making sweeping changes impacted by the contributor's change? In that case I don't want them on my project, because they are toxic, and probably toxic in other ways. More people need to realize that Open Source projects are a gift from the authors to the software community. Other developers do not have the right to make changes, push for the development to go in a certain direction, etc. If an author wants that they'll turn stewardship over to a committee and maybe be part of such a committee. You have only two rights with Open Source work you want to work differently: fork it or forget about it (i.e., not use it). Anything else is a massive gift from the maintainer(s) and should be viewed as such. And yeah, as you can tell from the last paragraph I'll proudly wear an Arsehole button to avoid wearing a Burnout button. Heck, to borrow from Bruce Lee in Snowcrash, I'd even wear a "12 Gauge" button to avoid burnout (button only though, the behavior is not for me).
- young_unixer 6y ago
  That didn't work for Torvalds.

gus_massa 6y ago

I agree, but I'd make an exception for fixing typos, obvious bugs and tiny additional features. Sometimes the change takes less time that discussing in other channels, and sometimes it's easier to explain with code if you are not a native speaker. I think that spending more of a weekend in a PR without checking before with the maintainers is a bad idea, because there is a big risk that is not merged and is a waste of time. Also, each project has it's own weird rules, like code style, space vs tabs, changing whitespace in unrelated lines, adding tests, ... and a long list. Some are written explicitly, and some are just implicit rules. So sometimes it's difficult to make a PR that follows all the rules.

Communitivity 6y ago
100% agreed. Things that are obvious to fix and have no design impact should be ok to PR and get accepted quickly. Every rule has exceptions, and this is definitely one for the rule I described. Thank you for pointing reminding me and clarifying.
phkahler 6y ago
Yep. We had a PR for a single character typo. The submitter went to a lot of trouble, but the burden to the project really was as small as could be. No discussion, no open issue, just a PR with a one liner that could be reviewed in seconds and accepted with a click. Any other process would have been more work for the maintainers.

matthewmacleod 6y ago

I guess this would probably solve the problem of you getting unsolicited contributions – by making you come off as such a gigantic raging arsehole that nobody would want to work with you again.

Communitivity 6y ago
Perhaps? But if someone had that attitude, and couldn't be bothered to discuss design impacting changes with the devs who are making sweeping changes impacted by the contributor's change? In that case I don't want them on my project, because they are toxic, and probably toxic in other ways. More people need to realize that Open Source projects are a gift from the authors to the software community. Other developers do not have the right to make changes, push for the development to go in a certain direction, etc. If an author wants that they'll turn stewardship over to a committee and maybe be part of such a committee. You have only two rights with Open Source work you want to work differently: fork it or forget about it (i.e., not use it). Anything else is a massive gift from the maintainer(s) and should be viewed as such. And yeah, as you can tell from the last paragraph I'll proudly wear an Arsehole button to avoid wearing a Burnout button. Heck, to borrow from Bruce Lee in Snowcrash, I'd even wear a "12 Gauge" button to avoid burnout (button only though, the behavior is not for me).
young_unixer 6y ago
That didn't work for Torvalds.