Preparing for Hacktoberfest contributors

Hacktoberfest is almost upon us. If your project is participating, you’ll want to make sure you’re ready for an influx of new contributors. If you’re not prepared, you’ll overwhelm your existing team and give new contributors a bad first impression.

How Hacktoberfest is different

When you’re recruiting new contributors, you typically only work with a few people at a time. I many cases, they’re long-time users of your project. They may already be active on mailing lists, in issues, or on other parts of your project. You’re bringing them into your project because they’re invested in it, they have skills your team needs, or both.

Hacktoberfest — and other public hackfests, to be fair — are different. Many of them aren’t looking for long-term participation in a project. They may just be after a t-shirt or a sticker. As a result, they may not be familiar with your project at all. A slim majority of Hacktoberfest participants are students, possibly making their first open source contributions.

This isn’t bad. So-called “drive by” contributions are still valuable. And people who have a good experience making what they think is a one-time contribution may wind up being long-term members of your project. But a burst of new contributors means you’ll need to scale up your ability to take on new people.

Prepare your governance

Hopefully you figured this out when the project started, but if you haven’t there’s no time like the present. Regardless of when you made these decisions, now is the time to make sure it’s well-documented.

First, what’s the license for your project? At a minimum, you should have the full license text in the repository, with a mention of the license in your README file (and the repo’s metadata if the forge supports it). For bonus points, include an SPDX license indentifier in each file.

Second, include your code of conduct. At this point, there’s no reason for a community project to not have a code of conduct. The Contributor Covenant is a standard, but you can find other good examples.

Finally, add your contribution guidelines. This should include things like documentation and code style, approval requirements, and other things you need people to know before they submit a contribution. This should include a policy on AI-generated submissions.

Prepare your repository

Before you get a rush of new folks, you want to get your repository(-ies) in shape. The first step is to go update your open issues and pull requests. Close anything that’s no longer valid. Update the current status and assignee of anything that’s in progress. Ensure that bug reports have reproduction information and feature requests have well-written requirements.

Next, make sure issues are well-labeled. Using a “good first issue” label or tag has become a common way to indicate an issue would be good for new contributors. You may also want to use other labels like “documentation”, “unconfirmed”, “needs testing”, “artwork”, and so on. Labels are a good way to give newcomers quick information about issues and pull requests, so you want to make sure they’re accurately applied.

Prepare documentation

I’ve touched on this already, but you’ll want to make sure your documentation is up-to-date before you welcome a horde of new contributors. Let’s be honest with ourselves: a lot of people won’t read it, but having published documentation saves you time because you can point folks to it instead of composing new replies every time. So what should you document?

At a minimum you need to document what you’ve come up with for the previous two sections: license, style requirements, governance, labels, et cetera. You also want to make sure you clearly document how to set up a development environment and run tests. If you have a chat system or mailing list/forum, document where to find those and any specific rules or customs you have.

And here’s the often-overlooked part: have someone who isn’t familiar with your project test the documentation. You’ve almost certainly made assumptions about what the reader knows because you’re so familiar with the project. Testing your docs will help your new contributors get up to speed sooner.

Make space in your schedule

According to a 2021 survey from Tidelift, maintainers spend roughly 25% of their project time writing code. For the month of October, you should plan on that being zero. Your effort needs to focus on helping the newcomers. And with the rise in popularity of generative AI, you will probably have more spammy submissions than you have in years past.

If you can, try scheduling office hours a few times over the month. This gives participants an opportunity to have real-time conversations with you. You can help them work through problems, answer questions, or just connect as humans. After all, open source is people.

This post’s featured photo by Kasia Derenda on Unsplash.