Skip to main content

My first bug fix: Completed

Fixing bugs is a lot of work. Fixing bugs for an open source project is even more hard work. If you have no idea what you are doing, it is very difficult to contribute. Fortunately, the open source world welcomes new people. My experience with working in open source was difficult but so satisfying.

I ran into a few bumps before I could actually start working. I talk about those bumps in my previous blog posts. I realized that I had no idea where to start. I had never worked with a project this big and I was intimidated. I did not know where to start.

I was having a very hard time, my head was hurting, I was feeling dumb, and I was beginning to give up. But then help came to help me. One of the guys over at Mozilla was a big help. He took his time to email me personally to check up on me. I was shocked that he did that.

I replied and we started chatting on IRC. He wanted to help me and he was very knowledgable. He suggested another bug for me to work on to get more familiar with the python language. He said that I can keep the bug that I was assigned and I can try to work on it again when I'm more comfortable. I accepted the new bug from him and I started working on it immediately. The bug can be found here.

It seemed to be a more simple bug that required me to remove code that is no longer being used. I found this job to be very easy and I did it really fast. I was excited and I asked him where I can submit my code. He said wait, slow down, have you tested the code? I responded yes, it runs exactly the same way. He said you need to run the built in tests using a certain command "./run-tests.sh" I was like oh, okay. I did it and I was waiting and waiting and waiting. It ran and ran and finally, I couldn't believe my eyes, it said no errors found. I was very excited at this point.

I rushed back onto IRC and said the tests were successful and he told me to commit it to my cloned version of Balrog and then to do a pull request so he can review the code. He reviewed it and told me to fix one more thing and then commit the changes again.

I changed what he asked, but this time, the automatic tests that are on github did not pass. He told me that it's a formatting issue. There should be 2 lines of spaces between classes instead of one. I changed it, and the tests on github passed.

Finally, after waiting and waiting, my code was accepted and my code was committed to the official Balrog project. I became a contributor to Mozilla and I felt so accomplished over a small little bug. Overall, it was a long difficult journey, but the satisfaction of seeing the end result is very motivating. I look forward to working on more bugs in the future both in this course and even after my school career.

It was a fun experience and I want to be able to contribute to many other open source projects that I am interested in.

Comments

Popular posts from this blog

Fixing Bugs Again

I started working on Open Source Projects again and I had a difficult time getting started again. A big part of my problem was not having enough storage on my computer. After moving some things around and deleting files and programs I don't use, I was able to clone a couple projects and I was finally ready to start running them and replicating the issues.  This time around, I worked on three projects; Thimble, Brackets, and Balrog. The bugs that I fixed for Thimble turned out to be fixes on Brackets so the pull requests were made there but referenced from Thimble. Overall, getting started was much easier than last time because I already had the experience and possibly the necessary files on my system to begin. After being assigned a couple bugs, I began to work on them and I have made a couple pull request for the fixes. They have passed all tests and I am just waiting on it to be accepted and merged into the actual project! That is my goal. I will need to follow up if anyth

Second Attempt At Fixing Open Source Bugs

In my second attempt at fixing open source bugs, I want to prove that I have grown from the first attempt. My first attempt was fixing a single bug, requesting a pull request, and getting approved! My goal this time around is to work on more than one bug, I plan to work on 2-3 and my ultimate goal is to get all of them approved! There is no better satisfaction than getting approved!  Since I was working with Mozilla projects before, I decided to stay in that bubble and work on Thimble/Brackets. I have currently asked to work on a couple bugs like this  and this  and once I get the okay to do so, I will begin to try to fix them. As of right now, I am still researching for more bugs to work on, but at the time of this blog post, I do not have any backups.  Due to the strike, a lot of things are altered in my schools semester. Surprisingly, all my teachers were very accommodating and they dropped tests and assignments and overall, it's making the end of the semester less over

Documentation

Documenting everything is extremely important. It gives everyone the information they need whenever they need it. Github makes it very easy to have beautiful pages written in markdown rendered automatically. It's nice and easy to do. Creating a README in the root of the project is common practice and is even automatically rendered when the project is open in Github, under all the file names. I've been looking at quite a few different projects and they all have README files. It usually includes an introduction to the project, how to set it up, how to run it, how to contribute to it, major credits to people, etc... Essentially, it holds important information about the project that anyone has access to. Along with the README file, we can comment on our actual code so hackers who read the code can know what does what. It allows the creator to recall what they wrote in the past and it invites new people to understand what has been written. It is really important that comments are