Hacktoberfest 2024: My 2nd Year Experience as A Maintainer

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

This year's Hacktoberfest marks my 2nd year as an open-source projects maintainer. How time flies!

If you're interested, check out my experience as a maintainer during Hacktoberfest 2023 in this post and my transition from contributor to maintainer in this post.

Another Year as A Maintainer

Unlike last year, when I still tried to figure things out and get the hang of it, I felt more relaxed during this year's Hacktoberfest. Maybe it's because I already have some experience maintaining the projects. I knew where to look when reviewing incoming PRs and have saved replies templates for various things that often come up when folks submit a PR.

Somehow, the joy of helping newcomers with open source never fades. I enjoy supporting them as best I can. However, as people often say, "Life is not always a rainbow," I've also experienced some frustration. I'm fortunate to have a team where we always back each other up, especially in times of frustration and burnout.

The Frustration: Recurring Issues

Skipping the Contributing Guidelines

The issue that frustrates me the most is when someone submits their PR without reading the contributing guidelines.

Every open-source project has its own rules for contributing to their project. As a contributor, you might need to ask permission to work on an issue in one project. But, for another project, you might be allowed to work directly on an issue. You can learn that by reading the project's contributing guidelines and observing previous PRs.

We regularly update our contributing guidelines to clarify contributing instructions. But that doesn't solve the issue. Even though we've asked contributors to read and given the link to our contributing guidelines, some were not trying to address it or did whatever they thought was best without reading it. That caused a back-and-forth conversation that would not have been necessary had they read the guidelines.

Taking the Issue Form and PR Templates for Granted

Some projects allow you to create a PR without creating an issue. However, for the projects I help maintain, we want contributors to submit an issue before they work on any changes. This way, we understand the changes they propose and whether we ever need them.

Last year, I felt heartbroken whenever I had to close a PR that didn't come with an issue. But this time, I know it's the best thing to do. This way, they can learn to read the contributing guidelines. They also can learn to communicate with maintainers before they jump into a solution.

I understand that PR templates can be intimidating. (Believe me, most maintainers wish there were a PR form instead of a template.) But don't make this an excuse for not completing the template or even deleting the template details and submitting an empty PR template.

Ignoring PR Review

This issue does not often occur. But I have experienced some contributors not answering questions or addressing suggested changes.

During Hacktoberfest, I noticed that folks might ignore PR reviews when they take too many issues from various projects or already have 4 PRs accepted.

My Expectations as A Maintainer from Contributors

Read the README and Contributing Guidelines

Reading the README and contributing guidelines of an open-source project is not an option. It's a must.

Please read the documentation before working on anything. How can you fix an issue if you don't know how to install or run the project? How do you know how to claim an issue, submit a PR, or communicate with the maintainer if you don't read the guidelines?

Reading the documentation can save you time contributing and building trust with the maintainers.

Submit an Issue Form

If you've read a project's contributing guidelines, you'll know whether you must submit an issue before creating a PR. If the project requires an issue, please submit one and wait for feedback from the maintainer before working on any changes.

Maintainers are people who understand the project's vision. They can decide whether a change proposal is necessary or not. Creating an issue and waiting for feedback will save you time from working on something that might not get accepted.

Complete the PR Template

Maintainers create a PR template to help make the contributing process smoother for contributors. The more information about the changes maintainers get just by reading the PR template, the easier and quicker their task of reviewing your PR will be. The bright side is that your PR can get merged in faster.

If filling in issue forms and completing PR templates still intimidates you, you can learn how to filling them in in this blog post.

Address Feedback from Maintainers

Yes, contributors volunteer their time for a project and may decide whether to finish or drop the task based on their capacity. But don't forget that many maintainers are also volunteers.

We want to review PRs as fast as possible during Hacktoberfest so the contribution can be counted towards the goal. If you need more time or don't have time to continue the task, communicate it to the maintainer so we can find the best solution.

Remember, communication is the key in open source (and any other field), and it is important to respect each other's time and effort.

Final Words

Being a maintainer brings joy and challenges. There are times when I get frustrated and need support from other maintainers. But at the same time, it's very satisfying to help and support contributors and see PRs getting merged.

What brings you joy as a maintainer, and what challenges do you face? You can share your answers in the comment section below so we can support each other!

Cheers to the next Hacktoberfest! 🥂

🖼️ Credit cover photo: Goran Ivos on Unsplash

Thank you for reading! Last, you can find me on X or Bluesky. Let's connect! 😊