My Hacktoberfest 2018
It's the last week of Hacktoberfest!
"We’re close to the end of Hacktoberfest! If you’ve already completed 5 or more pull requests, you’ll be hearing from us via email soon to collect your address and t-shirt size. If you’re still working on reaching your goal, here’s some inspiration for projects to contribute to and tips to get started..."
My first Hacktoberfest was a great experience. Hacktoberfest is a yearly event run by DigitalOcean, GitHub, and Twilio that encourages developers to make five GitHub pull requests during October. (I was motivated by the offer of a limited edition t-shirt.)
My goals
This was my first Hacktoberfest, but I still wanted to make a variety of contributions, so I set myself two goals:
- Do a documentation-related commit
- Use a language other than JavaScript
What I contributed to
I made pull requests in two repositories:
SkylineSpartabots/skylinespartabots.github.io
- Add electronics category [1]
- Add Euler problem 7 10001st prime solution in JavaScript [3766]
- Implement standard deviation in Java [3850]
- Add documentation for LZW compression [3872]
- Add documentation for Levenshtein distance [3898]
What I learned
1. Always read contributing.md
Contributing was actually much easier than I expected. Cosmos has a very well laid out contributing guide, which makes it easier to make useful commits.
2. Documentation is important
Looking through other people's code is hard, especially when they follow a strange coding style and have few (or no) comments. You should do your part to make sure that your code has descriptive commenting or add documentation/comments to other people's code.
The two documentation commits I made were a valuable learning experience. I knew the basic gist of the LZW compression and Levenshtein distance algorithms before, but actually describing how they worked was a challenge. It taught me how to write pseudocode and explanations to be easily understandable to others.
3. Make sure the issue hasn't already been taken
At any given moment, Cosmos has hundreds of open pull requests. I started working on a few issues, then later found out that there was already a pull request for it that hadn't been merged yet. Save yourself the time and search before you claim an issue.
4. Open your own issues
By that I mean you can open issues up yourself and then make a pull request to fix them. Creating a GitHub issue before working on a problem means that it is trackable. It tells other contributors that you have already started to work on fixing the problem.
5. Merging pull requests is surprisingly hard
I had a basic knowledge of git before, but I'd only used git and GitHub for my personal projects. Working on a repository with others meant I had to learn how to make my commits easy to merge for the repository maintainers.