Sugarizer bugfix

For my bugfix assignment, I was pointed to an error in the README.md file for the Sugarizer application by my wonderful professor. The issue with the Sugarizer README was pretty simple. In Markdown, some number of octothorpe (#) at the beginning of a line denotes a header. If there is no space between the octothorpe and the header title, the text will not be emboldened. You can see an example of the issue below.

##this is supposed to be a header

Method

The first step in the process for me in fixing this bug was creating an issue in the github repo for the project. In the issue, I explained what the issue was as clearly as i possibly could, essentially saying exactly what I did in the first paragraph of this blog. Once the issue was logged, I forked the repo into my own github and cloned my newly forked repo. In my local copy of the repo, I modified the broken README file so that the Markdown would show correctly. After committing and pushing my change, I created a pull request stating the changes I made to fix the issue.

Community interaction

I actually didn’t end up having to communicate with anyone involved with the project for help fixing this issue. The issue was relatively simple. I did look through some of the currently open pull requests to see what the discussions are like among the contributors. They are relatively nice people, though there are only a few actively committing or commenting. Judging by the way they interacted with the other people submitting pull requests and issues, I would have no problem getting help for a more intensive project on their code base.

Edit

A few days after sending out a pull request for my fix, my pull request was denied. Apparently the issue I had fixed had already been dealt with on the dev branch of the repository. I was told that all fixes should go through the dev branch. While I feel a little miffed in that my work was for nothing, I did learn a little more about the workflow of the usgarizer project.