Comment by darawk
7 years ago
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.)
You're right--communicating about the intent of a patch is a good idea, especially if that intent is outside of normal expectations.
In a similar vein, I recently learned about prefixing a pull request on Github/Gitlab with "[WIP]", or a "work in progress", to suggest that the proposed changes are for informational purposes or not yet complete.
1 reply →