This time, I practiced contributing to another student’s repository by adding a new feature and submitting a Pull Request. This was my first time doing a full open source style workflow, and it gave me a good sense of how collaboration works on GitHub.
The feature I implemented was the Recent Changes Filter. The idea of this feature is when running the tool with a --recent or -r flag, it should only include files that were modified within the last 7 days. This makes the output more focused on current development instead of the whole project.
To achieve this feature, I Added a new CLI flag (--recent / -r) using Commander, with an optional number argument (e.g., -r 3). Check the file’s last modified time with Node’s fs.statSync(file).mtime. Filter the list of discovered files to only keep the ones modified within the given number of days (default is 7 days if no number is provided). I also Updated the output so the File Contents section only includes these recent files. And there has a small summary line to show how many recent files were found.
Before coding, I created a GitHub Issue repo-snapshot in my classmate’s repo describing the feature. I explained why it was useful, how I planned to implement it, and that I wanted to work on it. This way the repo owner could see my plan and give feedback.
The PR process went smoothly. The repo owner reviewed my code and gave feedback about the feature. So I updated with custom date, and then the PR was merged. From this, I learned how important it is to keep commits small and focused, and to write PR descriptions that clearly explain what you changed and why.
At the same time, I also received a PR on my own project (PR #6). This first thing I have learned is how to get someone's PR branch into my local machine for testing purpose. And reviewing someone else’s code felt different because I had to think like a maintainer. I checked if their changes broke any existing functionality, if the code followed the project style, and if the feature matched the project’s goals. I requested a small change before merging, The contributor updated their code quickly, and after testing I merged the PR.
This taught me that code review is not just about finding bugs, but also about communication: giving clear, constructive feedback, and making sure the contributor feels supported. It was interesting to see how small details (like formatting or naming) can matter in open source collaboration.
Overall, I learned both sides of the open source workflow:
- As a contributor, I practiced reading someone else’s codebase, adding a feature without breaking existing functionality, and responding to review feedback.
- As a maintainer, I practiced reviewing code carefully, requesting improvements, and merging contributions.
Top comments (0)