The semester is coming to a close and I had two more pull requests to do. I decided I wanted to take a different approach to what kind of issues I wanted to work on. Over the past few months I have tried working on a lot of different projects. I’ve learned a lot of new things. But, I wanted to take a proactive approach this time around. Instead of looking for issues that exist I wanted to find my own issues in different repositories.
Telescope
One of the most important things I have learned over span of this course has been how to use git and GitHub. Version control has been something I have been interested in for a while. I have had some bad experiences in the past with working on a code base with multiple other people. That’s why I took such a keen interest in learning the in’s and out’s of git. And I think I have gotten pretty good at it working with git. I have been fortunate to have been able to help a few of my friends with git problems. I noticed a lot of the issues have been with how to rebase properly and squashing commits. Ideally we were aiming for each issue that is addressed to have a single commit for it in the master branch. This hasn’t really been the case in Telescope.
During one of my labs I was helping a classmate of mine with squashing his commits along with my friend Anton. As we were doing this Anton mentioned he thought we should update the documentation in Telescope to provide some information on how to squash commits. I thought this was a great idea and went for it.
### Squashing Commits
Before creating your pull request you may want to squash all your commits down to one. Ideally this should be done before you rebase on the upstream master.
Before you begin make sure you are in your own branch and any and all changes you wish to make are commited.
1. The first step is to find the base commit where your branch began. To find this you can run `git log` and look through the history for the commit before your first commit. Copy the hash from this commit.
1. Run `git rebase -i` followed by the base commit's hash.
Example: `git rebase -i 1bab04f`
1. A `git-rebase-todo` file will then open up in your default editor. If you have no set one then you will be prompted to edit it in terminal using VIM.
Example:
```
pick 52a4ced Build
pick b85d7a9 Final Build
```
1. On this screen you will need to decide what you want to do with each commit. Most commonly you will be choosing to squash, fixup or reword your commits. The example below will create one commit instead of 2 with the commit message being "Build".
Example:
```
pick 52a4ced Build
fixup b85d7a9 Final Build
```
1. Once this is done you can save and close the file. (Or if using VIM press esc then : followed by wq to save and quit).
I believe it is really important for projects to have really good documentation. Especially open source project. Over the past few months the projects I really enjoy working on the most were the ones that really documentation. It makes it so much more likely that people who are not part of the project will want to come in a join it. The projects that I saw that had little to no documentation were always ones I was less inclined to participate on. In addition to helping outsiders, it is also really helpful for members to have some documentation to refer to when they need a hand.
Accessibility Insights for Web/Civic Data Lab
As for an external pull request rather than spending a lot of time looking for issues to work on as I have done so in the past I decided to take the advice of my professor and actually use the Accessibility Insights tool that I have been working on to find accessibility issues on the web. I was worried about showing up on a random project and just telling them their website wasn’t very accessible and giving them code. What I decided to do instead was to work on a project I have already worked on. Back in Release 0.1 on the very first external open source project I had ever worked on was the front end web site of a group called Civic Data Lab. I thought I would be interesting to run the Accessibility Insights tool on the front page and see what came up.
After running the tool I found a lot of the links on their main page I found that many of the social links for the members did not have aria-labels. Aria-labels are there to label links, images and other elements that would be difficult for a person with visual impairment to see. When a screen reader is used without these labels the reader would not be able to properly convey to the user what the link is for. It might for example read out the entire URL one word or letter at a time. Instead with an aria-label would read out the label which would hopefully make much more sense to the user.
<ul class="pagination justify-content-center">
<li class="page-item px-2">
<a target="_blank" class="fa fa-github" href="{{ member.github }}" aria-label="{{ member.full_name }}'s LinkedIn Account"></a>
</li>
<li class="page-item px-2">
<a target="_blank" class="fa fa-twitter" href="{{ member.twitter }}" aria-label="{{ member.full_name }}'s Twitter Account"></a>
</li>
<li class="page-item px-2">
<a target="_blank" class="fa fa-linkedin" href="{{ member.linkedin }}" aria-label="{{ member.full_name }}'s LinkedIn Account"></a>
</li>
<li class="page-item px-2">
<a target="_blank" class="fa fa-inbox" href="{{ member.email }}" aria-label="{{ member.full_name }}'s Email"></a>
</li>
</ul>
In the above code I added aria-labels based on the members full name so that each link had even more context than just “GitHub Link” for example.
After running Accessibility Insights again I removed 36 issues. There was still one issue remaining regarding the amount of contrast between colours. This was something I did not feel I should change and would rather leave that for the team itself.
After this I went to their repository to create an issue and file a pull request. Only then did I realize there was already an issue regarding air-label created and a pr for it as well. I felt a upset at my self for not looking before getting started. But I then noticed the time stamps. The issue was filed in June 2018 and the PR was push in November 2018 but still wasn’t merged. When I looked into the changes I realized the fix had become out dated. Its seems a lot of the code base has changed since that time. So I create pull request just mentioning the issue I worked on and that the previous PR was outdated. Hopefully that is OK with the team and my PR will be merged eventually.
Telescope:
Original Repository: Seneca-CDOT/telescope
My Fork: varshannagarajan/telescope
The Issue: https://github.com/Seneca-CDOT/telescope/issues/312
My Pull Request: https://github.com/Seneca-CDOT/telescope/pull/480
Civic Data Lab
Original Repository: CivicDataLab/civicdatalab.github.io
My Fork: varshannagarajan/civicdatalab.github.io
The Issue: https://github.com/CivicDataLab/civicdatalab.github.io/issues/6
My Pull Request: https://github.com/CivicDataLab/civicdatalab.github.io/pull/42
Issue #1
Pull Request
Varshan's Blog 