Now that I have no deadlines looming over my conscience, I can look back at my work over the past four months and reflect without the pressure to look for the next big bug.

My first experience with open source, was filing issues on my classmates’ text-note editors. It had been simple code, and it had been code that I had also written. On the blog post, I mentioned how through coding my own text-editor, I had found a bug. One that I was able to see replicated in several repos.

I had been optimistic in that blog. I mentioned a new-found confidence, that while real…it was one that would not last.

The problem was, that I would not have the same experience ever again in the next four months. There would not be a bug that I already found through my own work. That is not to say that it is not possible, but given the few side projects I work on and the scope of the repos I wanted to work with…

That was impossible.

I didn’t want to work in some programming student’s practice website. I wanted to work on a popular framework, on something with a growing community, something I could see myself continue and better my coding with.

It was with that mindset that I rapidly made my experience hell. Because while working on big projects is not a flaw…wanting to find the issue while working on a big project and no experience is.

I admit I fixated too much on finding the issue. I wasted hours looking for something big, rather than doing anything. I clicked page after page, rejected issue after issue, ignored repo after repo, because I wanted to find something that was just right. Even after finding time and time again, that it was impossible.

Doing several small fixes is miles better than not doing a single big one.

And sure. Good first issues don’t really help you grow, but they do expose you to a greater pool of skills. If I had realized that sooner, I might have had an easier time working on a repo I liked. It is easier to find something to work on when you are not stuck looking at only three projects.

Sadly, it is not something that I truly realized until I was desperately looking for something to work on for my last and final issue.

Repository: ruby/www.ruby-lang.orgIssues: 2244 | 2248 | 2249Pull Requests: 2299 | 2300 | 2301

This repo is the Jekyll source for the Ruby language. While it is a language that I have never used, it is one I have heard about.

I did another round of translations and I have to admit, a benefit of doing these, is that it exposes me to a lot of frameworks and languages I would not have otherwise worked with because I don’t know enough about them to code with them.

This time around, I did some updating of the documentation rather than full on translating. It still made me realize I prefer translating to English, though the reasons are very shallow.

Tildes. And 100% solely because English doesn’t have them.

I spend a lot of time copying and pasting from google translate because apparently everything has a tilde and it is faster to use translate than to have use the keyboard shortcuts.

…Also because I always miss one, and I’m so tired of making edits.

for example, the shortest translation required me to change five words (four because tildes) and I still managed to miss two. Moments like these remind me why I never went into professional translating. I don’t nearly care enough about grammar.

Which kind of connects why this section is about Ruby, and not a continuation of Gatsby. I do like working on Gatsby…It is just that my grasp of the formal you is not very strong and I’m still working on editing that page. Gatsby-es only allows you a page at a time, so that’s that.

Despite my weak passion for accurate spelling, I am glad these repos have people that do care, because they allow a greater pool of programmers to read, work, and contribute to these projects.


Repository TelescopeIssues 482|354|316Pull Requests 484|481|320|

Working with SAML was interesting.

With my first pull-request, I hadn’t really needed to work with anything other than the HTML. It had been very easy to ignore everything that was being added to the project. After linking the login with the main page…I could not anymore.

In order to be able to do what we wanted with the SAML, we needed to run docker and understand what it was doing. The gist of it, is that Docker runs like virtual server that allows of us to programs like Redis and express at the same time. Docker would also take care of SAML and how it would connect once we coded in the express routes.

In order for SAML to be implemented, a greater level of communication and collaboration was needed. We were not experts on docker nor had we payed attention to it while it was set up. After being point to the right person, the whole process went more smoothly.

I had initially filed an issue to use my mock login page, but after learning about what Docker did and more about SAML, we learned that we couldn’t use my page. The user should be redirected directly to the page in charge of the authorization. So while the routes were being set up to support that, I made sure I understood what was going on so I could make some documentation so other people would be able to use what we were making.

Overall, the course was a positive experience. I learned a lot of practical skills, and while I can’t say I always did the best coding, working on open source was incredibly valuable and I would love to continue in the future.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s