Hacktoverview

Wrap-up

So it's a wrap for me on my first Hacktoberfest, it's been pretty cool and built a bit of confidence with using some of githubs features and in my own ability to jump into a project and get started.

Seems like a lot

Cause it is. At first when you look at the list of issues it's a lot to take in, you find pretty quickly that a lot of issues are not to do with writing code, there's a lot of repositories that just exist to give people a place to contribute to for Hacktoberfest credit, there are a lot of other issues that are entirely legitimate but not coding as well such as documenting and then there is a long long list of issues that have already been spoken for by other people. Here are some tips I have found.

• Filter:

One of the first things you will find yourself doing if you want to have a better time is learning how to use advanced search to filter your results based on no assignee or a particular label like good first issue, or perhaps you are like me and in the end value a larger pool and find that on a particularly dry day you want to shed a label that's restricting your searching filter. In any case learning to filter your search is an important thing to start with because you need to be searching with the intention of finding a repository you actually want to contribute to.

• Jump in:

Don't let your dreams be dreams. When you find a repository that interests you go for it because the issue will not be open for long within the context of these crazy busy events like hacktoberfest. You might not know how to do it, that's ok. Even if you do not end up solving the problem you are going to hopefully have a learning experience communicating with the maintainers of a cool project and at worst you can graciously admit that you are out of your depth for the task at hand. As long as you are not leading them on acting as if you can do something you can't for weeks I am sure they will understand. My favorite formulation is Can I try to work on this?. It's non-committal, you're not saying you can solve it off-rip, but you are putting your hat in the ring and saying I want to try.

• Communicate:

Maintainers are all different but every one I have worked with so far has been as helpful as they can be when asked for advice or when commenting on the contributions you are trying to make. Some advice I would offer is, particularly when getting set up with a project at first, if something is unclear ask the maintainer instead of wasting time trying to solve it yourself. If it's unclear how to get setup with a repo in the first place that's kind of on the maintainer and I think most of them would want to know so that they can make contributing more friendly in future anyways. On the flip side, when you are creating a pull request and they make some corrections take the advice graciously and accept that they have their way of doing things and that you could maybe learn something. It's a friendly dialogue with all parties wanting to achieve a common goal.

My PR Progression

I had some fun for myself this Hacktoberfest and I really do feel like I had a good progression in terms of the kinds of issues I was taking on.

At first I worked on a Tutorial markdown to get people started with HTML, CSS and GIT basics so that they can contribute to a library of tailwind styled elements. https://github.com/Clueless-Community/web-ui-kit/pull/25

This is where I first started communicating with maintainers and taking their feedback into account, adding images to make it nicer. This was my start, a page of documentation.

Second was a small CSS change in a popular project, Caprine. I really had a long back and forth with the maintainer about two seemingly simple changes in a style sheet and I realized I should have been linting my code changes and I learned how to find the css elements I meant to target, it was a small step forward. https://github.com/sindresorhus/caprine/pull/1933
You can still see the remainder of a bunch of requested changes.

Third PR is when I created my own Div and gave it some JS logic through jQuery, saying that it should be an accordion. In this project I learned how to isolate the files I was interested in and really work with what I was particularly interested in. To do my initial code changes I did not fork the repo for the first time but instead took the HTML of interest and copied it into an HTML file and the CSS file it referenced and I used live server to edit them separately before I was happy with the outcome and forked the repo and put them in my own little issue branch and made my PR. https://github.com/IndigoWizard/wildfire-burn-severity/pull/3

Finally I made a bigger change. I used the reddit api to retrieve popular subreddits to populate the default autocomplete drop down of a pre-existing set of search and autocomplete elements. https://github.com/gregrickaby/reddit-image-viewer/pull/414

To get started I created a reddit app to get a client id and secret and added those to the .env of the project.

Then I had to understand the pre-existing logic from the other API calls, the way SWR was being used to fetch data and the format the returned data took, then I had to consider where it should be passed into the AutoComplete element.

Conclusion

To conclude this was a lot of work, but looking back on my merges not a lot of code and I wish I had found more server side problems to do with making some APIs. Finding good problems has been really hard.

This experience however has made me a bit more confident, I feel good having worked with multiple strangers now, when your code is accepted you kind of feel accepted as well in a way, like you are a part of something a bit bigger now.