Hello folks and welcome to the eighth edition of the interview series “I contribute to Ember” , presented by the folks at The Ember Times 
This week we’d like to highlight the work of contributor @kategengler who talks about addon observations, RFC tracking, effective collaboration and how all kinds of contribution to Ember really matter.
How did you get started with using Ember?
There were a couple of interns at my job at the time who were given the assignment to experiment with different JavaScript frameworks. One of those they chose was SproutCore or what was gonna be the next version of SproutCore, but then later became Ember. […] Maybe 6 months or a year later, they released a [first] version of Ember and I decided to use it for a new project we were building. I didn’t know anybody in Ember and I just read about it on HackerNews and Twitter and decided to use it.
What are you working on right now in regards to contributing to Ember?
I have a lot of projects in the air, so that’s an interesting one. So recently I finished up the Request for Comments (RFC) RFC (#300) which was to change the RFC process, and I’ve been doing various things to implement that RFC, specifically tracking merged RFCs. And that’s one of the biggest things I’ve been working on in Ember. I also do the weekly releases of Ember.js. And I also maintain EmberObserver.com, which is my project, it’s not strictly an Ember project, but it’s very much about Ember; so I review all the addons as they are published, categorize them, score them, and maintain the site. And in terms of Ember CLI, the main thing I’m working on is maintaining ember-try.
Was there something really interesting or surprising when working on ember-try?
Well, ember-try works by changing package.json and running npm install (or yarn ). Dependency management is always full of surprises. Different versions of npm, yarn, and node all work differently, so there’ve been some surprises.
[Another interesting thing] about ember-try: Originally, a lot of these libraries that ember-try uses today did not exist in npm. There’s one called execa that has a lot of functionality that originally had to be built into ember-try and now we can use this library rather than doing the work ourselves. And that’s really nice.
The ecosystem has grown up around us, so we don’t have to do that much for ourselves anymore. For the same reason, you might use Ember for the frontend so you don’t have to do a lot of the groundwork yourself.
Do you remember your first contribution to Ember and community?
I think the first thing I did was writing the first acceptance testing guide. I paired with Jo Liss on some of it. Because I had been working at a startup together with Jo and she gave a talk at the very first EmberCamp - [her talk] was about testing. […] Yeah, I think [my very first contribution] must have been to the Guides.
What motivated you to do that?
So, Jo and I were working together at the time on Ember app embedded in a Rails app. And we had been using a Rails JavaScript testing framework, the name of which I have forgotten. We had this great test suite for our app. And then - Ember changed, as pre-release software does, and we could no longer get that framework to work with Ember. Ember later added tools for acceptance testing and somebody suggested I document it, so I think that would be how I made that first contribution.
Do you have any piece of advice for first-time contributors?
So I remember trying to contribute and feeling like I didn’t know what I should do. Some of the things that felt easiest for me to do off the bat were things that were like refactors because they didn’t really require domain knowledge. But then I also was wary because I was worried that I would work on a refactor that nobody wanted, or that I would change code that was written that way for performance reasons or something like that.
And so I think that might be part of why I started with contributing to the documentation because I felt that if the documentation wasn’t clear to me, it wasn’t clear to somebody else (it’s not always true, but [often it is]). So I would say if you find something small and manageable that you can do in an hour or two to just make that first contribution. And then after you do that the next contribution will be so much easier. After my [my first contribution] — I remember staying up all night to write it […] — after I did that I started to contribute to more things.
What also helped me was having my own projects: my own addons and my own Ember apps to contribute to because I learned a lot more about working in OSS in general and I had more control, so it was easier to make those contributions without having the feeling I need to have permission.
I kind of think you contribute to where it makes sense. I always look for something that needs doing, that no one else is gonna do because it’s not as important as other stuff, or for something that can free other contributors up for work that requires their specific skills. For example, I started doing the Ember.js releases because I realized it could free up Robert Jackson’s time for doing [other contributions]. Get a feel for what kind of work you can do with [your current] knowledge. Even answering questions on Discord, the forums, or in issues is freeing up someone else’s time.
Katie Gengler, also known as @kategengler is a partner at Code All Day and a contributor to Ember. You can find her on Twitter.