Another Simple PR

This was another simple issue that I created a pull request for. It was just to add a code of conduct file to the repository, and link to it from the CONTRIBUTING.md file. In looking into doing this pull request, I had noticed that the link from the README.md file to CONTRIBUTING.md was broken (mentioned in an earlier blog post). So after fixing this, I pulled the code of conduct file into the repo, and gave a relative link to it from the CONTRIBUTING.md file.

It was only later that I realized I had given this relative link by habit. All of the other links to markdown files in the repo were absolute. The thing with using absolute links is that if you fork a repository, or are in another branch of the main repository, and then click on an absolute link, it will take you from the current repository/branch to the branch on the repository that the absolute link points to. With a relative link, you link to a file in the same directory, on the same branch of your repository.

Both of these approaches to providing link paths have their own advantages: using absolute links means you can force users to always be redirected to a specific version of a file that is on a specific branch, and using a relative link ensures that users always see the file that is local to the repository and branch they are working in. If you wanted users to always see the most current version of your Contributing.md or code of conduct, or README, it may make sense to use absolute links. However, things like instructions for build processes in CONTRIBUTING.md, have information that changes with, and is relevant to a specific commit on a specific branch. Redirecting users away from the files that are relevant to that snapshot in time of the repository might lead to confusion. For this reason, I think it is generally best to prefer relative links.

Comments

Post a Comment

Popular posts from this blog

Tinkering with Chrome Headless to Handle Mic Input

This pull request consisted of performing more research for the CodeTalker repository. One of the ongoing issues with the repository is figuring out how to make it easy to capture microphone audio across a variety of operating systems, and then process it in a way that is easy to set up across multiple user's devices (all of which have may use different operating systems). In an earlier attempt to make the development environment more accessible to potential contributors to the CodeTalker repo, I tried to mount all of the scripts that processed microphone audio to a Docker container. The advantage of this was that the Dockerfile, which defines how a docker image (virtual machine) is built can be configured to install and configure various dependencies. These dependencies in this case would be for processing microphone audio (Python libraries, and various microphone hardware handling libraries). This worked great for Unix style machines, because the microphone hardware (and other
Read more

Using Arrow keys to cycle through Mozilla Screenshots

Image
 The Mozilla-Services' screenshots add-on for the Mozilla Firefox browser is a nifty browser add-on that allows you to snip a portion of your browser's screen to create a screenshot that you can then either download to your computer, or host on Mozilla's servers. It also comes with some simple image editing tools to allow you to draw on top of your screenshot, etc.. Screenshots consists of both the add-on itself, and the server that it communicates with. The add-on allows you to capture parts of your browser's window and then save the resulting screenshot to your computer or the cloud. The server provides a UI to browse, edit, and download these screenshots after they have been uploaded by the add-on. The server is written with React, and NodeJs with express routing, and uses a Postgre SQL database to store screenshots and their metadata. I believe the add-on uses IndexedDB to store the current screenshot before it is either downloaded or saved to the cloud. The p
Read more

A look back at Hacktoberfest

While I only made a series of small changes, for Hacktoberfest, I feel that I learned a lot in the process. I learned about the capabilities of VirtualBox, in terms of running nested VMs (no 64 bit VMs can be run inside VirtualBox VMs), and the was introduced to the use of Vagrant for virtualizing a development environment across multiple platforms, and how to get creative by stealing JSON data from live versions of code when my local version was missing data (see the blog post here) . I was also exposed to some simple things that you don't necessarily think about unless you visit an array of repositories as an outsider (previously, my use of GitHub consisted mostly of working on school projects in private repositories). I discovered that if you own a repository, there are some files that may change or be moved that you don't think about--either because you are not the primary user of the file (like CONTRIBUTING.md), or because you overlooked how a change affected the acces
Read more