Rookie Mistakes

When finding an issue to work on in an open source projects, it's very important to keep your own strengths and weaknesses in mind. Just because an issue says "good for first contributors" or "good first bug", doesn't mean it's necessarily for you.

...Well, not if you're working on a deadline, anyway. Which I am -- I was supposed to have fixed a bug by today in a project of my choice. Instead of a pull request, though, I've got 3 different projects in ember.js sitting on my hard-drive and a search history filled with queries along the lines of "ember.js basic routing examples". From hours of research, I've got a few measly lines to show for my effort -- and they're certainly not worthy of being pushed to a project.

All this because I didn't take a moment to think about my strengths.

The Bug

I spent the better part of a week looking for a bug to work on for my course, DPS909. It had to be something small -- I had only a week to work on it, and would be expected to find another small bug for the next week. And the next week. And the week after that.

Finding a small bug is easier said than done, though. Or at least, it was for me. There are a lot of projects that caught my eye, but none had issues that were suitable for beginners to tackle. I ended up browsing a bunch of repositories Github recommended to me, based on repositories I'd previously looked at. I will say, I wasn't so much concerned with what the project was -- the issues were all I was looking at. A cursory glance at the labels and issues, to see if there was anything suited for my skills. It took awhile, but eventually I found something in the ember.js repository that sounded right up my alley:

Fixing up documentation.

Before I go any further, I'd like to mention that I have never used ember.js before. I have used a few other Javascript frameworks, though -- namely AngularJS, ReactJS, and Vue. ember.js didn't seem all that different from them; it produced single page applications, made us of components, used JavaScript... And so on. I was sure it wouldn't be too hard to figure out.

Of course, I was wrong. But hindsight is 20/20, and I signed up to help with documentation for a method called "isActive" without digging deeper into what ember.js was.

The Process

It took about 30 minutes for me to figure out that I'd probably bitten off more than I could chew. Initially, I figured that I'd just whip up a little ember.js app and test out isActive() myself. After setting up my "little" test app, though, I realized I was way in over my head. The app was structured in a very specific way that, I'll admit, was a little overwhelming to look at. Folders for templates, controllers, helpers and routes, and other things that I wasn't familiar with in the context of ember.js. In the context of AngularJS? I knew what all that meant. But ember.js is a different kind of beast, and I found myself way in over my head.

It was time to hit the docs and figure out exactly what I needed to do to get a working application going. Like a lot of the popular JS frameworks, ember.js has a CLI to make building apps a bit easier, but that doesn't make it easier to understand what's going on in the app. At the time I'm writing this, I've spent about five hours going through the documentation and trying to figure out how to use ember.js' router service, and by extension, isActive. This has led me to research a lot of different things -- mostly routing related, though I've had to look at components, models, and many other pages too.

In the end, I've managed to figure out most of what makes isActive tick. There's still one parameter left to figure out -- mostly because it involves researching models in ember.js -- and then I can finally get to writing out the documentation that I promised to do.

Moving Forward

I've definitely learned some valuable lessons from this -- namely, don't offer to work on a decently in-depth part of the documentation for something you've never used. Or at least, not when you're working on a deadline, and don't have the time to spare for more in-depth research. You might argue that this is common sense. I'm inclined to agree. But it's easy to lose sight of things like this when you're under pressure to find and fix a bug within a week's time. Suddenly the only thing that matters is the presence of the "good first issue" label (or something similar).

That's not to say I regret choosing this issue to work on. This has been a very valuable learning experience, both with regards to open source development and working with ember.js. I've learned how to better pick my issues... And also the basics of ember.js, expanding my knowledge of JS frameworks. Not bad, all things considered.

An Addendum

Adding an addendum to a post that's not even published yet probably seems a little weird. When I was writing this post, though, I was fully expecting not to finish my work in time to make a pull request by the end of today. This morning, however, I had a bit of a break through and managed to finish off the bulk of the documentation I'd promised to write -- now I'm just waiting on some feedback on how to improve it. You can check out my pull request for it here.

Anyway, with the post already written, I didn't want to go back and rewrite it into something new now that I'd gotten a PR up. I like the original post, and I think it's a good reflection of what this experience has been like for me.