This week, we embarked on our contribution journey in the Topics in Open Source course. Our initial task was to contribute to our classmates' projects and review the pull requests (PRs) of others who were contributing to our own projects.

This experience was not only exciting because we got to explore other people's projects, but also because it required us to read and understand their code deeply, figuring out exactly where to apply changes to implement new features.

All of the projects in our course are focused on using LLM (Large Language Model) chat completions to enhance various CLI tools, with each student having the freedom to choose the specific functionality of their tool.

This week, the common feature we needed to implement in each other's repositories was support for a -t or --token-usage flag. This flag would display the number of tokens used in the prompt and the tokens generated in the completion response.

My Project

For my project, OptimizeIt. My partner for this week was Nonthachai Plodthong.

The Issue

The issue filed on my repository clearly outlined the feature to be implemented: adding a -t or --token_usage flag to display the token count used by the program. After some discussion between my partner and me, we decided to use -tu instead of -t, as there was already a -t flag that allows the user to set the temperature. Additionally, we chose --token-usage for the long command name, as it more closely aligns with the standard naming conventions than --token_usage.

The Pull Request

Nonthachai Plodthong opened a pull request on my project to merge their changes. We spent several hours communicating back and forth to ensure everything was covered — all edge cases, comments, updates to the README.md, and more. This was a perfect simulation of a work environment, where the reviewer and the author constantly collaborate to ensure everything meets the required standards.

Examples of requested changes included adhering to coding standards, removing unnecessary try/catch blocks, and fixing a program crash in an edge case.

Ultimately, the PR was successfully merged after addressing over 10 requested changes, ensuring that the new feature was integrated correctly without impacting any of the existing functionality!

The Project I Contributed To

The project I contributed to is genereadme, which belongs to my Lab 1 partner from last week, Cleo Buenaventura.

The Issue

The issue I filed on Cleo's repository proposed implementing the same feature mentioned above. I provided a concise and thorough description, explaining what the feature is and why it should be implemented. I also included several examples of how the feature would be used.

The Pull Request

To approach this task, I first needed to understand how the commander package worked. Cleo used this package to parse command-line arguments into options and command arguments, and to display usage errors when needed. Afterward, I analyzed Cleo's code to understand the guidelines he follows, such as variable naming conventions and overall code structure.

I then added the new command-line flags and implemented the logic to accumulate and display the token usage information based on whether these flags were present.

The requested change was to add a shorthand flag -tu that behaves the same as the --token-usage flag. This was necessary because the -t flag was already being used for the temperature setting in the program.

Once the requested change was made, Cleo successfully merged the PR into his repository!

Conclusion

This week's activities felt like a warm-up, preparing us to contribute to larger and more complex codebases in the weeks to come. It was a valuable learning experience that underscored the importance of writing clean, well-organized, and accessible code that is easy for others to understand and build upon. I learned firsthand how critical it is to maintain a consistent coding style, adhere to best practices, and ensure that our code is structured in a way that welcomes contributions from a diverse group of developers.

Beyond the technical aspects, this experience highlighted the significance of clear and detailed communication in collaborative environments. Providing comprehensive descriptions in issues and pull requests is essential, not only to convey the purpose and context of a change but also to facilitate a smoother review process. The more context and clarity provided, the easier it is for reviewers to understand the intent, identify potential issues, and suggest meaningful improvements.

Ultimately, this week was a powerful reminder that open source is not just about code—it's about community, collaboration, and the shared commitment to creating something better together. Each contribution, no matter how small, adds value to the collective effort, and I'm excited to continue this journey, contributing, learning, and growing alongside my peers. I look forward to tackling more challenging tasks and collaborating with developers across the globe to make a real impact in the open-source world.