There are so many incredible quotes in this piece. :)
Contributing to open source should be the goal, it should be the means by which you achieve other goals.
This is indeed very insightful. I also see a lot of « Just look for projects » advice, and for me it never worked either. The projects I’ve contributed to were mostly libraires I used in which I found issues that needed fixing. I think this approach works really well, especially once you:
Stop seeing open source as being fundamentally different from everything else. It's not.
As for #6, and I speak more as maintainer here, I think proactively posting a snippet of the patch / workaround you used can be super helpful, both to the maintainers (they don’t have to ask you again!) and to other people who may lookup the issue because they’ve encountered the same problem.
Also, for feature requests, it can be a good idea to take some time and think about the exact API you want. It’s okay to start with « Is there are way to do X? », but what’s even better is to show how you would like the library/framework/tool to help you do X, and ideally include code snippets of that. Again, it helps maintainers better seize your problem and whether it’s in the scope of their project.
Great points, thank you! I agree with all of it, but I’m especially keen on posting your solution so other people with the same problem can find it.
I don’t think I emphasized enough how important i think it is to create issues. It serves not only as a means of communicating with maintainers but also as a form of documentation. A sort of living FAQ mixed with “known issues”.
Thanks again for your comment :).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There are so many incredible quotes in this piece. :)
This is indeed very insightful. I also see a lot of « Just look for projects » advice, and for me it never worked either. The projects I’ve contributed to were mostly libraires I used in which I found issues that needed fixing. I think this approach works really well, especially once you:
As for #6, and I speak more as maintainer here, I think proactively posting a snippet of the patch / workaround you used can be super helpful, both to the maintainers (they don’t have to ask you again!) and to other people who may lookup the issue because they’ve encountered the same problem.
Also, for feature requests, it can be a good idea to take some time and think about the exact API you want. It’s okay to start with « Is there are way to do X? », but what’s even better is to show how you would like the library/framework/tool to help you do X, and ideally include code snippets of that. Again, it helps maintainers better seize your problem and whether it’s in the scope of their project.
Anyway, thanks for this great post!
Great points, thank you! I agree with all of it, but I’m especially keen on posting your solution so other people with the same problem can find it.
I don’t think I emphasized enough how important i think it is to create issues. It serves not only as a means of communicating with maintainers but also as a form of documentation. A sort of living FAQ mixed with “known issues”.
Thanks again for your comment :).