Comment by bayindirh
7 years ago
In most cases, the process has some hidden steps and hoops which are unrelated to patch.
The patch methodology will be probably criticized. Sometimes this criticism will go beyond the boundaries and leak to personal space of the developer, and the dialog will turn abrasive or abusive.
And a patch written in two days will be revised an revised for weeks. Not all revisions will be made for logical or legitimate reasons.
Then the developer will submit its patch, it'll be accepted at last, and the developer will never patch anything again, for ever. It'll be burnt out in a single patch.
Some communities do this, and often they don't know what they're doing.
I personally wouldn't do kernel patches. Heck, can't dare to ask anything to the list. Because I don't want the harassment. Also there's the silent ignorance in the mailing lists because your question is too basic or uninteresting or just posted to wrong-ish list. That's a different matter, but results in the same avoidance reflex.
Some anecdata:
I tried to submit a patch once (https://patchwork.ozlabs.org/patch/660921/) - which to me felt exactly as you described. I didn’t get the reply to my questions questioning the review comment (maybe I didn’t understand it completely so was not worthy of a response?).
In any case, luckily that was not in a critical path for me and then I have moved to a different project so I abandoned it - just seemed like a not so productive/happy use of my time.
And now I feel actively disinterested to ever attempt contributing again.
I can see the other side of the coin as well - the need to maintain the code quality, and probably the burnout of multiple “stupid” questions/patches. I can imagine how it gets tiring especially if one does it in their spare time.
Do I have the right to say “they need to be more patient/welcoming”? Probably I don’t - but equally I don’t fancy being someone’s emotional grounding.
So I will rather stay on the sidelines.
> I can see the other side of the coin as well - the need to maintain the code quality, and probably the burnout of multiple “stupid” questions/patches. I can imagine how it gets tiring especially if one does it in their spare time.
It gets tiring only if you despise answering these "basic" and/or seemingly "stupid" questions. In my day job I'm a system administrator of an HPC cluster, and we also do technical support ourselves. Users ask questions "wrong" all the time. Not enough information, seemingly simple details, etc. I personally never get mad at them, because they don't know how to do it better. We generally try to guide them, point to the correct places, test the problem ourselves, and see what happens, but never intentionally harass them.
You can maintain the code quality with a polite "Why this patch didn't pass the inspection" letter. There's a similar effort called "I downvoted because" [0], but even giving links from that page requires some niceness. Just pasting the relevant URL also looks and feels rude.
If a user is intentionally volatile, we defuse them. If they're intentionally malicious, we block/prevent them. If they're intentionally smarmy or snarky, they get polite but firm answers. At the end they cool down, because they cannot fuel their anger with our reactions.
> Do I have the right to say “they need to be more patient/welcoming”? Probably I don’t - but equally I don’t fancy being someone’s emotional grounding.
They don't need to be patient, if one is intentionally testing their patience. They don't need to be (overly) welcoming, but they need to be polite enough to tell that, or point the person to right way. Saying "no" is not a problem, but not pointing the next step is problematic, especially if the asking person doesn't know the better.
At the end, these behaviors are not because of the person asking the question, or sending in that "stupid" patch. It's about the person who's reacting to the patch/question/whatever. They don't like something, or see something and get triggered, then unload all the rage upon the asking person regardless of relevance of the rage.
For one, knowing oneself better is as essential knowing the stuff that you're working on. Having a baseline niceness is a win for everyone, because it makes life much simpler without softening boundaries. In fact, it strengthens them without making them intimidating.
[0] http://idownvotedbecau.se
I am responsible for my emotions, and my reaction to something is my problem. I get this.
Programming is creative. Just like artists, writers, any other creative process. We get emotionally involved with our work and we become emotionally vulnerable when we show our work to others.
So submitting code to the scrutiny of others is a vulnerable space for me. If the reaction of others is "this sucks" then I have a negative emotional reaction to that. I understand that this reaction is my problem, I'm not blaming the other person for their response, but I still have a negative emotional reaction.
I do not want to emotionally disassociate myself from my creative work so that I no longer have this reaction. I enjoy being this emotionally connected to my work.
I'd rather not show my work to others, or to only selected people who I can trust not to respond with something that will hurt me. I know this about myself.
8 replies →
> In my day job I'm a system administrator of an HPC cluster, and we also do technical support ourselves.
The difference is that you are paid to do that. You are not helping those people out of personal altruism, so wasted time is not lost. You did a successful job nonetheless.
If I on the other hand like to help people with coding problems in my free time, and they don't even bother to properly format the code they want me to look at, I'm wasting time if I still try to read it. My free time, and other peoples time that would need some help too.
1 reply →
I've had a similar experience when submitting a patch for an open source Google product.
Jumped through their hoops, was met with denial and skepticism of a problem hundreds of people were reporting, that is until one of the skeptical project members independently cited a standard that I had cited in my pull request. We go back and forth for two weeks to refine the pull request, where I am doing all of the revisions. Eventually they're given approval and I assume all is well.
About three months went by, their product is still broken so I check on the pull request and it appears that the relevant people tested and approved of my patch... but they wanted a test suite written for it. They expected me to write and submit tests for their broken product after spending a month of my free on their project.
I was left with feeling as though Google employees should just do their jobs if they want their products to work, as I'm not wasting any more of my time by doing work for them for free.
This is a sharp contrast with other projects I've contributed to, where the response has been "Thanks for pointing out a problem with our project, let's do everything we can to fix it" instead of an uphill battle that was my experience with Google.
If they want the tests to be written beforehand by the patch developer, they need to write that in the guidelines. If that isn't present in the guidelines, or they're not accepting patches to testing/building process, they should write these tests themselves.
Otherwise it's just the same thing as child labor. Unethical, ugly, and sad.