Comment by fefe23
7 years ago
I see this pattern regularly and I always wonder: why would you deny yourself the opportunity to improve?
If you have a patch, and others know how to make it better, why would you forgo that chance to learn something?
What good can possibly come out of "I'll just hide in my shed" and tell nobody about my patch (that is what the OP recommended, invite-only repositories).
You submitting patches has nothing to do with the community. You submitting patches has everything to do with:
a) improving the patch to maximize its usefulness
b) the project becoming better
c) you becoming better
d) the project taking over maintenance of your patch so you don't have to.
It's a win-win for everybody.
If I have patched the code to scratch an itch of mine, by the time I submit the patch my itch is scratched - no subsequent changes will contribute to scratching my itch, no matter how good they are.
At the same time, many open source projects are subject to constraints or requirements that are entirely reasonable from their perspective but that take time and don't much help or educate me as a one-off contributor.
For example:
* Paperwork like contributor license agreements
* Supporting obsolete (or nearly obsolete) platforms, and avoiding modern language features to maintain that support.
* Compatibility with project features I don't use, but other people do.
* Getting all the integration and test features of a finicky build pipeline to work, not just those needed to make a build.
* Correctly dividing up changes in multiple areas into multiple patches reflecting the fact different changes will need to be reviewed by different people.
* Requirements like code style and automated test coverage that contribute statistically to lower bug counts at the project level, but that don't reveal any bugs in my specific contribution.
* Code structure issues specific to the project, which as a one-shot contributor it isn't productive for the project to educate me about.
* Conflicts with planned future changes that aren't really documented very well anywhere - or that are documented only in places I didn't find, like the archives of a high-traffic mailing list.
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
11 replies →
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.
The benefit of taking that particular avenue to improve oneself might be overshadowed by the potential downsides of having to deal with toxic people to get there. And that's a personal scale-weighing that everyone has to do for themselves. There's no objective right or wrong in that.
Everyone is toxic to someone. Avoiding every toxic person is just crippiling you socially, professionally. You have to meet challenges head on, or you are just lazy, and blaming the topic du jour. The ideal welcoming working group is a great goal, but we are humans, and always striving. To stop progress because its hard or annoying just shows your character.
> Everyone is toxic to someone.
I'm not known for my positive view of humanity, but I don't believe that's true at all. "Toxic" doesn't apply to anyone short of a true saint. It's meant for people who exhibit specific behaviors that undermine others' confidence, satisfaction, etc. If a person X who seems above average in collaborative and supportive behavior to everyone else has a single bad interaction with another person Y, does that make X toxic? Of course not. It probably means Y is toxic, and is projecting their own toxicity onto others. Who's the lazy one? Who's evading responsibility for their own outcomes? Whose character does that reflect on?
The time spent "improving" in the terms of the project is time not spent improving in areas that matter to you (or your employer) more. If the fix works and the itch is scratched, extra time spent developing specialized knowledge about that project's build/test systems or standards or personalities for is likely not time well spent, especially if the likelihood of submitting a second patch to the same upstream is low. If you plan to keep contributing over the long term then sure, but that's not the only case.
Honestly, aside from issues with the process it's also just embarrassing. IMO, that's what is causing a lot of the issues that are being surfaced these days in oss. No one likes to be told they're ignorant. Add in a smarmy attitude and poor social skills and only the most confident or skilled people will contribute; which isn't a bad thing to be honest.
We've come a long way from the RTFM days but learning something as complicated as programming tends to make people sensitive about what they do and don't know.
It's a delicate balance. On one hand the project and the community benefits from a lot of ideas. On the other hand, a strong ego with poor understanding can not only destroy a project, they can cost a lot of people a lot of time, money, and heartache so some sort of barrier to entry that turns some people away isn't a bad thing.
At the end of the day, it'll all work itself out as long as we keep the projects open and free. Popular projects attract talent which in turn improve those projects.
> Add in a smarmy attitude and poor social skills and only the most confident or skilled people will contribute; which isn't a bad thing to be honest.
Personally I'm playing with computers since Commodore64 days. I'm occasionally publishing papers about algorithms that solve real problems that I develop (just submitted one yesterday). I'm confident about my skills, and generally know about my stuff, however I don't like uncivilized brawl.
So to be able to be a developer whose patches to be accepted, I need to be a person who can put up with snarky comments, and be able to return them with the same level of abusiveness?
Sorry. Life is too short for that.
> Add in a smarmy attitude and poor social skills and only the most confident or skilled people will contribute; which isn't a bad thing to be honest.
It is a bad thing, because the "most confident" and the "most skilled" are almost never the same.
Theoretically, rude gatekeeping can destroy confidence, but it can't really destroy skill. Of course, the rude gatekeepers typically don't recognize skill either...
"...and only the most confident or skilled people will contribute; which isn't a bad thing to be honest...some sort of barrier to entry that turns some people away isn't a bad thing"
Confidence (or as I look at it, social pain threshold) is unrelated to skill.
>If you have a patch, and others know how to make it better, why would you forgo that chance to learn something?
Maybe because there is not much to learn from people who cannot give you feedback about your patch without calling you an idiot, or making sure that they show that they are above your level.
Because in toxic projects, they are not about teaching you something. And because the only thing you learn is to never contribute to a toxic project again.
Also, why don't you try to create a github account, where you disguising yourself anything but a white guy, and start to contribute. Or just ask any female developer about their experiences.
>You submitting patches has nothing to do with the community.
If you seriously believe this is true, you have no idea about software development.
Your patch might not fit the projects guidelines, but work fine for what you are trying to do. Maybe it even is a hack, which only works in your case. There's also the possibility of time pressure, or just not wanting to deal with possibily snarky comments.
Probably because, if there's a real bug, the patch is by definition an improvement even if the whitespace isn't to everybody's liking?
The tech community has pivoted hard to an obsession with the superficial in recent years. I'm not gonna do 10 iterations of catering to someone's personal tastes in order to do them a favor. They can take it or leave it.
It’s also that if the guidelines about the whitespace are so important, just automate the thing.
I like quite a lot the approach taken at my $dayjob: the files that you change must not change if one uses ‘indent’ twice on them (twice because some of indent’s opinions are bistable). And there is a script that brings the non compliant files to compliant state.
So I don’t have to think of whitespacing at all while coding and can make “good” before submitting. And, even if I don’t like that particular style of whitespacing, I do admit the code which is uniformly whitespaced is easier to read and maintain.
I really like how a number of languages now have a code formatter built in (Elixir, Go(?)). I might not always like how it formats my code, but most of the time I do. Furthermore, it:
1) spares everyone a whole bunch of bike-shedding and bickering
2) often teaches me how to better format my code
3) speeds up my work slightly because quite often I can just messily write my code and rely on the formatter to fix it.
There was an upvoted article on HN the other day [1] where the gist of it was:
"If you don't have a separate documentation website for your open-source project, it's not worth my time."
This is as superficial as it gets.
[1] https://news.ycombinator.com/item?id=18150876
Wow that whole thread is awful. So much entitlement, so much inaccuracy, so little insight.
I take your point but good documentation is not superficial.
1 reply →
d is the only one that the people paying me care about.
The benefit of not dealing with upstream is that I can get more done that they do care about.
I also got burned in a case where I was added to a project as a maintainer and then the original maintainer disappeared, 10 years later I am still getting support requests on a project I just submitted bug fixes for.