Skip to main content

My Journey of Fixing Bugs

Fixing bugs in the open source world is completely new to me. It's something I've never done before and it is something that I am really looking forward to. Being able to say that I've contributed to so and so sounds very fulfilling. I am ready to start working on bugs.

To start off, I picked three bugs and I left a comment asking to be assigned if no one else is assigned. So now I have to play the waiting game. I will be doing research on the bugs so I can be prepared for when/if I do get it assigned.

I chose two bugs from Thimble and one bug from Firefox(Android OS). The android one seems simple, and can be found here. I'm not really interested in this one but I'm using it as a backup to my backup. It seems to be just cleaning up and renaming. Which I think I can manage.

The runner up to that bug is a bug from Thimble which can be found here. This bug is a feature request that I think I am capable of fulfilling. It is to add line numbers to the console output. I am interested in this one because it is a project I've never used and it seems to be really useful for me in the future.

The one I'm most excited for though is found here. This one is also on Thimble. It is like a feature request/bug. Pretty much, I'd have to figure out how to change the description of a project without actually publishing it. Seems challenging but I'm ready for it.

I'm nervous because this is my first time and it seems very overwhelming, but I have the support from my teacher and I have all my classmates and the rest of the web that I can turn to. I'm hoping to learn how to work on bugs, learn things in a short amount of time, adjust and adapt to new environments and just things like that in general.

Open source is a huge part in today's tech society and I am really looking forward to be part of it and be involved in it. I hope I can make a lot of changes in the time to come.

Comments

Popular posts from this blog

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

Automated Testing

Automated testing is a very useful feature that is simple to implement in any open source project. It allows the testing to be automated to ensure that nothing will break when things are changed. In the open source world, code is changed quite often so having automated testing can make it easy to track and manage errors and we can know if the code is properly written to pass the tests. Overall, it is very beneficial in open source programming. Travis CI makes it very easy to link your Github page and the repos on it. It is very easy to get started and I would recommend it to everyone! I always used to do my testing by outputting the results and comparing it with whatever I had in my head, now, it does it all on it's own.

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