Comment by azernik
7 years ago
For people criticizing this approach as a selfish one:
Fixing toxic communities is work. While it would be a public service for the author to do so, she is under no obligation and probably has a day job and a life that take priority.
I praise community-builders and community-shapers and code-sharers and code-reviewers to the heavens, but I'm not going to knock someone who just can't be bothered to do all of that.
You don't need to fix a toxic community to just submit your patch. Just submit it, and if they don't want it, they don't want it. But at least you've done the bare minimum of giving back. If they want to tell you to fix your code formatting or something, or make your comments less phallocentric or whatever and you don't like it, don't make the changes - but you still ought to submit the patch.
On the other hand, reviewing code is also work. One could argue that if you don't intend you follow the contribution guidelines and work with the maintainers to get the code to a state where it's good enough to merge, you are wasting their time.
I agree, but I also think it's easy to avoid that. If you say in your cover letter "I appreciate that this might not be in a good state to merge, but I don't personally have any more time to spend on it and won't be able to respond to any code review; I'm posting it to make it public in case it helps somebody else", then the project knows where it stands with the patch, and can invest time, or not accordingly.
(I did something like that with a half-done binutils patch once. It wasn't committed, and I didn't expect it to be. But I was happier having put it out there, so somebody looking for weirdo-TI-COFF-format support maybe had a place to start.)
2 replies →