I want to start contributing to open source. I think I know the mechanics of doing so. I have also skimmed through Open Source Resources for Beginners posted by @jess which I'll use the sources she provided to find projects. I have few questions
- After I contribute first time, am I illegible for
first-time-onlyissues any more? How aboutbeginnerissues? - Should I ask whether I can work on the issue every time I want to do so?
- What happens if I claim the responsibility of wanting to solve an issue and after few days of trying I can't? Is it a bad thing to start the open source "career" as the guy that can't finish?
- Do I do anything if I have contributed but after a week the pull request hasn't been accepted?
- How about me taking the initiative of: correcting spelling, adding instructions to the readme, or (my favorite) creating demos. Should I just open an "issue" (even though it's not technically an issue) and ask if they want it, or should I just make the pull request and see what happens?
- Relating to question 5 (more for the github interface maybe), if I want to ask the owner "hey I see you made a function that let's you scroll to an element, but you haven't provided a demo, would you like me to do it" do I open an issue (even though it's not) or reach out to them through email or what ever else. Or is it ever a good idea just to make a pull request with a message and let them decide whether they want it
Context that made me ask the above:
I made my first contribution a week a go, I asked whether they wanted their document translated to Albanian, they said yes, but nothing happened after I made the pull request - everything fine in my end (hence question 4). Github timeline thing says that I made the first pull request (fireworks and everything)
Few days a go I found a fantastic issue, the owner had made it especially for beginners, it was as simple as adding two lines of code. But I had never come across of that issue before. I would have solved it with a bit of research. 23 hours later, I check back and they owner had solved it (which is fine) (hence question 3), in this case I know I would have solved it, but for the future what's the best thing to do.
Two more, sort of, unrelated questions:
- I read that new contributors should blog about it. I do not get that, what would I blog about? Isn't that just a tweet's worth of content "I contributed yet again". I'm serious, I'd love to get into this in every way I can!
- I've had few personal goals I needed to solve hence programming has been a hobby till now, as I start looking for work, do these contributions go on my CV under "work experience"?
Hope this made sense.
Thanks devs
Latest comments (8)
My first contribution has just been accepted.
I'm so happy.
I thought of shouting it from my bedroom window but no one would know what I'm talking about. So here it is.
My first contribution was a translation to Albanian. A perfect little thing to get me used to the mechanics of it all
Also, thanks again to all of you for the very helpful replies. To be honest I couldn't think about contributing without seeing the first one to the end. Now I'll re-read all the comments and get to work
Thanks devs :)
Though it looks like you've gotten some pretty detailed responses already, I think these questions are shared by a lot of open source contributors, so I'll give my input on things that I've observed or experienced personally.
While I definitely wouldn't say that it's required, by showing interest in addressing an issue you can potentially save yourself or others some time by ensuring that someone isn't already actively addressing the issue.
I know that this can seem daunting, but I've found that if you revisit the issue and explain your attempted method and where you're getting stuck, another contributor may be able to relate and help you get back on track or your explanation may potentially help others solve the issue.
This is something I've encountered quite a few times and I've found that sometimes with a bit of investigation, you can usually tell whether the repo is either no longer being maintained or if your pull request has just gone unnoticed by the project maintainers.
Though, in either scenario, it can be helpful to @mention one of the project maintainers to ensure that they are notified of your pull request.
I would say that the obligation to open an issue with the suggestion probably depends on the subjectivity or size of the addition or change. Additionally, many projects have various flags for issues that aren't necessarily "issues" that maintainers can apply.
Also, to address a point in #6, I would personally avoid emailing the repo maintainer unless they have explicitly stated that emails are welcome somewhere in the project's documentation.
I hadn't heard this, but I can see how relatable testimonials from new contributors could make others feel more comfortable contributing themselves.
I've wondered this same thing. The conclusion I've come to is that if you feel like your CV is lacking other relevant work experience or your contributions have been sizable, then I would include them. Otherwise, I would expect that they'd visit your GitHub (which you should definitely include) if they're interested in seeing your open source contributions.
Hope this helps!
Thanks for the comment. I found it very useful.
Leave them for others if they're not impeding you and there are other people regularly taking beginner-level issues on. If it's causing you trouble or if the project is smaller and less active then it's not a big deal.
If it's going to take you a while to address the issue, or if issues tend to be resolved very quickly, it's a good idea to at least comment and say you're going to work on it so you're not stepping on anyone's toes and vice versa. Otherwise, nobody's ever gotten upset because someone opened a pull request out of the blue.
It happens more often than you think. People get in over their heads or just don't have as much time as they thought. It's not a big deal, but it's good to leave a comment to that effect so someone else can take it on.
You can comment to ask the maintainer(s) if there's anything standing in the way of getting your pull request merged. In less active projects you may be SOL, in which case consider forking if your change is really important.
For small fixes and documentation, you can drop a pull request right away. For anything big, it's a good idea to open an issue first to make sure your idea is in line with what the maintainer(s) want for the project.
The issue tracker should be your first mode of communication, and that's a perfectly fine question to ask. Bugs are only one type of issue. Try email if you don't get a response there.
There are going to be plenty of things it's not worth writing about, but if you learned something you can teach it to others. That's where the blog posts are.
A "work experience" section is more for jobs you get paid for. You can mention that you contribute to open source in your summary, or if you've made substantial contributions you could talk about those in a "major projects" section. Minor contributions are best as interview fodder (and they're really good for that).
@aarohmankad 's answers seem pretty spot on to me. There are no universal rules. Common courtesy usually applies. If the project doesn't have a clear contribution guideline that covers all of this stuff, chances are anything's fine as soon as you are polite.
first-time-only/beginnerissues are usually for people who are still getting started with contributions to open source. Once you feel you've made enough progress to tackle more complex issues, leave thebeginnerissues for beginners!Sure! You could either indicate interest ("Hey this looks interesting, are you looking for a contributor?") or comment on the issue once you've submitted a pull request ("Hey took a look at this, does this solution seem fair?")
I typically open a pull request as soon as I start working, so that if someone wants to help me solve the issue, they can help on my branch. Also there's nothing wrong with only finishing part-way. You still learned a lot and (hopefully) provided some value to the owner of the repo!
You can try pinging the owner to take a look at it, but the best thing to do might just be to wait for them to merge when they can.
Making an issue is fine! In my experience, open source maintainers love when people contribute to docs or make a demo. (These are usually the things they don't have time for!)
See question above.
This is very informative and encouraging. I'm glad I asked
Just wanted to share this additional resource that @bekka put together:
Wrap it up: Being a Good Citizen of Open Source by #devDiscuss
Rebecca