Get the best out of Hacktoberfest as a contributor

Get the best out of Hacktoberfest as a contributor

ยท

14 min read

We have reached the 2nd half of Hacktoberfest. This year, the event is super hyped with plenty of swags from different communities in addition to the cool tee/tree that you would get from Digital Ocean โšก๏ธ While all of these are motivations for you to get started for Hacktoberfest, the act of working on open source contributions is another story altogether ๐Ÿ˜ฅ

In this article, I will be share with you some tips and tricks to get the best out of Hacktoberfest through meaningful participation โœจ.


The workflow of contributing to open source

Before Hacktoberfest started, I looked around for resources and compiled them into an curated anthology. Doing this research helped me in setting expectations for the user journey on contributing to open source projects:

  1. where to find issues
  2. reaching out to get assigned to issues
  3. communication with the project maintainers to work on the issue
  4. how git works as version control and git commands (this won't be covered in this article, refer to the anthology if you need this.)

These are processes that we have to do to participate in Hacktoberfest and contribute to open source, and in practice, most of these are not difficult to do.

Finding projects to contribute to

If you don't have any clue what projects are available for contribution yet, try looking through the following items:

  • Awesome First PR Opportunities
    • shows opportunities sorted by programming language (yes, not by framework.)
    • has a twitter channel for you to be notified whenever there is a new issue for beginners available
  • Dev.to's Hacktoberfest 2021 Looking for Contributors Thread
    • This thread is a little messy, but you could hit the subscribe button to get informed if someone posted new projects for contribution.
    • Alternatively, you can scroll through the dev.to Hacktoberfest stories section, where there are articles by companies/organisations specifically seeking for Hacktoberfest contributions. This is is where I found out about the open source project Medusa Commerce, which I am going to contribute to soon.
    • There is also a tag #contributorswanted
  • Discord Open Source
    • Discord has a requirement for the projects listed there to have least 1,000 members in the community or for the GitHub repo to have at least 1,000 stars. So the projects listed here would be much more established, but you may find it harder to find issues to contribute here as a beginner.

With these lists, I'm sure you would be able to find a few projects that you would be keen to contribute to. Take your time to find a fit. The next section will be covering an effective method of finding issues to contribute on those projects.

Finding issues to contribute

Assuming you already have some target repositories that you would like to contribute to, there are 2 filters you can utilize at the GitHub Issues Tab to search for issues that you can work on more effectively.

  1. Search issues with labels: good first issue, hacktoberfest Filter issues using labels at GitHub

    Notice in the screenshot that the labels are marked with a filled circle rather than a checkmark, This indicates that the labels are selected with a "OR" condition. There's a tiny prompt at the dropdown near the annotated orange star symbol saying to use "Shift + Click" for applying filters with a "OR" condition.

    • By searching with the label filter, this helps you to narrow down the search on issues that have already been triaged by a project maintainer.
    • good first issue, first-timers-only, first time only, up for grabs etc are some labels intended for beginners.
    • hacktoberfest is a recent label that is created for Hacktoberfest 2021. In previous years' Hacktoberfest, this label doesn't formally exist. So if you are able to even filter issues by this label in a particular repository, chances are that project is really actively seeking for contributions and joining Hacktoberfest in 2021 too.
    • By finding issues via labels, you can also see other labels that the issues of that repository that you may be keen in. For example, Forem has tags like tech: frontend and tech: backend, so if you are interested to learn a specific part of web development you can choose to filter by those labels too. For repositories like Forem that have many labels, you can go into the labels page instead of scrolling the dropdown to look for labels. image.png Then you can search for labels, and see what other relevant labels that have open issues which may pique your interest. image.png
  2. Filter Issues by "Assigned to Nobody"

    Filter by whoโ€™s assigned - "Assigned to Nobody"

    • This reduces the chance that you don't waste your time working on an issue that someone has already worked on.
    • Across different projects, I have seen before many unassigned issues that already have a pull request opened for them. Sometimes the project maintainer knows that someone is working on it, sometimes they don't (to be expanded on further in the next section). To tell whether there is already a pull request made for the issue, you can refer to the symbol below the milestone column. Pull request symbol circled below the milestone column of the issues table

That was how I could quickly find issues to work on for Hacktoberfest. Beyond just finding problems to solve, open source adds an interesting social aspect to these problems.


Communication on Open Source Projects

As contributors, we are volunteers, and we should also be the ones making the initiative for many conversations.

Even if you are usually an introvert.

Cat thinks he should stop being lonely and talk to people. But when people walks to him and say hi, his hair stood up

Unlike real life, communication on open source projects happens mostly asynchronously. Unlike real life, there may be other contributors/maintainers that would read the conversations you are involved in aside from the ones that work with you on the issue.

Hence, it is important that we should cut down on unnecessary overheads that may happen due to a lack of diligence (e.g. not reading the CONTRIBUTING.md) so that we can make the collaboration process more efficient in terms of time and energy.

As a contributor,

  1. Aways check out the CONTRIBUTING.md first before asking any questions on how to contribute. Imagine you're a new hire to a new company, certain teams already have specific ways of working - be it branch naming conventions, tech stack used etc. With you and other newcomers in mind, they spent significant time to document it down nicely for your onboarding. But then as the new guy, you chose to ignore their efforts and ask them to repeat the same things that they have already laid out in the onboarding doc. How sad is that? ๐Ÿ˜ข
  2. Ask to be assigned an issue before working on them. This helps project maintainers be aware that you are working on it, and also help other contributors know to find other issues to contribute to instead. It's the same as kicking off stories on JIRA, you simply do not work on stuff that you have yet to formally be assigned.
  3. When creating a PR, be elaborate in your PR - what issue you are fixing, how are you fixing it, and what you have tested. This will help reduce cognitive load on the project maintainers, as your PR will be one of the many that they will be reviewing.

These are the steps you can do to reduce the communication overheads that you would experience in making contributions to open source projects. Your efforts in doing your homework to make the collaboration process smoother also goes a very long way for the project maintainers too when these little efforts are compounded by many contributors.


A typical new contributor's experience

As a newbie contributor to Open Source, you may experience some of these thoughts while going through the workflow of contribution.

  1. It's been a few days since I asked to be assigned to this issue. It's so annoying that we have to wait so long to get started ๐Ÿ˜  Why don't the project maintainers respond to us quickly whenever we reach out to them on issues? waiting
  2. Ah finally they assign the issue to me! Now let's try to setup the project... Oh no I'm seeing some errors but the documentation doesn't say anything about them. This is wasting so much of my time and I haven't event got to actually working on the code yet! ๐Ÿ˜“ Why isn't the documentation clearer for the setup?
  3. Phew... finally managed to set up the project and now we can get to coding. Let's check the issue on what has to be fixed and how to fix it. Wait... I was actually assigned to this issue without any further instructions? ๐Ÿ˜… How do I even start fixing this issue when I have never worked on the codebase and also never used any of the tech stack before? computer-guy-png-2.png
  4. Okay I think I finally managed to somehow to figure out how to work on the implementation by myself. Feeling awesome now - let's open a PR and wait for it be merged! Wait... why are there changes requested now on my PR? Does that mean I'm actually not awesome? โ˜น๏ธ Offended-Seriously-Computer-Guy-Meme_408x408.jpeg

So what should you do when you experience thoughts like the above? ๐Ÿง Some of these experiences are inevitable regardless whether you are new to open source or not. However, all of them are definitely detrimental to your Hacktoberfest experience and your perception of the open source community.

Below are my personal advice for you to enjoy Hacktoberfest better.

As a newbie, there will be some hopes of receiving more handholding and guidance from the community. I think it is important to point it out that you should not ever translate those hopes into expectations of entitlement. Yes, there exists a git blame command, but don't practice the act of pushing those expectations onto others when it comes to collaboration - more so if it's an open source project. In an open source project, while you are working on a voluntary basis as a contributor, most of your project maintainers work on a voluntary basis too. They will have other commitments outside of that project too.

If you do encounter some of the scenarios above, while some of them may cause some unpleasantness, there are certain mind switches and approaches you can try to improve your Hacktoberfest experience.

1. If you ask to be assigned an issue and you don't get a response quickly

So be it. Don't bug the project maintainers. Please.

A healthier mindset is to treat open source contributions like a side project. There is no hard commitment from anyone and don't wait for things to happen. If they do happen, then it's good. If they don't, so be it. Don't force it.

Anyways, if you are really hungry to work on open source projects immediately, there are other projects that you can work on in the mean time. It is ok to take on multiple issues from different repositories concurrently.

2. If you face problems in setting up your project despite following the docs

If it is a problem that is not written in both the setup and troubleshooting docs, check for any existing duplicate issues first before making a new issue for it.

  • If you can fix it on the spot, just make a PR for it โœ“.
  • If it is something you don't know how to fix:
    1. You can choose to reply to the issue that you met that problem to get some help from the project maintainers
    2. Try looking around to see if they have a discord or slack support channel to seek help.

In either choice, be sure to elaborate on how you met the issue. Some support channels I've seen actually have wholesome community members go out of their way to reclone the repository and repeat the steps you took to help you troubleshoot the problem you met.

And remember - don't vent or resent, keep the environment safe and comfortable for the community to give you support ๐Ÿค—

3. If you're not sure how to work on an issue

Don't shout for help just yet! Learn to adopt a self-service and self-learning mentality, a mindset advocated by GitLab.

If you're new to the tech stack, this is a chance for you to learn about the tech stack - look through the abundance of tutorials available online to grasp the concepts and compare it to how the project uses it.

If it's HTML, CSS, vanilla JS, and you can't tell what component is what and where it is used, always use the browser inspector. Don't get caught hacking though ๐Ÿค.

Using the element's id or class, you could search for it much more easily in the project.

Here's an example of the sidebar component from Forem that is not Preact Inspector showing popup above sidebar component to preview what classes the component has

Search Results in Visual Studio Code 10 results shown. 1 .scss, 9 .erb files

As you can see, your search will be trimmed down significantly from thousands of files to less than 10. From the search results, you can find the stylesheet that the classes are declared in. To find out which is the actual file that the sidebar component resides in, you can inspect the HTML hierarchy in the website and compare it to the files and make precision guesswork. This is actually what I did in my first pull request ๐Ÿ˜„

Having this self-service and self-learning mentality will help you grow down the long road ahead, especially when you want to be a self-taught learner and don't have access to regular/immediate support in your journey.

4. If you are requested to make changes on the PR

If you are requested to make changes on the PR, understand that it is actually a super common thing to happen. There's nothing wrong with what you did to address the issue. Your efforts are definitely not wasted. In fact, it is your efforts that made the path to the ideal solution much clearer than before.

It's the same as working with others in a team in real life, your initial solution may not always accepted by the team and there could be revisions required to make it better.

Sometimes, you could also get a pull request reviewer who is different from the maintainer that assigned you the issue. That person may then shed a new perspective to the issue and propose to you a better way of implementation to address it. Treat him/her like a free mentor โœจ, that way you get to learn a lot more out of working on that contribution!

And If ever you do feel burnt out working on a contribution because of the many interactions back & forth, remember that contributions are on volunteer basis. It's totally fine to take a break and get back to it later. It's also okay to give up on it too if you don't want to work on it anymore too. We all have our priorities, do what sparks joy for you. But just don't go ghosting! Be transparent and the project maintainer know if you're no longer working on it, so that someone else could possibly resume from your progress. I'm sure that they still appreciate what you have done thus far ๐Ÿค—.


Conclusion

I hope the tips that I have given you to manage your expectations about the open source community and your contributions, will help you to get the best out of Hacktoberfest and enjoy it much better! โœจ

On a side note, I would recommend you to watch the Open Source Symposium livestream recording. At this event hosted by Hashnode, there are man inspiring speakers who shared their experience working on and maintaining open source projects. Some stories hit home, and there was a simple yet deep quote by Matteo Collina that I really like as he was talking about the topic of being a good open source citizen.

If you're in open source, be kind.

How often do we remember to be kind to others, especially in the cyber space where most of the people you meet are strangers? We live in different parts of the globe and that meant living in different environments, cultures, timezones, and languages.

  • Not every senior developer and engineer you meet has a GitHub profile.
  • Not every open source project have an established and active team behind it.
  • Not everyone uses Mac or Linux for development.
  • Not everyone knows how to articulate their thoughts clearly.
  • Not everyone knows the proper channels to go to for asking questions or posting certain content.

Be kind. Put aside your prejudices, assumptions, and believe that each of us are trying our best to make the development eco-system and our open source projects better ๐Ÿค— That includes towards yourself too, don't beat yourself up if you ever make mistakes in the process of making open source contributions.

To be in development, you have to learn through endless mistakes after all.


โœ๏ธ Whenever you are ready, feel free to pen down your stories of the open source contributions during Hacktoberfest and share them. Just for 2021, you will be able to get unique badges from dev.to, CodeNewbies, and Hashnode โœจ

๐Ÿ‘‰ Lastly, remember to checkout the Hacktoberfest website to see the contributions you have made so far - or sign up if you haven't already!

Let's get the best out of Hacktoberfest 2021 together !


If you find this useful, hit the reactions ๐Ÿงก, feedback ๐Ÿ’ฌ, and share ๐Ÿฆ!

To stay updated whenever I post new stuff, follow me ๐Ÿง here and Twitter

Did you find this article valuable?

Support Estee Tey by becoming a sponsor. Any amount is appreciated!

ย