This content originally appeared on DEV Community and was authored by Jeanine Duchaney
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 ask them the same questions over and over again.
The same goes for repositories. I can't count how many 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 do take the time to read the README and CONTRIBUTING files; your maintainer will appreciate your attention to detail.
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 determine it is 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 job.
✒️ 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
This content originally appeared on DEV Community and was authored by Jeanine Duchaney
Jeanine Duchaney | Sciencx (2024-10-29T02:11:34+00:00) Professional communication for Hacktoberfest đź’¬. Retrieved from https://www.scien.cx/2024/10/29/professional-communication-for-hacktoberfest-%f0%9f%92%ac/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.