I already wrote about my experience setting up a dual-boot system while I started the application process. I had a very busy month while I worked on contributions and submitted my final proposal. Last Tuesday I got the email that I have been selected as an Intern on the Public Lab project! I should probably make a post about how the rest of the application process went.

My first word of advice is to choose your top project candidates from the list of options ahead of time, then try to get the repositories installed and running on your system. Having to dual-boot my system on the day I wanted to start contributions was stressful! I also recommend really looking at the code base and trying to get familiar with it, it can take some time to understand what’s going on in a large project.

Once the repository was working I started looking for a small contribution to make. Make sure you read any instructions the organization has; Public Lab wants everyone to make a small, very easy first-timers-only issue as an introduction. Unfortunately there are going to be a lot of other people also looking for a beginners issue, so be patient and polite.

I made my first few small pull requests and felt pretty good about it. I’ve officially contributed to open source, hurrah! I wanted to show the mentors of the project that I am capable and skilled at code, friendly and helpful with others, and willing to listen to help and suggestions that they give. Public Lab really values cooperation and working as a team, it’s more than just submitting a contribution and being done. Then look around and decide what larger contributions you could make, both as a learning experience and also to show what you are capable of. I looked for something that was a challenge and a little intimidating, but not so complicated I would be completely stuck. I aimed to complete different types of issues: I had some in Rails, some CSS, and some Javascript. This not only was good to show my abilities, but also to remind myself that I am capable of taking on different challenges and succeeding!

I had prior experience using GIT for my own project, but I had never contributed to open source before. Public Lab has instructions and a posted Git Workflow; I don’t know if all open source projects have that available, but it sure is helpful! I also watched some videos on GIT (there are tons available on YouTube, I’m sure most are good). One that stood out was Advanced Git Tutorial. It really broke it down into the pieces I needed to understand (mostly) what was happening. Our workflow involves Rebase and I think it would be easy to just follow the instructions without understanding what it is really doing – and I don’t like not understanding the big picture. A big part of this internship process is challenging yourself to try new things and build new skills. Take the time to dig into subjects, figure out what’s going on.

Once I got some pull requests in I felt good about my chances but also very nervous about who else was applying. I stayed active all month, spending my time as if I was an intern and I was working on projects. I also spent a lot of time building my proposal, which required me to look at the work they wanted done and then break it down and organize it. I was unsure how that would translate in the real internship since Public Lab is using two interns to work on a group project, but I based my proposal on what I would do if I were working by myself.

The final application was due on Nov 4. It was a relief to be done with the proposal and have it out of my hands, but it was also a tough wait, not knowing if I was going to be working in December or not. On November 26 the emails were sent out and I learned that I had been selected for an internship spot! I began working on December 2; the project ends on March 3. I am working on integrating geolocation and mapping features on PublicLab.org! I am so excited to have this opportunity!

Tools I Am Using

I am using Notion to create a wiki page of notes and links to the project’s workflow, testing documentation, style guide, and planning posts. Initially I set up a To-Do template for listing the issues/pull requests I’m working on, but once we started the Outreachy project I used the Roadmap template. I love that it has space for notes on each issue, and I can add and remove properties to make it what I need. Plus I added my colleague intern so we can work on the project together and stay informed of each others progress.

One of the other tools I am using daily is the FireShot Chrome Extension screenshot tool. It gives you the option of saving an image of just the visible portion of the webpage, saving the entire webpage from top to bottom, or a selection chosen with the mouse. I am really happy with the free version. I know there are a lot of different screenshot tools out there, just find one that works for you because you will need it frequently when working in open source. Public Lab prefers to have a screenshot of any UI changes before merging anything, and of course it’s a very good idea to post a screenshot when you have discovered a bug, or when something you tried is having odd results. It is so much easier for someone to help you when they can see what is happening!

I have used Photoshop many times in the past for design and photography editing, so I figured I was all set. While creating my proposal I did use it for a few graphics, but most of the mockups and graphics I did in Adobe XD, which I am complete new to. I have to rave about it, it makes life so much easier! It automatically snaps to lining elements up and matching margins. It’s so quick to add text and rounded borders, to do all the things that we do for websites. You can do it in Photoshop, but it’s persnickety. The only downside to both apps is that I have to boot into Windows to use them – and my Windows installation is very sluggish at the moment, I think it needs a fresh install. But after my last experience with installing an OS I’m not feeling very eager!