Outreachy – Why, When, and How.

After three weeks as an Outreachy intern at Mozilla, I can say it’s definitely not been easy getting here, but it definitely was fun.

For those of you who haven’t heard about Outreachy, they offer 3 month long remote and paid internships in open source for underrepresented groups in tech, open to both students and non-students alike. Outreachy has two cohorts a year – one from May to August, and another from December to March; I had the luck to be selected for the May-August’18 round. Applications usually open in February and September, for the mid-year and end of year rounds respectively.

It’s recommended that you start the application process at least 2-3 weeks before the application deadline, but the earlier you start the better, obviously.

Once you’re done setting up an account and verifying your eligibility for the program, the process for getting selected as an intern is fairly straightforward –

1. Pick your projects
If you followed the above link, you’ll see that it’s recommended to only pick a couple of projects, tops. I’ve found that sticking to this guideline is pretty helpful as the rest of the process can be pretty time-intensive. Personally, I narrowed in on just one project. This proved to be the best course of action for me although it also meant putting all my eggs in one basket.
Picking projects and figuring out whether you can and want to work on them can be a daunting task. The setup needed for some projects is nothing more than a Github fork and clone away, while others may take a few hours to get working (read: installing/uninstalling libraries, messing around with symbolic links, and quite a bit of frustration)

2. Make a contribution
Outreachy requires that you make at least one contribution before you can apply to a project, but it helps to make smaller contributions throughout the application period.

Depending on the project, the mentor(s), and the community and your willingness to engage with it, a contribution can be anything from a series of small, logical steps you need to follow or a few days of messing around with the source and reading documentation.

You’ll notice I mentioned ‘willingness to engage with the community’. You might have to learn to talk to people on public channels (mailing lists, IRC). Being new and unsure of myself, a part of me found this terrifying – but don’t stress it!
Community members are almost always very nice and very helpful (I’m yet to find someone who’s even been remotely close to being rude), so don’t hesitate to reach out if you don’t understand something. Reaching out to your mentors or other members of the community can, at times, decide whether a fix takes a couple of hours or a couple of days.

No one expects you to disappear from the face of the planet for a week and only resurface once you’ve found the perfect solution. Collaboration is the backbone of open source. Code reviews exist for a reason. It’s nerve-wracking to put your code up for review (especially in cases where you know it doesn’t work), but it gives you a chance to have someone else read your code and point out things you might not know.
Like any internship, it’s an opportunity to learn. You aren’t expected to know everything, either. Don’t be too hard on yourself.

3. Record your contributions and write your application
I started working on my application at the last minute, and do not recommend it. The earlier you start, the better. Always.
I wasn’t sure how to go about writing an application and was pressed for time, so I wrote everything I could think of. I’d been contributing to my project for about three weeks by this point, and there were still things I didn’t understand.
Luckily James, my mentor, had already broken the project down into chunks so I just had to break them down into even smaller chunks, and that was my proposed timeline. Here’s what it looked like.

4. Wait.
Once you’re done applying and the deadline has passed, it’s almost as if life catches up to you again. I was in the middle of a semester at college when I started contributing to web-platform-tests. For me, it was the most ‘fun’ code I’d ever written – I was pretty invested in my work. It had reached a point where I’d completely ignored what was happening around me and missed enough deadlines to put my grades at risk. Not a smart move considering I’d only applied for one project and didn’t have anything else planned for the summer. It all turned out to be for the best, though – and that’s what matters the most at the end of it all.
Although this is just the beginning 🙂

Advertisements