Hello everyone!
Today, I wanted to share some details about my second contribution as part of the Hacktoberfest month.
If you have not been following this series, you can refer to my previous post where I explain what Hacktoberfest is.
Repo
My goal for this year's Hacktoberfest was to contribute to at least one big established company or product in IT. Luckily for me, I landed on a an interesting repo called the CVE Binary Tool. It is an open source tool to help you determine if your system includes known vulnerabilities. It is based of the data from the National Vulnerability Database (NVD) list of Common Vulnerabilities and Exposures (CVEs).
Issue
The issue that I worked on was part of the series. They were partway through a migration from the older os.path method of handling filesystem paths to the newer Pathlib style. So, they had a number of files that needed updating and created an issue for each of them.
My issue was called refactor: use pathlib in sbom_manager/init.py.
First, as always I checked if they had the contribution guidelines and found their CONTRIBUTING.md. I quickly went through it and noted the parts that might be applicable to my PR. A couple of the things that I followed were creating a new branch and using Github keywords inside the commit message for automatic issues management.
Pull Request
When I submitted my PR, I almost instantly got a comment from a developer at Intel saying that my changes looked good. She approved them, however, as I first contributing to this repo for the first time the workflows still needed the maintainer's approval to run. I waited for a few days but did not get any updates, so I decided to leave a kind reminder. I was not sure why she approved my changes but not the workflows. Then, I found out that she was not the maintainer and could only review.
I got a message from one of the maintainers later and she approved the workflows. They showed one issue which was due to the requested modules not being in alphabetical order. Before I even saw these messages, the maintainer has already fixed that by proposing new changes and accepting them. So, my PR got accepted.
Experience
This issue took me much longer than my first one during this month. First, I had to make sure I follow all of the standards from the contribution file. Second, it was a coding fix about the topic I have no experience in. I had to do my own research by referring to many different documentations, search for some example and test the work to make the changes. I also had get an approval from people in different roles such as reviewer and maintainer.
Learning outcomes
Now, I have contributed to an Intel repo, made a fix in unfamiliar topic, communicated with maintainers and reviewers and worked through a workflow fail. So, I can be very proud of myself.
This time, I also realized that the open source community has an always changing pace, sometimes everyone might feel so active and reply to your PR very quickly and sometimes you might have to wait for a few days as everyone is silent. So, have to be ready for both and always react fast.
P.s: Originally, I chose another issue from the same series but someone stole it from me by submitting a PR quicker although I commented that I am working on it. Fortunately, I found another issue that was very similar, but pls do not be like that guy lol.
Top comments (0)