> There’s no certification, ceremony, or merit badge that says, “you’re ready to contribute to OSS”.
I strongly believe that everyone, and I mean everyone, is ready to contribute to OSS. On the Python project, Jesse Noller recently started a "core mentorship" group to help people put the rubber to the road. There's an almost endless amount of work to be done on CPython, and we'll literally take anyone with any amount of knowledge and help them contribute. Whether it's people contributing to OSS for the first time, or people new to contributing to Python, we can find something.
If you understand English, you can write documentation. If you can write Python code, which is obviously a common skill for someone interested in contributing to Python, there's plenty of work. If you know C, dig right in.
The group of core contributors ranges from 18 to the upper 60s, from the self-taught to multi-PhDs, from students to Googlers. I think the only people who aren't ready to contribute, wouldn't be interested in contributing in the first place.
> It’s not obvious where to start.
This is definitely an issue for a lot of projects, and as mentioned above for CPython, the core mentorship group is hoping to tackle this.
Online and in person, I've pointed countless amounts of newcomers to the "easy" bugs list on our tracker, but that's not always a great starting point. Half of the issues are a 35 comment bikeshed, but it's tagged as "easy" because the end result will probably be a 2 line change. The other half of the issues are easy, but in uninteresting corners of obscure modules.
I've had success leading newcomers at the PyCon sprint to start with test coverage, and I think that approach worked pretty well. You can't get too far without writing tests anyways, so it's a good educational step that you can even take back to your day job if you aren't already doing so. Additionally, it's a task that gives you a tangible sense of accomplishment. Being able to fix bugs is cool, but often they are very low impact. Being able to say you raised test coverage from 30% to 70% is nothing to shrug at.
Having early success is key to having continued fun on the project. No one wants to spend their evening working on a patch to have it rejected and shot down -- that's not fun. My approach, and one I also suggest to some first-timers, is to start with documentation. You can bang out 10 successful doc patches a lot easier than you can do 10 successful code changes. In order to get some attention to yourself, find the easiest way in the team and stick with it a bit before branching out.
> Guidelines often make a maintainer’s life easier, and mine harder.
I can certainly feel for this, and speaking for CPython, I think we've tried to keep the guidelines simple and well documented. Overall, the process doesn't deviate too far from "write it, review it, commit it", when it comes to being an external contributor. Once you have commit access, some of the source control process gets hairy, but it mostly stays out of your way and lets you do the work.
> Open source is for people who are better at this than me.
I'd put myself on the bottom of the pile both on the CPython team and at my day job. I told my dad programming was stupid when I was in high school, I barely got by in college, and finally found myself the first year on the job. I'm not a bad developer by any means, but I'm not blowing the doors off of companies when I interview with them. I just like what I do and I have fun doing it -- I think a lot of the people involved in this stuff are probably the same way.
> Trying to contribute and failing makes me feel stupid.
Failure sucks, straight up. It especially sucks when it's on an open source project that you're trying to help in your free time outside of work. It's not news that you're going to fail from time to time, but something that worked for me and apparently some people I've helped was choosing the right thing to work on. I touched on it earlier, but fixing 5 small easy things sometimes looks better to a maintainer than fixing 1 regular thing. If you start with that approach, soon you'll have 15 successful pull requests and may feel more confident to dive into deeper and harder things, and the maintainer may have more confidence that you can offer quality work for those harder things.
> There’s no time.
Time is the biggest bottleneck in open source. Not only do you have a kid, job, and responsibilities, everyone else does too. Submitting a patch or a pull request only to have it sit un-noticed for months sucks. The only way to get it through the system is more time. I don't know of any really good solutions on the maintainer side other than quitting everything and going full steam on the project, but that's clearly not viable :)
> It’s pretty lonely.
The CPython core mentors group aims to fix that. I don't remember the numbers off the top of my head, but the ratio of core contributors to new outsiders is pretty tight, and we've helped a bunch of interested contributors get their work accepted. Your average 1-man project might not be able to do this, but we've tried to make a group available for those who need a helping hand on Python.
An important piece to this that isn't mentioned is filing bug reports, good bug reports. If you track down where some fails, figure out why, and find the smallest, easiest set of steps to reproduce, you have helped the developers a lot. Even you don't know how to fix it, or know that the fix is not trivial, the developer now has a great place to start.
I have created several bug reports for Django where I pointed where it fails and even offered "bad" solutions in the description. I rarely provide a true patch because I don't have the latest of Django and rarely have the time to check it out, create a patch and tests. In the few cases that I have, my patch hasn't been used because the developers, in the wisdom, found better solution, usually very similar to mine, but more thought out or handling other cases I wasn't aware of. This doesn't bother me, because the developers are never hostile over proposed solutions, in fact they have been appreciative for the help in a starting point.
Very good point. The worst report is the one that isn't written, so any report we receive we're thankful for. Doing the things you said like finding the smallest steps to reproduce or a test case are a big help. This is an area that didn't come up in the original article, but I'm thinking about doing some further writing on the topic and writing bug reports are certainly worthy of significant mention.
This is spot on. I'm a contributor noob and when I search bug trackers for an issue I'm experiencing I run across a lot of reports like, "the user profile page is broken". That's not helpful to anyone. I'll then submit a detailed bug with detailed steps to reproduce, php errors generated, etc.
I adore Python and the general ethos of the community. I can be a bit of a sideliner and I usually don't have a lot of spare time - when I do I fritter it away playing with code and general programmer style procrastination. On a number of occasions I've thought it would be nice to contribute to Python in some way. I just didn't know how, if I could, or what the barrier for entry was.
This is one of the most encouraging things I've read in regards to getting my finger out and starting to give something back. You've sparked my interest and I will definitely be looking at this and seeing how I can contribute and get involved.
If you understand English, you can write documentation.
The bar is a lot higher than that. You have to understand English and understand the functions themselves. Sometimes even getting bullet-point list of functionality out of devs is like pulling teeth - leaving you with nothing to document in the first place. Similarly an understanding of why something was designed a certain way helps angle the documentation more accurately.
Clean documentation is hard, and doubly so if you're not the person who wrote X module for OpenFoo.
> The bar is a lot higher than that. You have to understand English and understand the functions themselves.
In general, you're certainly correct. I was thinking too much about Python, where there's a strict but easy to follow guideline that all public APIs are documented, so the lowest level work has already been done. Because of that, there aren't a ton of places where you'd need a super deep understanding of the code in question to make a documentation impact. A lot of it is updating, removing, and reformatting. You'll see a lot more "reformat this paragraph as a table" issues than "write the whole doc for the wizbang module", the former being a fairly easy task.
Also if you understand the project well enough to write documentation you have to have the ability to put yourself into a new user's position. Many people lack this ability and create just unusable docs.
Agreed. It's a hard skill even when you're trying consciously. One way to improve the situation is to actually give your draft documentation to a trusted user for feedback. I've been lucky enough to have an enthusiastic user in-house who has road-tested some of my documentation, and it's much better for the exercise.
After you are setup there, http://bugs.python.org/ is the bug tracker. Bugs are sorted newest first, and there are a bunch of queries on the left side of the page, plus a query builder. The search feature works fairly well, and I sometimes suggest that people search modules they are comfortable with. If you use zipfile a lot, search it, and you'll find 46 issues.
In addition to that stuff, as Jesse mentioned in one of the responses, http://pythonmentors.com/ is the mentor site. There's a mailing list you're more than welcome to join should you have any questions, comments, or anything about the process. We can help you get setup, help you figure out what to work on, and help you successfully contribute your work.
This has motivated me to somehow contribute to Python now. Although I have been Python/Perl programmer for a while. Other projects need this sort of stuff to attract contributors.
Will be nice if Perl can also do this. This will help Perl 6 efforts a lot.
With Leiningen, my Clojure project (http://github.com/technomancy/leiningen) I make an effort to periodically publish any "low-hanging fruit" TODOs that are suitable for newcomers to implement. There hasn't been as much recently since most of that kind of thing has been implemented, but explicitly calling out those places has helped a lot in the past.
I think stuff like this is great. I was interested in contributing to this project years ago before I really knew how to program very well. I still have never contributed to OSS, or anything like that. I will have a guilty conscience if I don't now.
I strongly believe that everyone, and I mean everyone, is ready to contribute to OSS. On the Python project, Jesse Noller recently started a "core mentorship" group to help people put the rubber to the road. There's an almost endless amount of work to be done on CPython, and we'll literally take anyone with any amount of knowledge and help them contribute. Whether it's people contributing to OSS for the first time, or people new to contributing to Python, we can find something.
If you understand English, you can write documentation. If you can write Python code, which is obviously a common skill for someone interested in contributing to Python, there's plenty of work. If you know C, dig right in.
The group of core contributors ranges from 18 to the upper 60s, from the self-taught to multi-PhDs, from students to Googlers. I think the only people who aren't ready to contribute, wouldn't be interested in contributing in the first place.
> It’s not obvious where to start.
This is definitely an issue for a lot of projects, and as mentioned above for CPython, the core mentorship group is hoping to tackle this.
Online and in person, I've pointed countless amounts of newcomers to the "easy" bugs list on our tracker, but that's not always a great starting point. Half of the issues are a 35 comment bikeshed, but it's tagged as "easy" because the end result will probably be a 2 line change. The other half of the issues are easy, but in uninteresting corners of obscure modules.
I've had success leading newcomers at the PyCon sprint to start with test coverage, and I think that approach worked pretty well. You can't get too far without writing tests anyways, so it's a good educational step that you can even take back to your day job if you aren't already doing so. Additionally, it's a task that gives you a tangible sense of accomplishment. Being able to fix bugs is cool, but often they are very low impact. Being able to say you raised test coverage from 30% to 70% is nothing to shrug at.
Having early success is key to having continued fun on the project. No one wants to spend their evening working on a patch to have it rejected and shot down -- that's not fun. My approach, and one I also suggest to some first-timers, is to start with documentation. You can bang out 10 successful doc patches a lot easier than you can do 10 successful code changes. In order to get some attention to yourself, find the easiest way in the team and stick with it a bit before branching out.
> Guidelines often make a maintainer’s life easier, and mine harder.
I can certainly feel for this, and speaking for CPython, I think we've tried to keep the guidelines simple and well documented. Overall, the process doesn't deviate too far from "write it, review it, commit it", when it comes to being an external contributor. Once you have commit access, some of the source control process gets hairy, but it mostly stays out of your way and lets you do the work.
> Open source is for people who are better at this than me.
I'd put myself on the bottom of the pile both on the CPython team and at my day job. I told my dad programming was stupid when I was in high school, I barely got by in college, and finally found myself the first year on the job. I'm not a bad developer by any means, but I'm not blowing the doors off of companies when I interview with them. I just like what I do and I have fun doing it -- I think a lot of the people involved in this stuff are probably the same way.
> Trying to contribute and failing makes me feel stupid.
Failure sucks, straight up. It especially sucks when it's on an open source project that you're trying to help in your free time outside of work. It's not news that you're going to fail from time to time, but something that worked for me and apparently some people I've helped was choosing the right thing to work on. I touched on it earlier, but fixing 5 small easy things sometimes looks better to a maintainer than fixing 1 regular thing. If you start with that approach, soon you'll have 15 successful pull requests and may feel more confident to dive into deeper and harder things, and the maintainer may have more confidence that you can offer quality work for those harder things.
> There’s no time.
Time is the biggest bottleneck in open source. Not only do you have a kid, job, and responsibilities, everyone else does too. Submitting a patch or a pull request only to have it sit un-noticed for months sucks. The only way to get it through the system is more time. I don't know of any really good solutions on the maintainer side other than quitting everything and going full steam on the project, but that's clearly not viable :)
> It’s pretty lonely.
The CPython core mentors group aims to fix that. I don't remember the numbers off the top of my head, but the ratio of core contributors to new outsiders is pretty tight, and we've helped a bunch of interested contributors get their work accepted. Your average 1-man project might not be able to do this, but we've tried to make a group available for those who need a helping hand on Python.