DEV Community: Jeanine Duchaney

Professional communication for Hacktoberfest 💬

Jeanine Duchaney — Tue, 29 Oct 2024 02:11:34 +0000

Welcome to 6 Things They Don't Tell You About Hacktoberfest (When You're Learning to Code). In this series, we’re sharing tips for self-taught coders that the official Hacktoberfest resources may not cover.

Please note that, while contributors can use either GitHub or GitLab to participate in Hacktoberfest, we’ll only be discussing GitHub in this article.

If you're interested in becoming a part of the open-source community through Hacktoberfest, you're likely here because you want to help. One of the best ways contributors can be helpful to organizers and maintainers is through professional interaction.

You likely won't find many Hacktoberfest guides on how to write a descriptive yet concise commit message or tactfully respond to feedback on your pull request, so most of the responsibility falls on you to learn these skills on your own. With that said, there are certainly some faux pas to avoid.

In addition to the obvious (e.g. don't type in all CAPs, repeatedly post the same message, or be otherwise spammy to get noticed), here are a few callouts:

Read before you ask

Recently, I learned of the phenomenon RTFM. While I don't necessarily support such a demeaning approach to “helping” first-time contributors, I can empathize with the point of frustration from which it stems.

Earlier this month, I attended one of Digital Ocean's virtual Hacktoberfest events. Over the course of two and a half hours, I watched as the moderators practiced tremendous restraint, graciously answering the same questions over and over again when I know deep down inside they really wanted to say, "Bestie, respectfully, ✨ read the website ✨." As the month progressed, I observed this trend continue via the Hacktoberfest Discord.

Folks, I just know the team over at DigitalOcean did not spend weeks lovingly compiling their FAQ page just for all y'all not to read it and then repeatedly ask them the same questions.

The same goes for repositories. I can't count the number of times I've seen a maintainer comment, "Please don't ask me to assign an issue to you. Just submit the pull request," only for someone else to comment directly below them asking to be assigned.

Granted, we all make mistakes. But many mistakes can be avoided by simply scrolling up a bit. So take the time to read the README and CONTRIBUTING files; your maintainer will thank you.

Be respectful of maintainers' time

The second thing that surprised me was the number of people I saw on GitHub and in the Hacktoberfest Discord following up with maintainers if they didn't receive a response within two hours.

Please remember that maintainers are people with full-time jobs, families, and otherwise busy lives. Always behave respectfully and exercise patience. Do not act demanding of their attention or entitled to their time; it only reflects poorly on you and hurts your job prospects.

Keep in mind that many maintainers are volunteering their time, dedicating nights and weekends to manage these repositories and review your contributions. They're not just sitting at home by the computer all day waiting for your pull request to come in. In fact, they might not even be in your time zone.

Furthermore, maintainers receive an overwhelming volume of messages, comments, and pull requests during Hacktoberfest season. It's not unusual for pull requests to take days or even weeks to be reviewed. Please rest assured that they are likely working their way down the queue to yours.

The next time you feel the impulse to follow up, pause, take a deep breath, and put yourself in their shoes. Ask yourself, "Has it really been that long since I reached out to them?" As a rule of thumb, I recommend waiting at least a week before following up.

If you DO determine it's appropriate to follow up...

...consider phrasing it like this:

"Hi @[MODERATOR_NAME]! I'm kindly following up on my pull request. Will you have time to review before October 31?

If you don't have the bandwidth, I completely understand. I would just like to know if this is the case, so I can pick a different repository to work on for Hacktoberfest. Thanks in advance!"

Ok, maybe that's a bit verbose, but you get the point. Offer a gentle nudge, clearly stating how their response affects your next steps.

Conclusion

Regardless of whether you're entry-level or senior-level, working professionally requires a baseline level of autonomy. While it's ok to ask for help, you shouldn’t expect your maintainer, mentor, or manager to hold your hand. This means getting comfortable with trying to look up answers by yourself before asking for help. It also means getting a feel for when is the right time to ask for help and how to go about asking.

Like everything else, these processes can only be learned through practice. Take Hacktoberfest—and more broadly, open-source—as an opportunity to develop these habits, so you're ready to hit the ground running when you land your first developer role.

✒️ Contributors, what are some rookie mistakes you've made in the past that you wish someone had warned you about?

📝 Maintainers, what are some of your pain points that you wish more new coders were aware of?

Comment below and let's spread the knowledge!

This is a submission for the 2024 Hacktoberfest Writing challenge: Contributor Experience

The hardest part of Hacktoberfest isn't the code 🚫

Jeanine Duchaney — Tue, 29 Oct 2024 02:11:26 +0000

Please note that, while contributors can use either GitHub or GitLab to participate in Hacktoberfest, we’ll only be discussing GitHub in this article.

You heard right, folks. The hardest thing about Hacktoberfest isn't the coding itself. It's figuring out how to test your code.

Ok, maybe this one's just me. Maybe there's a bit of selection bias involved. (i.e. You're obviously going to sign up to fix issues you feel qualified for.) And maybe there's a lot of back-end folks laughing at me right now. But hear me out.

When you begin learning simple web development, every tutorial just says to open your examples directly in the browser. So this is coming from someone who's spent the past several months writing code in Visual Code Studio, then just double-clicking HTML files in File Explorer to pop them open in Chrome. You can't exactly blame me for not knowing I'd have to download Ruby and Jekyll to see a simple, one-line footer I added in HTML.

Because each repository is unique and there are so many different tech stacks, I unfortunately can't write you a step-by-step guide for setting up your environment. After all, that's the repository's README or CONTRIBUTING files' job. And did I mention I don't 100% understand it myself yet? (Though MDN does offer some helpful background.)

Anyway, that's not the point. This article is moreso a heads-up that Hacktoberfest will have you downloading software you've never used before and may not use again for quite some time, depending on what stage you're at in your learning journey.

The important thing is not to let it deter you. Sure, figuring out what you need to download, how to download it, and what commands you need to get it to work may end up taking more time than the coding itself. But you'll come out more knowledgeable for it.

Conclusion

Let this and the previous post serve as the FYI I wish I had. No matter how productively you spend your Preptember, you're not going to know everything going into Hacktoberfest. You're going to have to pick up some knowledge on the fly, just like in a real engineering job. So mentally prepare yourself, but definitely don’t let it stop you.

This wraps up my PSA about what the tutorials don't teach you. In the final post of this series, we'll be exercising our soft skills. NEXT POST ▶️

✒️ Contributors, what are some rookie mistakes you've made in the past that you wish someone had warned you about?

📝 Maintainers, what are some of your pain points that you wish more new coders were aware of?

Comment below and let's spread the knowledge!

This is a submission for the 2024 Hacktoberfest Writing challenge: Contributor Experience

GitHub's help resources will only get you so far with Hacktoberfest 📖

Jeanine Duchaney — Tue, 29 Oct 2024 02:11:19 +0000

Please note that, while contributors can use either GitHub or GitLab to participate in Hacktoberfest, we’ll only be discussing GitHub in this article.

One misconception I had when I started Hacktoberfest was that I would not have to touch the command line. After all, I had been teaching myself HTML, CSS, and JavaScript for the past few months and had managed to avoid it thus far.

From what little I understood about version control, I knew that GitHub was based on Git. I just thought GitHub was a standalone visual interface that would allow me to never have to use Git through the terminal window.

As I quickly learned, GitHub often works in conjunction with—not instead of—Git. Some steps, such as forking a repository and creating a pull request, are usually performed through GitHub. Others, such as cloning the fork to your local machine and staging, committing, and pushing changes, are frequently done through the command line. You'll regularly find yourself tabbing back and forth between the two windows throughout the pull request workflow.

This also means that GitHub's help resources will only get you so far. The first time I tried following along with the Contributing to a project tutorial on GitHub Docs, I got hopelessly stuck trying to create a branch using Git Bash, receiving the error message fatal: not a valid object name: 'master'. When I reached out to the GitHub Doc's team for help, I was respectfully told that, because Git Bash is not their product, they unfortunately were limited on what troubleshooting tips they could include in the article. In the end, it took me three hours to figure out I was in the wrong directory.

The punchline is that I later found out that I actually could have cut out the command line entirely by simply using GitHub Desktop. But I view this oversight as a happy accident. MDN posits that learners will benefit from practicing at least the basic Git terminal commands. After having been through it myself, I have to agree.

The moral of the story is not to rely on GitHub to solve your Git problems. If you're able to figure out how to use Git with no prior knowledge of the command line using only GitHub Docs, it likely means you never pushed yourself to open Git Bash in the first place.

In this line of work, using the command line is inevitable and avoiding it will only get you so far in your career. So don't fear or resist it like I did; jump right in and embrace the uncertainty.

Conclusion

I went into Hacktoberfest expecting that everything I needed to do on GitHub could be done through the browser. My advice to you is to let go of any such preconceived notions.

Yes, you can avoid the command line for a good, long time if you really want to, but don't.

Yes, everything—from the Ctrl+Shift commands to new ways of navigating the cursor—will take some getting used to. (Terminal? Command line? Am I even using these terms correctly?) But take some confidence in knowing that you don't have to wait until you feel "ready" to start putting real contributions out into the world.

There is another instance during Hacktoberfest where you might unwittingly find yourself using the command line. We'll discuss it in the next post. NEXT POST ▶️

✒️ Contributors, what are some rookie mistakes you've made in the past that you wish someone had warned you about?

📝 Maintainers, what are some of your pain points that you wish more new coders were aware of?

Comment below and let's spread the knowledge!

This is a submission for the 2024 Hacktoberfest Writing challenge: Contributor Experience

The BEST way to search for a Hacktoberfest repository 🔎

Jeanine Duchaney — Tue, 29 Oct 2024 02:11:12 +0000

Please note that, while contributors can use either GitHub or GitLab to participate in Hacktoberfest, we’ll only be discussing GitHub in this article.

Now that we understand what does and does not count toward Hacktoberfest, it's time to start looking for issues to work on.

Unfortunately, it’s harder than you might think to find issues that are (1) inside a participating repository, (2) within your skillset, and (3) not already assigned to someone else.

Problem

Conventional wisdom says to browse the Hacktoberfest topic on GitHub. What no one talks about is how user-unfriendly this process is.

With nearly 150,000 participating repositories, the feed is set up as a continuous scroll, and users lack the ability to jump from page to page. Unless you want to spend the next several hours clicking the “Load more…” button, it's nearly impossible to access the wealth of repositories in the center of the pack. While users do have the ability to sort, this still leaves everyone crammed at the top and bottom of the list.

The only option you're left with is to filter repositories by language. However, this alone still might leave you with a bunch of projects that are out of your league. When you're first starting out, you may want the ability to apply additional search criteria, such as the "first-timers-only", "beginner-friendly", and "good-first-issue" labels.

Good news! You can.

Solution

The Hacktoberfest website points to several third-party resources, some of which allow you to achieve this filtering to varying degrees. (My personal favorite is Up For Grabs.) Likewise, the project-sharing forum on the Hacktoberfest Discord proves less overwhelming.

With that said, I’ve found the most flexible solution is simply to use the GitHub search bar. This can be effective if you know how to do it properly.

Searching for repositories

Say you want to search for repositories that contain CSS, have the "hacktoberfest" topic, and have at least one issue with the "good-first-issue" label. Just type the following into the search bar:

language:css topic:hacktoberfest good-first-issues:>0

Note that the last qualifier only works with the "good-first-issue" and "help-wanted” labels. For example, the following syntax would yield an error message:

first-timers-only:>0

Searching for issues

You can also search for issues instead of repositories. Say you want to filter by open issues that have the "hacktoberfest" and "beginner-friendly" labels and are within repositories that contain CSS. Try entering the following into the search bar:

type:issue state:open label:hacktoberfest label:beginner-friendly language:css

If you use this method, just double check that the repository you select also has the "hacktoberfest" topic. Remember, labels and topics are two different things in GitHub. If the issue has the "hacktoberfest" label but the repository does not have the "hacktoberfest" topic, your pull request will not count. (Confusing, I know. See our prior post.)

Can't I just filter by issues with XYZ label that are inside repositories with the "hacktoberfest" topic?

As far as I can tell, GitHub is not capable of searching for issues with specific labels that are within repositories with specific topics. In other words, you cannot combine the label and topic qualifiers. This is because the "label" qualifier is not supported when searching repositories, and the "topic" qualifier is not supported when searching issues. Therefore, you can only search by one type at a time (i.e. repositories or issues).

Have you found a workaround to this problem? If so, please let me know in the comments!

Conclusion

By mixing and matching the search criteria to suit your needs, you can narrow down the number of results from several thousand to a few dozen. This might seem like a no-brainer if you're familiar with GitHub, but it's a game changer if you're new to the platform.

I’ll leave you with some closing tips:

Make sure you use quotes around multi-word search terms. For example, to search for issues with the label "up for grabs," type label:"up for grabs", not label:up for grabs.
Search terms are not case sensitive.
If you prefer a visual interface, you can also use GitHub's advanced search page. However, I find this option offers less flexibility.

See Search on GitHub on GitHub Docs for everything you need to know on this topic and more.

We're now up to speed on finding repositories to work on. In the next two posts, we'll shift gears and explore a couple of the unexpected things you might encounter while working on those repositories. NEXT POST ▶️

✒️ Contributors, what are some rookie mistakes you've made in the past that you wish someone had warned you about?

📝 Maintainers, what are some of your pain points that you wish more new coders were aware of?

Comment below and let's spread the knowledge!

This is a submission for the 2024 Hacktoberfest Writing challenge: Contributor Experience

The difference between merged, accepted, and reviewed in Hacktoberfest 🚦

Jeanine Duchaney — Tue, 29 Oct 2024 02:11:04 +0000

Please note that, while contributors can use either GitHub or GitLab to participate in Hacktoberfest, we’ll only be discussing GitHub in this article.

While browsing Hacktoberfest repositories, I noticed some maintainers had requested that contributors do not ask them to assign issues. (i.e. "If you want to work on an issue, just do it and then send me a pull request.")

This made me wonder: If an issue isn’t assigned, who receives credit if multiple people make pull requests that fix it? If each of them comes up with a different—yet conflicting—answer to the same problem, does the first contribution that’s submitted get merged, or is it the solution that the maintainer likes the most?

Furthermore, does only the pull request that gets merged count? In other words, is it possible for more than one contributor to receive credit for working on the same issue, or do we as contributors have to race each other to claim dibs?

The answer to all of the above questions is: it depends. To understand why, let's examine the multiple ways maintainers can approve pull requests.

Merging a pull request in a repository with the "hacktoberfest" topic

The "hacktoberfest" topic is the most automated means by which contributions are approved. Assuming both the repository and pull request align with Hacktoberfest's values, a contribution will count as long as (1) the pull request has been merged and (2) the repository has the "hacktoberfest" topic.

Seriously, that's it! As long as these two criteria are fulfilled, no further action is needed by either the maintainer or the contributor. Issues, commits, and the "hacktoberfest" label aren't counted, as we discussed in the previous post.

See Incorporating changes from a pull request on GitHub Docs for more details on merging.

Giving a pull request the "hacktoberfest-accepted" label

The "hacktoberfest-accepted" label is a workaround for maintainers to manually approve one-off pull requests if one or both of the aforementioned conditions are not met. Think of it as a catchall. Note that pull requests must be marked "ready for review" (NOT "draft") in order to qualify for Hacktoberfest credit.

To answer our opening questions, it's completely up to the maintainer if and how they apply the "hacktoberfest-accepted" label. Some maintainers may, in fact, operate on a first-come, first-serve basis. Others, if they have more time on their hands, might be able to award credit to multiple contributors in the event of duplicate pull requests.

What are some other situations where a maintainer might use the "hacktoberfest-accepted" label?

The repository does NOT have the “hacktoberfest” topic

Say you regularly contribute to a repository year-round. Unfortunately, the maintainers don't have the bandwidth to participate in Hacktoberfest.

Given you already have an existing relationship with the maintainers, you might kindly ask if they'd consider applying the "hacktoberfest-accepted" label to your pull request. This way, you can receive credit without the maintainers having to open the floodgates to all Hacktoberfest contributors.

The pull request is NOT merged

Perhaps you submitted a meaningful contribution, but the maintainers determined your pull request wasn't quite ready to merge as-is. Instead of asking you to make the necessary changes, they might simply add the "hacktoberfest-accepted" label to your unmerged pull request in appreciation of your effort.

At the end of the day, maintainers are free to use the "hacktoberfest-accepted" label at their own discretion, and contributors are asked to respect their decisions.

Giving an overall approving review to a pull request in a repository with the "hacktoberfest" topic

Some maintainers have structured their repositories so that any new pull requests must undergo rounds of checks before they can be merged. Think of it like a rubric that's automatically attached to your pull request when you submit it.

For example, say a repository has five maintainers. They may set up their repository so that pull requests require approving reviews from at least two of them before merging is enabled. Or if a specific maintainer's sign-off is required, they can configure the repository so any new pull request reviews are automatically assigned to that person.

By requiring multiple checkpoints, maintainers can ensure their teams are aligned on internal requirements. Having more eyes to catch mistakes also safeguards against errors slipping through the cracks.

An "overall approving review" generally means the pull request has passed the minimum criteria to be merged, even if it has not been merged yet. Look for the checkmarks!

Finally, note that pull requests must NOT be closed in order to count for Hacktoberfest via an overall approving review.

See Reviewing changes in pull requests on GitHub Docs for everything you need to know about reviews.

Conclusion

Circling back to the scenario at the top of the article, we've now learned that it is possible for multiple contributors to receive credit for fixing the same issue, as long as the maintainer applies the "hacktoberfest-accepted" label to each of their pull requests. However, given Hacktoberfest is a busy time of year for maintainers, it's not guaranteed that they will have time to do so.

With this in mind, it's probably still a good idea for you to drop a comment in the issue to say you're working on it, if nothing else but for the benefit of other contributors. Feel empowered to take communication into your own hands, even if the maintainer isn't assigning issues, and others will appreciate your effort to help mitigate confusion.

Over the last two posts, we've summed up what to look for in a repository. Now, let's go over how to look for a repository. NEXT POST ▶️

✒️ Contributors, what are some rookie mistakes you've made in the past that you wish someone had warned you about?

📝 Maintainers, what are some of your pain points that you wish more new coders were aware of?

Comment below and let's spread the knowledge!

Image courtesy of Naomi Plasterer

This is a submission for the 2024 Hacktoberfest Writing challenge: Contributor Experience

Just because it says “hacktoberfest” doesn’t mean it counts toward Hacktoberfest ⚠️

Jeanine Duchaney — Tue, 29 Oct 2024 02:10:44 +0000

Please note that, while contributors can use either GitHub or GitLab to participate in Hacktoberfest, we’ll only be discussing GitHub in this article.

You know when you're playing a video game with friends and you realize you've spent more time customizing your characters than actually playing the game? That's how it can feel sometimes when you're trying to find a repository to work on for Hacktoberfest.

At first glance, all you should have to do to find a participating repository is look for the "hacktoberfest" topic. Sounds pretty straightforward, right?

In truth, there are a number of reasons why an ineligible repository might appear deceptively promising. Let's break down some common pitfalls.

An issue has the "hacktoberfest" label, but its repository doesn't have the "hacktoberfest" topic

When you're new to Git and GitHub, the jargon can feel pretty indecipherable. Topics? Labels? What's the difference?

The two can be pretty difficult to tell apart given how similar they look. As it turns out, though, labels pertain to individual issues, pull requests, and discussions. Topics, on the other hand, apply to the repository as a whole. (If that wasn't confusing enough, tags mean something else entirely, but that's another story.)

Here's an example of an issue that has the "hacktoberfest" label...

...within a repository that's missing the "hacktoberfest" topic.

This distinction is important, because Hacktoberfest tracks the "hacktoberfest" topic, NOT the "hacktoberfest" label.

In practice, this makes sense. It's less upkeep for maintainers to opt in the entire repository once rather than have to attach labels to every issue. Vice versa, if they subsequently decide to opt out of Hacktoberfest, they won't need to go through each issue removing labels one-by-one.

But if only the topic matters, why is anyone still using the label? You'll likely see maintainers giving issues the "hacktoberfest" label to organize their repositories internally or make their repositories easier for contributors to find. Alternatively, they themselves may be unclear on the rules and/or want to cover their bases.

If the former, they'll likely also have given the repository the "hacktoberfest" topic. Still, it's worth double-checking in case of the latter. While you’re at it, make sure the maintainer hasn’t made any typos.

With all that said, there is one instance where Hacktoberfest tracks labels: the "hacktoberfest-accepted" label. We'll look at this in more detail in the next post.

A note about issues

While we’re on the topic, it’s worth noting that you're not necessarily limited to existing issues. Issues are great for organizing what problems are and who's working on them. However, at the end of the day, Hacktoberfest only tracks pull requests, NOT issues or commits.

This means, depending on the repository's etiquette guidelines—typically outlined in the README file and/or other documentation, often titled CONTRIBUTING, HACKING, or similar—you’re sometimes free to create your own issues if you identify meaningful areas for improvement.

In some repositories, creating an issue may be an optional step. On rare occasions, the maintainer might even prefer you skip over the issue altogether and jump right to submitting a pull request. In either case, the pull request does not need to be attached to an issue to count toward Hacktoberfest.

Every repository is unique, so approach each one on a case-by-case basis.

The repository is invalid

The Hacktoberfest rules state, "Bad repositories will be excluded." But what does this look like in practice?

When I began looking for repositories, one of the first things I did was Google "hacktoberfest beginner". Wouldn't you know it, the following repository popped up as the first search result:

"What luck!" I thought. "A repository made just for someone like me."

I clicked the link, went through the README, and was ready to create a fork when I noticed one issue.

It turns out the well-meaning maintainer had inadvertently violated the Hacktoberfest rules regarding quality contributions. While GitHub users could continue utilizing it as a learning resource, any contributions make to this repository ultimately would not count toward their Hacktoberfest quota.

Given the repository had "hacktoberfest" in the title and the README did not indicate that the repository had been excluded, I easily could have submitted a pull request without ever having noticed the issue.

Lesson learned: If you stumble upon a repository that seems too good to be true, click around first to make sure it's legitimate. And, of course, make sure your own contributions align with the Hacktoberfest values. (I'm looking at you, spammers!)

The repository is inactive

Next, I tried filtering the "hacktoberfest" topic by language. The fourth search result was a repository that I thought looked approachable.

Not only did it include the "hacktoberfest" topic, it also showed no signs of having been reported. So far, so good.

I proceeded to review the README and CONTRIBUTING files and was all set to fork the repository when, once again, I noticed an issue.

In it was a disclaimer stating that issues were no longer being reviewed and pull requests wouldn't be merged. Furthermore, the maintainer specifically mentioned, "If you're looking to contribute here for Hacktoberfest or other similar events, this would not be a good repository to contribute to."

Considering this repository fell near the top of the search results, this message was pretty easy to miss. Sure enough, it looks like not everyone got the memo.

The takeaway? Even if you put in the time and effort to make a meaningful contribution, it won't count unless the maintainer reviews it. Thus, check the repository for signs of recent activity. If there haven't been any commits for months, consider leaving a comment asking if the repository is still being monitored. If no one responds, then you have your answer.

Lastly, if you are a maintainer, please consider removing the "hacktoberfest" topic from your dormant repositories to reduce confusion for contributors. Even if it's not logistically possible to track or enforce, it’d be great to see at least a cultural push within the Hacktoberfest community encouraging maintainers to clean up their repositories’ topics and labels.

Conclusion

As you can see, several factors can quickly add up to make finding a repository harder than it looks. The process might even end up taking longer than the coding itself!

Now that we've cleared up some of the nuances that could disqualify your pull request, let's talk about the various ways your pull request can be approved by the maintainer. NEXT POST ▶️

✒️ Contributors, what are some rookie mistakes you've made in the past that you wish someone had warned you about?

📝 Maintainers, what are some of your pain points that you wish more new coders were aware of?

Comment below and let's spread the knowledge!

This is a submission for the 2024 Hacktoberfest Writing challenge: Contributor Experience

Introduction 🎃

Jeanine Duchaney — Tue, 29 Oct 2024 02:10:19 +0000

Please note that, while contributors can use either GitHub or GitLab to participate in Hacktoberfest, we’ll only be discussing GitHub in this article.

There are a lot of excellent articles out there if you're interested in learning about Hacktoberfest, open-source, or Git and GitHub. Many of them come from reputable sources like GitHub Docs, GitHub Skills, and DigitalOcean, the company that hosts Hacktoberfest.

No matter how beginner-friendly they claim to be, however, it sometimes can feel like everything assumes a baseline level of knowledge, especially when you're just starting out. As someone who found myself below this baseline, I was left learning any topics that weren't explicitly covered on the Hacktoberfest website through good ol' fashioned trial and error.

In the spirit of open-source, I wanted to help raise others above this baseline by filling in some of these knowledge gaps. Here are six lessons from my first year of joining Hacktoberfest.

But first…

Why should beginners participate in Hacktoberfest?

Get started using Git and GitHub

The first time I heard about Hacktoberfest, I had already been teaching myself HTML, CSS, and JavaScript for quite some time. All the while, I had managed to avoid Git and GitHub.

I'm ashamed to admit it, but I rationalized putting it off for months. I told myself, "I'm still just coding by myself! It's not like I need to learn how to work with a team quite yet." 🤡

Eventually, though, my conscience got to me, and I faced the fact that I needed to familiarize myself with version control. Hacktoberfest was just the kick in the pants I needed to quit procrastinating and start holding myself accountable.

Practice soft skills like collaboration, problem-solving, and resilience

In addition to getting your feet wet with Git and GitHub, Hacktoberfest is a great place to start building soft skills. While soft skills like communication are just as important as hard skills like programming, they are sorely underemphasized when you're learning to code.

Hacktoberfest is a beginner-friendly environment where you can safely practice soft skills like managing uncertainty, self-soothing the imposter syndrome, and the ever-important art of Googling.

If you've only ever coded in the privacy of your local machine, Hacktoberfest is an excellent opportunity to start putting yourself (and your code) out there.

Conclusion

If you're a newcomer to Git and GitHub, open-source, or coding in general, don't let lack of experience deter you from participating in Hacktoberfest. Instead, consider it a chance to gain exposure to high-level topics far sooner than you would have on your own.

Without further ado, let’s dive into the six things I learned from my first time participating in Hacktoberfest. We'll start by demystifying some of the rules that are outlined on the Hacktoberfest website. NEXT POST ▶️

✒️ Contributors, what are some rookie mistakes you've made in the past that you wish someone had warned you about?

📝 Maintainers, what are some of your pain points that you wish more new coders were aware of?

Comment below and let's spread the knowledge!

This is a submission for the 2024 Hacktoberfest Writing challenge: Contributor Experience