3 ms·

This articulates almost every experience I've had with trying to contribute my time to any open source project that has any size. I really think I've figured so

This articulates almost every experience I've had with trying to contribute my time to any open source project that has any size. I really think I've figured something out that'll help. I spend many hours getting X codebase to compile / work on my machine. I fix said issue and feel great about it! It never even gets looked at and/or it gets smashed to shreds with criticism by the same person that submitted the feature req / bug / whatnot.

Zancarius 9y ago
I feel you, especially as someone with a bit of social anxiety any time I think I'm doing something helpful or useful (like writing this comment), because that concern is always in the back of my head. I don't have any particularly good advice that you likely haven't read or heard before, but sometimes it's useful to read/hear it from others who've been in the same boat. In my experience, and this goes doubly so for small FOSS projects, you have to remember that it's someone else's baby. Maybe they were the person who started it, maybe they've been there since the early days, or maybe they have an unusually strong attachment or sense of ownership over whatever it is you're changing. At any rate, the moment you submit a patch, there's always the risk that it may be met with harsh criticism (sometimes deserved; sometimes not), and at least part of that may be the nature of the human psyche. So, the best defense is to do things by the book, if there's an established process, or failing that, persistence. Sometimes, just the existence of a patch in the wild--even if it isn't accepted by the developer--can be enough to motivate them toward a fix. I've seen plenty of relatively minor fixes get rejected only to be fixed hours later by a maintainer because the patch got them thinking. Let's be honest, even if it bruises the ego a little: As a user, I don't care how it gets fixed. I'm not in it for the glory. I just want it to work. There's of course the usual advice [1]: Keep your pull requests/patches short and targeted. Don't try to do too much, because larger, more widely reaching patches are likely to be ignored or turned down. Document what you can, why you did what you did, and what you intended to fix; but don't be too verbose (guilty, as you can see here!). Asking follow-up questions is instrumental if it's rejected, because there's probably something that was missed or overlooked. Of course, this doesn't obviate issues with projects that have a distinct lack of communication skills or toxic personalities. Ironically, I've had some luck with non-committal/non-responsive maintainers by forking small projects, applying my changes and moving on, only to find some weeks later that they want to pull my changes. In those cases, I never expected a fix--I just needed it to work yesterday--and I needed somewhere to publicly source the fixed copy from. That upstream wants the resolution as well is merely an added bonus. But the key is (polite) persistence. It's also the hardest to do if you don't want to seem rude or pushy. I also think that rejection and criticism play on our fear of failure (whether or not we admit it), which may kill participation. Just don't give up: Think of the other users who don't have your skill set to fix the underlying problem and consider that you're advocating for them! [1] https://www.atlassian.com/blog/git/written-unwritten-guide-pull-requests https://www.atlassian.com/blog/git/written-unwritten-guide-p...
- Vinnl 9y ago
  Well, skip the anxiety, because this is good advice :)
tunareter 9y ago
This doesn't have much relevance for LO. Devs there are generally welcoming. You'll still get honest feedback but they generally want your code in the codebase, and want to help you get it in a shape to land it.

Zancarius 9y ago

I feel you, especially as someone with a bit of social anxiety any time I think I'm doing something helpful or useful (like writing this comment), because that concern is always in the back of my head. I don't have any particularly good advice that you likely haven't read or heard before, but sometimes it's useful to read/hear it from others who've been in the same boat. In my experience, and this goes doubly so for small FOSS projects, you have to remember that it's someone else's baby. Maybe they were the person who started it, maybe they've been there since the early days, or maybe they have an unusually strong attachment or sense of ownership over whatever it is you're changing. At any rate, the moment you submit a patch, there's always the risk that it may be met with harsh criticism (sometimes deserved; sometimes not), and at least part of that may be the nature of the human psyche. So, the best defense is to do things by the book, if there's an established process, or failing that, persistence. Sometimes, just the existence of a patch in the wild--even if it isn't accepted by the developer--can be enough to motivate them toward a fix. I've seen plenty of relatively minor fixes get rejected only to be fixed hours later by a maintainer because the patch got them thinking. Let's be honest, even if it bruises the ego a little: As a user, I don't care how it gets fixed. I'm not in it for the glory. I just want it to work. There's of course the usual advice [1]: Keep your pull requests/patches short and targeted. Don't try to do too much, because larger, more widely reaching patches are likely to be ignored or turned down. Document what you can, why you did what you did, and what you intended to fix; but don't be too verbose (guilty, as you can see here!). Asking follow-up questions is instrumental if it's rejected, because there's probably something that was missed or overlooked. Of course, this doesn't obviate issues with projects that have a distinct lack of communication skills or toxic personalities. Ironically, I've had some luck with non-committal/non-responsive maintainers by forking small projects, applying my changes and moving on, only to find some weeks later that they want to pull my changes. In those cases, I never expected a fix--I just needed it to work yesterday--and I needed somewhere to publicly source the fixed copy from. That upstream wants the resolution as well is merely an added bonus. But the key is (polite) persistence. It's also the hardest to do if you don't want to seem rude or pushy. I also think that rejection and criticism play on our fear of failure (whether or not we admit it), which may kill participation. Just don't give up: Think of the other users who don't have your skill set to fix the underlying problem and consider that you're advocating for them! [1] https://www.atlassian.com/blog/git/written-unwritten-guide-pull-requests https://www.atlassian.com/blog/git/written-unwritten-guide-p...

Vinnl 9y ago
Well, skip the anxiety, because this is good advice :)

tunareter 9y ago

This doesn't have much relevance for LO. Devs there are generally welcoming. You'll still get honest feedback but they generally want your code in the codebase, and want to help you get it in a shape to land it.