I have joined Hackoberfest since 2017. It is really an enjoyable journey to code and communicate with the developers from different corners of the World. One can indeed learn a lot. And one would feel excited to see your pull request is merged into some others' repository.

Write test case

Test-Driven Development (TDD) has been a popular practice these years. It aims to make a project easier to maintain. And the tests are now usually included in the Continuous integration and continuous delivery (CI/CD) pipeline. Meanwhile, I seldom wrote test cases before due to time constraints or simply laziness.

My first writing of a testing case was in some others' project during the Hackoberfest. I was using unittest for a Python project. I read the documentation and some blog posts. I wrote the test cases as detailed as I could think of and created the pull request. The project owner pointed out that I should only write the test cases for the correct cases, no need for the failed cases unless it is testing for the error handling. This made me very touched that someone is willing to teach me and offering a chance to improve.

In these few years, I have tried to write test cases for JavaScript and Rust projects.

Write documentation

It was not a happy experience though, but I can still gain something. The maintainer of a quite popular Python package project thought my pull request is "T-shirt driven" spam and marked as invalid tag. I was shocked that how come the people can be so rude. Am I "T-shirt driven"? To be honest, maybe. But that time, I did not simply add a space character or add "Awesome project" in the README.md file. I really added screenshots and the steps to use such features. I read through several pages of the existing documentation to check the writing style and tried to follow them.

So I leave a comment to refute them. Finally, the maintainer removed the invalid tag. Need not to say, they simply close the pull request and don't merge. I understand that the time of maintainers is limited.

In fact, I thought it was because the original issue creator did not carefully specify the problem. The scope was too broad. And the maintainer has no much time to communicate with the original issue creator. When I came to make a pull request, then the miscommunication happened. All in all, to argue with someone you don't know politely is an exciting experience. It really made me step out of my comfort-zone.

Learn a new language

I wanted to learn Rust language. I particularly searched for some projects using Rust. I select some bite-sized issues to contribute. By doing this, it can force me to search how Rust works, what are the concepts of Borrowing...etc Again, after I created a pull request, the maintainer responded and suggested to me that some cases may not need to clone the variable too much.

Start hacking!

If you are open-minded enough and willing to learn and communicate sincerely, the open source would be fantastic and beautiful. I hope more and more people can create quality pull requests and contribute to the World. My next stop would be as a maintainer of an open source project that can carry the newcomers and spread the love!