Laureline Paris

Posted on Oct 31 • Edited on Nov 6

Hacktoberfest 2025 - Automating reviews

#devchallenge #hacktoberfest #opensource #automation

Hacktoberfest: Contribution Chronicles

This is a submission for the 2025 Hacktoberfest Writing Challenge: Contribution Chronicles.

" ✨ Another year, another Hacktoberfest community event and more involvements! ✨ "

Hacktoberfest is all about discovery, community, and contributing to open source — but it’s also about personal growth and challenging yourself.

🔸 Context

As in previous years, I'm participating in Hacktoberfest 2025 🙌 and once again pushed myself to grow!

I continue contributing to Animation Nation as both a maintainer and contributor, with a growing focus on creating meaningful impact within the project.

The repo focuses on collecting CSS animations — an awesome opportunity for contributors to practice styling and animation skills every year.

While the main purpose is animation submissions, we also occasionally welcome meaningful improvements. As maintainers, we sometimes go beyond animation contributions to help the project evolve.

🔸 Motivations

I care deeply about developer, contributor, and user experiences,
and I've become more impact-driven over time — so this year
I focused on improving the review process.

How could I enhance the Animation Nation contributor experience
based on my experience as a maintainer?

Through years of reviewing PRs, I noticed repetitive tasks and patterns:

Maintainers often have to:
- manually provide the same feedback across PRs
- manually add labels for communication \ (including hacktoberfest-accepted)
I also observed:
- contributors sometimes don’t revisit their PRs (even when pinged)
- asynchronous feedback can cause disengagement, especially for new contributors

These insights naturally led me to automate
the review process — what I call pre-review.

Benefits:

reduces maintainer workload by automating labelling & detection of PR readiness
improves contributor experience with faster feedback and more autonomy

So, I created a pre-review bot using GitHub Actions, shell scripting, and JavaScript to automate a review for a PR:

➡️ Pre-Review PR ⬅️

The other accepted PRs were improvements built on top of this work

🔸 Automation / Bot - Key Points

You may wonder:

What’s the difference between automation and a bot?
How do you even know what to automate?

Automation starts when you notice repetition / patterns. (so does the refactoring process)

Automation is simply a process that runs automatically when something happens.
In this case, GitHub Actions trigger when a pull_request event occurs and run a series of steps - commonly called a workflow.

📌 A good trigger + a set of steps = automation.

So how do you come up with something to automate?
You watch for patterns - in this case:

repeated feedback comments
repeated clicks or actions
the same mistakes happening across PRs
maintainers doing the same manual checks every time

📌 Repetition is the signal.

Once you know the repeated tasks, you can turn them into steps — like a recipe — and code handles the logic.

📌 This is where you start thinking programmatically: using conditions and logic to automate decisions.

And where does a bot fit in?
A bot is simply code acting on your behalf!
It listens for an event and performs the actions you defined — without you being there.

In this case, the bot reviews the PR, posts comments, applies labels, and helps move the process forward automatically — just like an assistant we delegate repetitive tasks so maintainers can focus on real review work.

✨ Pre-review Automation — How this Works ✨

First, I created a JavaScript script that:

triggers on Pull Request events
ensures contributions follow the README.md structure (GitHub handle folder + index.html, styles.css, meta.json)
checks edge cases and invalid submissions (no JS, inline styles, non-interactive animations, etc.)

Then I orchestrated the flow using GitHub Actions, and added new repo labels including:

Awaiting Maintainer Validation — pre-review passed, no issues detected, awaiting manual approval before merging

Workflow steps:

trigger on Pull Requests
collect PR data (contributor handle, PR diff, maintainer status, etc.)
execute the script to run checks and output personalised feedback
automatically apply labels using Bash + conditionally assign hacktoberfest-accepted based on date

🔸 What I Learned This Year

This year, I focused on identifying real pain points and building solutions that create meaningful impact.

Technically, I deepened my understanding of GitHub tokens:

PAT token → needed to interact with forks & assign contributors (useful for full automation when permissions allow)
GitHub token → enough for labeling, commits, gh CLI interactions, diff checks

This clarified when each token is appropriate depending on repo permissions and contributor roles.

Definitely one of those “good to know” maintainer lessons!

Beyond the technical part, it was about supporting others and enjoying the satisfaction of seeing things run smoothly and genuinely help contributors.

If you have any questions - Please feel free to ask bellow

🙌 See you to the next hactoberfest!🙌