Gosub Tests
For this contirbution, I chose to contribute to a project called Gosub, a work in progress browser. I decided to work on this project because it had a decently sized community without being too massive, and that was friendly and receptive to newcomers, which was a good sign. It also interested me as an open source browser seemed like an interesting idea, and I liked their submarine branding.
Introduction to the Community
Gosub, or Gateway to Optimized Searching and Unlimited Browsing, is an open source browser currently being developed. My experience with the Comm Arch assignments and the previous GitHub Bug Fix project helped me to determine that this project would be a good fit for me as a relatively unexperienced newcomer. This project showed good signs such as having a contribution gude, a license, a vulnerability policy, several different chats to talk with the developers and community, and instructions on how to set it up. When I went to submit my Pull Request, it even reminded me of some of them.
The Issue
I originally found this project while searching Good First Issues for something to work on, as it helped me last time with my Bug Fix. It was provided to me by Elizabeth Barron in her presentation on CHAOSS. The issue is about moving some tests from the tests folder into specific crate folders. Although there was no mention of specifically where to put each item in each spot.
When I found this issue, I first joined their community chat called Zulip because they recommended doing so if you are looking for something to work on. After looking around and getting used to the platform, I created a message in the #help wanted stream. I described why I’m here, how I found the project, and my interest in helping on the issue I found. After I sent this, I also added a similar message on the GitHub issue for consistency.
A contributor named Shark responded to me quickly and described the issue to me. Shark described that I should move the tokenizer.rs file into the crates/gosub_html5/ folder, which I would never had guessed would have been the correct folder on my own, so this was very useful.
I wrote back explaining my confusion with where exactly to place the test files and my specific confusion of where to place the other file in the tests folder, tree_construction.rs. I did some digging and found a potential spot for it but it seemed like it would cause problems by overwriting another file in that location.
Afterwards Shark responded to me with a different potential location for tokenizer.rs, but that it would make more sense in the one they suggested earlier. They also said that if I am to move the file over, I should have #[cfg(test)] above it’s module declaration. They then continued that I could add the content of the second file, tree_construction.rs, onto the file with the same name in crates/gosub_html5/src/parser. They said that I should include it under the trait section with the same #[cfg(test)] and a module declaration. This one being written in an embedded code snippet gave me a big hint on how to do it correctly, which was very useful.
The next day I responded confirming that I think I could do that. I asked some more questions that weren’t asnwered, but I was able to figure out the issue to the best of my abilities without it.
I then created my own branch of the project to make my changes and move the files. I moved the 2 files to their new locations and deleted them in their old spots. I commited my changes which you can see here.
After making these commits I then submitted a pull request to merge my fork with main.
I then posted on the zulip thread that I had made a fork, done the changes, and submitted a pull request for them. To which Shark quickly responded saying that they will look at it later.
Conclusion
This was my second time contributing to an open source project. This one was significantly more intimidating to me than the previous one for many reasons. First of all I was actually touching code this time, instead of just markup documentation, so the possibility of my change actually breaking something if I did something wrong was higher. Secondly, I have never used Rust before and have not thoroughly learned it, so this was an entirely new experience for me. Thirdly, I asked questions and not all of them were answered. This wasn’t the end of the world as I used what I already knew to guess, and talked to our TA Adrian to make sure what I was thinking was on the right lines. Once I knew what to do and how to do it, I found that actually implementing the changes was not very difficult or intimidating at all. I’m glad I got to do this project because it has made me more confident in checking out open source projects, talking to the communities, and being confident in the face of stuff I know nothing about by asking questions. All in all, I enjoyed this project and how it has benefited me as a coder and community member.