Hacktoberfest 2020 had a rocky start. I’m not here to argue against any of the criticisms brought up by other members of the community. Their feedback is not unfounded. However, I don’t believe it was all bad.

I signed one of my weekend projects up for Hacktoberfest to gain some more experience in a maintainer role rather than an individual contributor role. In this regard, I believe Hacktoberfest 2020 was a successful experience for myself and for the contributors who spent their time and energy submitting patches to my project.

What follows are some of the lessons I’ve learned through this experience.

Disclaimer

Before getting into it, I’ll just throw a disclaimer up. I’m perfectly aware that my sample size of 1 does not reflect the state of all open source projects. Furthermore, this experiment was entirely fueled on an event that offers contributors a chance at getting a free T-shirt.

However, a maintainer can’t control the reasons why contributors to contribute. There are a number of reasons why people might contribute:

• They are paid to contribute
• They want to fix something they’re experiencing
• They want to sharpen their own skills on a project that uses a language or tools or some underlying concept they want to learn
• They want to win a free T-shirt

To a maintainer, the experience is more or less the same regardless of what motivates a contributor to contribute. At least, for legitimate contributions.

More momentum = more contributions

What I mean by momentum is the activity levels that an open source project produces. For very large projects, it almost looks like this bus drives itself. Ubiquitous projects, either through popularity or practical use, see hundreds if not thousands of issues filed against them. Patches/pull requests/merge requests may meet or exceed even the number of issues filed against them.

Regardless, the more popular or ubiquitous a project is, the more work it is generating. These are all opportunities for contributions.

For a smaller project–much less a project that no one uses or cares about (not trying to diss myself, but really, who uses Trivial File Transfer Protocol in 2020?)–contribution opportunities are not as visible.

The maintainer must make these tasks obvious by filing issues themselves.

I found that the more issues I filed, the more pull requests I would get. In fact, a quick look through all pull requests not authored by me reveals that 100% of the pull requests from other people are associated with an issue that has already been filed.

Furthermore, I’ve noticed that when I stopped filing issues, the new contributor count started waning.

My takeaway from this is that it is encouraging to new contributors to see visible work as a jumping-off point for them to get started with making contributions.

Generally, this will be issues/bugs filed in some kind of project tracker. I also consider reviewing pull requests as contributing; however, during my experiment, only one contributor reviewed someone else’s work on the repo and they only did so after having some of their own patches merged.

Removing ambiguity increases contributions from new/inexperienced contributors

Speaking of visible work, I’ve found it is helpful to remove ambiguity from bugs/issues filed in the tracker. Some might argue this is almost to the point of spoonfeeding. I don’t think so.

Clearly stating the acceptance criteria and providing a loose outline of hints for how one might orient themselves to the task and the part of the codebase that it pertains to resulted in a large number of well-defined issues being closed on my repo during Hacktoberfest.

It can be tempting to write the bare minimum that you believe will jog your memory of what must be done while working on a project with a close-knit team of people who are responsible for different parts of the codebase (or just by working by yourself).

Fight that urge. If it will take a significant amount of time to decompose the task in this way when you’re filing the issue, then the issue can be marked as a meta or a large-scoped issue. I’d encourage you to revisit the issue and break it down further when your schedule allows. The advanatages of this are two-fold:

1. A little bit of time designing can save a lot of time coding
2. Someone else might do the work for you if they have some clue what a way forward might look like

It takes up a lot of your time

I get it now. Before, I was sympathizing. Now, I’m empathizing. I know from my day job that reviewing code, especially for larger changes, takes a lot of time and energy. I maintained a much smaller project during Hacktoberfest than I do for work. I’m also paid to do those things at work; but no one is paying me for my toy TFTP project :-)

Encouraging contributions, reviewing them, and shepherding them all the way through to be merged can take a lot of time. Some pull requests might take 5, 10, 15 minutes to review. Others might take 30 minutes or an hour. They might also require more than one pass over while you cogitate over it!

Sometimes this time investment just isn’t palatable if you’ve had a tough week at work, or if you want to invest your spare time in some of your other hobbies, or spend time with people you care about, etc.

Overall

To a lot of the internet, it seems like Hacktoberfest as a net negative. It was worth it to me, though. I got to learn a lot about maintaining a project in a controlled environment.

In hindsight, much of this article reads like common sense. I’ve found that after spending too much time in the weeds with one workflow or another, sometimes we lose sight of the fundamentals. A little reflection is always a breath of fresh air.

My hope is that some of the contributors, especially those that struck me as newer to the software field, took something away from this process, too.