3 ms·

Do you think someone (with a programming background) can help in say, 2 to 4 hours by just jumping in, or am I going to cause more harm than good?

scrapcode 9y ago
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.
chris_wot 9y ago
Hop onto IRC - #libreoffice-dev on Freenode
buovjaga 9y ago
The first step is setting up the build environment on your operating system and completing a successful build. Depending on your computer, the build might run for 4 hours :) The articles on building are found in the General Programming Guidelines box in this index: https://wiki.documentfoundation.org/Development https://wiki.documentfoundation.org/Development Then you will want to pick an easy hack: https://wiki.documentfoundation.org/Development/EasyHacks https://wiki.documentfoundation.org/Development/EasyHacks Note that there are more challenging easy hacks marked by the difficultyInteresting keyword. This step also implies you will create an account on the Bugzilla. If the easy hack is not an ongoing thing, you should comment on the Bugzilla report about your desire to work on it and assign it to yourself and change status to ASSIGNED. If the easy hack is an ongoing task, you might want to check https://gerrit.libreoffice.org/ https://gerrit.libreoffice.org/ if there are some unmerged patches related to it by searching for message: and the bug number. This will allow you to be confident about avoiding duplicate work. To start working on your patch, you typically create a new branch: git checkout -b my-branch-name as advised in the "Sending a Patch to Gerrit" section of this: https://wiki.documentfoundation.org/Development/gerrit https://wiki.documentfoundation.org/Development/gerrit The topic of amending patches is dealt in this additional article: https://wiki.documentfoundation.org/Development/gerrit/SubmitPatch https://wiki.documentfoundation.org/Development/gerrit/Submi... Easy hacks come with mentors attached to them, so the patch reviews should not get stuck in a limbo. Regarding "normal" patches, they might sit there even for some weeks, but I hope the situation improves when TDF hires the new developer mentor(s): https://blog.documentfoundation.org/blog/2017/11/07/job-search-development-mentor-201711-01/ https://blog.documentfoundation.org/blog/2017/11/07/job-sear... Btw. there is a job search for feature implementation going on: https://blog.documentfoundation.org/blog/2018/01/16/tender-consultancy-libreoffice-feature-implementation-incl-site-development-training-201801-01/ https://blog.documentfoundation.org/blog/2018/01/16/tender-c...
tunareter 9y ago
Honestly: yes. LibreOffice is quite a friendly place, and there's even a list of beginner bugs that help with getting your foot in the door. They like new developers. It might take more than a few hours (e.g. you'll need to set up a dev environment - but the builds are quite robust nowadays unlike some projects), and the codebase is complicated - but contributing to LibreOffice was fun and helped me gain real world software experience. I'd only worked on small personal projects before LO. You definitely won't cause harm, and there are devs who will try to help you get your patch submitted. (They even employ someone to help new contributors get up to speed and to help get their patches in.) As chris_wot said, get on irc and people will generally be able to help you get set up. (IRC presence tends to vary by time and day, jfyi.)

scrapcode 9y ago

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.

chris_wot 9y ago

Hop onto IRC - #libreoffice-dev on Freenode

buovjaga 9y ago

The first step is setting up the build environment on your operating system and completing a successful build. Depending on your computer, the build might run for 4 hours :) The articles on building are found in the General Programming Guidelines box in this index: https://wiki.documentfoundation.org/Development https://wiki.documentfoundation.org/Development Then you will want to pick an easy hack: https://wiki.documentfoundation.org/Development/EasyHacks https://wiki.documentfoundation.org/Development/EasyHacks Note that there are more challenging easy hacks marked by the difficultyInteresting keyword. This step also implies you will create an account on the Bugzilla. If the easy hack is not an ongoing thing, you should comment on the Bugzilla report about your desire to work on it and assign it to yourself and change status to ASSIGNED. If the easy hack is an ongoing task, you might want to check https://gerrit.libreoffice.org/ https://gerrit.libreoffice.org/ if there are some unmerged patches related to it by searching for message: and the bug number. This will allow you to be confident about avoiding duplicate work. To start working on your patch, you typically create a new branch: git checkout -b my-branch-name as advised in the "Sending a Patch to Gerrit" section of this: https://wiki.documentfoundation.org/Development/gerrit https://wiki.documentfoundation.org/Development/gerrit The topic of amending patches is dealt in this additional article: https://wiki.documentfoundation.org/Development/gerrit/SubmitPatch https://wiki.documentfoundation.org/Development/gerrit/Submi... Easy hacks come with mentors attached to them, so the patch reviews should not get stuck in a limbo. Regarding "normal" patches, they might sit there even for some weeks, but I hope the situation improves when TDF hires the new developer mentor(s): https://blog.documentfoundation.org/blog/2017/11/07/job-search-development-mentor-201711-01/ https://blog.documentfoundation.org/blog/2017/11/07/job-sear... Btw. there is a job search for feature implementation going on: https://blog.documentfoundation.org/blog/2018/01/16/tender-consultancy-libreoffice-feature-implementation-incl-site-development-training-201801-01/ https://blog.documentfoundation.org/blog/2018/01/16/tender-c...

tunareter 9y ago

Honestly: yes. LibreOffice is quite a friendly place, and there's even a list of beginner bugs that help with getting your foot in the door. They like new developers. It might take more than a few hours (e.g. you'll need to set up a dev environment - but the builds are quite robust nowadays unlike some projects), and the codebase is complicated - but contributing to LibreOffice was fun and helped me gain real world software experience. I'd only worked on small personal projects before LO. You definitely won't cause harm, and there are devs who will try to help you get your patch submitted. (They even employ someone to help new contributors get up to speed and to help get their patches in.) As chris_wot said, get on irc and people will generally be able to help you get set up. (IRC presence tends to vary by time and day, jfyi.)