Improving my (P)ersonal (R)ecords 💪 with (p)ull (r)equests 💪

Hello to new and existing readers! My name is Peter, and I'm a student at Seneca Polytechnic, where I study Computer Science.

Today, I wanted to write about what I did this week for my OSD600 | Topics in Open Source class.

Table of Contents

1. Making a pull request
2. Accepting the pull request of others

1. Making a pull request

The topic of this week was to do the following:

1. File a GitHub issue on another OSD600 student's repository, regarding adding a feature.
2. State that you will take ownership of implementing that feature and that you will make a GitHub pull request that contains the appropriate updates to the code.
3. Have another student do the same thing for you.

One of the lessons I learned this week in open source is that in the spirit of open source, we should just file issues right off the bat.

What do I mean by this?

Well, in the context of school, most students will probably reach out to another student to "partner up" and claim who will work on each other's repository, for the sake of completing the assignment.

This is in stark contrast to what we should be doing - just filing any issues we find right away (with the caveat of checking if an issue has been filed already or is being taken care of)!

Admittedly, I was still in "school mode" where, my first instinct was to reach out to my previous partner, Aryan Khurana and plan out how we would attack doing our pull requests. Long story short, this didn't work out to my favour since I learned that someone else had pro-actively filed an issue to his repository and added the necessary changes in a pull request, regarding adding a feature to his repository.

That made me realize that in the world of open source, you have to be pro-active when filing issues. If you don't file an issue, or make a pull request, someone else will do it!

To that end, I started scanning the repositories of different students in my class.

I found Kannav Sethi's repository for his command-line tool, DialectMorph and quickly filed the enhancement issue.
In the issue I filed, I suggested to add a new command-line option, -t / --token to display how many tokens are consumed when connecting to the Groq api.

I explained that we can show users the breakdown of tokens used when sending a request. Token usage can be broken down into:

1. prompt tokens, the tokens consumed from simply prompting the API.
2. completion tokens, the tokens consumed from the API's response.
3. total tokens, the sum of prompt and completion tokens.

Given that Kannav's code was quite similar to mine, it was very easy to change a couple of lines of his code to make sure it displayed the token usage.

I tried to minimize the amount of code changed, while still maximizing the result. I ended up doing 3 separate commits:

1. My first commit simply added -t and --token as a valid option and explains what the option does.

1. My second commit involved changing Kannav's logic slightly to return more information than he originally intended for a function. However, his pre-existing function now returns both a prompt from the API as well as token information from the API.

1. My third and final commit... Let's save that for later!

For now, I'd like to show the result of my changes:

After making sure my code seemed to work (up to the 2nd commit), I hastily made a pull request. I thought that if I made the code work that my code could be merged. However, I didn't realize I had failed to meet Kannav's requirements for formatting.

Kannav had set up a continuous integration pipeline, that automatically checks if the code being merged or pushed to his repository is formatted properly. I had failed to format my code prior to committing my changes and Kannav's continuous integration pipeline caught that.

After realizing I didn't format my code, I followed Kannav's guidelines to format my code, and did my 3rd and final commit, which simply contained the reformatted code from my 2nd commit:

With my changes up-to-date in my forked repository, my pull request now passed the continuous integration pipeline and was accepted by Kannav.

You can see my commit history here.

And with that, my code was merged! It felt good to be able to resolve the issue and get feedback from Kannav that the changes looked good.

2. Accepting the pull requests of others

Just like how I added a feature for Kannav, he had to add the same feature, but for my repository as well.

Right off the bat, Kannav filed the issue on my repository and was also very quick to respond to my request with regards to how I wanted it done.

In a similar manner to me, Kannav also adjusted some of my functions to a state that works, but had failed to meet my own CI pipeline with regards to my unit test specs. Our chat log can be found on this pull request thread.

After I advised Kannav that the tests failed to pass, Kannav was quick to resolve the issue. He had opened up another pull request that resolved the formatting issues with his code and updated my test cases to reflect the changes that he made.

With that, both Kannav and I gained a little bit more experience with making pull requests and ensuring our commits meet each other's continuous integration pipelines. This was a good experience for me as I learned that a project that is set up well with continuous integration pipelines can give those trying to contribute some indication if the user is on the right track.