As an open-source project maintainer, Hacktoberfest (held by DigitalOcean every year) can be both a blessing and a curse.

It’s a phenomenal way for an open-source project to get new contributors and accomplish tasks quickly, but it can also create a huge amount of pull requests of varying quality. Then to make matters worse these need to be reviewed before the end-of-the-month deadline! We all appreciate the time folks give to these projects even if it is just to get a t-shirt, but the review process is literally a pandora’s box. Each PR might be a great quality change that is delightfully innovative or just a white space formatting change that doesn’t follow the guidelines for the project.

Hacktoberfest creates a lot of work. Thanks to some changes by DigitalOcean, each submission needs to be tagged Hacktoberfest. Also, you need to add Hacktoberfest to your project’s topic to opt into the event. Labels help with sorting contributions, but what if you could separate the spammy t-shirt attempts from the quality addition’s automatically?

How Can You Separate the Good from the Spammy Hacktoberfest PRs?

There is a free tool that can help you with your projects that are hosted on GitHub.
/:\ gitStream by LinearB is a new way to manage your PR workflow by categorizing and sorting PRs as they are submitted. 

This is called continuous merge or CM, like continuous integration(CI) and continuous delivery(CD). It creates a set of automated processes that can help you evaluate the good PRs quicker and keep the spam out.

How Do You Install gitStream?

First, we need to install gitStream on the repo from the Github marketplace – go to https://github.com/marketplace/gitstream-by-linearb to install. Here’s a quick video on the whole process takes just a few minutes:

Next, we need to copy in our .cm file and our GitHub actions file and commit them. To get you started we have built a special Hacktoberfest gitstream.cm file that matches and labels common spam patterns.

# -*- mode: yaml -*-
​
manifest:
 version: 1.0
​
# The `automations` section includes a list of automation that applies
# to the repository in which gitStream is installed. Each automation has an
# `if` key with a list of the necessary assertions, as well as a `run` key with a
# list of all actions. All the listed assertions need to pass in order
# for the following actions to be executed (there is AND relation between conditions).
​
# Each automation under the `automations` section is independent of the others.
# Every time a PR is opened or changed, the automation's conditions are evaluated (the `if`).
# The actions under `run` are executed one by one if all the conditions pass.
​
# Conditions consists of an expression, which are wrapped with double curly braces, and
# includes a context variable like `files` and filter functions like `length`. Filters
# functions are essentially functions that can be applied to context variables. They are
# called with a pipe operator (|) and can take arguments. Read more on https://docs.gitstream.cm
​
automations:
 # This is the name of the review automation. You can use whatever name, a meaningful name
 # will help to identify it in the future. Each automation name in this file should be unique.
 spam_formatting_changes:
   # The `if` key has a list of conditions, each condition is specified as a Jinja expression
   # in a double curly braces. Expressions are evaluated by gitStream on a PR when triggered.
   if:
     # Given the PR code changes, check that only formatting changes were made
     - {{ source.diff.files | isFormattingChange }}
   # `run` key has a list of actions, which are executed one by one whenever the automation
   # conditions are met.
   run:
     # When the changes are validated as formatting only, you can help to speed up the review
     # by adding a label that marks it accordingly.
     - action: add-labels@v1
       args:
         labels: ['SPAM?']
​
 spam_docs_changes:
   if:
     # Given the PR files changes, check that only documents were changed.
     - {{ files | allDocs }}
   run:
     - action: add-labels@v1
       args:
         labels: ['SPAM?']
  spam_images_changes:
   if:
     # Check for every changed file if is a document file. The allImages filter checks for
     # common file extensions used for graphics.
     - {{ files | allImages }}
   run:
     - action: add-labels@v1
       args:
         labels: ['SPAM?']

You can watch this short 43 second video for a quick walk-through of how to setup this custom .cm file:

Out of the box the hacktoberfest gitstream.cm file comes with 3 actions that add “spam?” labels to the PRs, based on formatting changes, only images or a only docs change. Your team might have other ideas what is a spam PR so modify them to make it suitable for your needs – check out the docs to see what your options can be.

Here’s what the spam filter looks like in action:

Now when you are ready to review your Hacktoberfest PRs you can already have a lot categorized as spam that you don’t need to spend as much time on.

Other gitStream Features

Another feature of gitStream is an estimated time to review.

You can add this code to your gitStream.cm file you just created and it can add in the comments how long gitStream guesses that it will take to review, this way you can plan your day better.

automations:
  etr_on_all:
    if:
      - true
    run:
      - action: add-comment@v1
        args:
          comment: "Estimated {{ branch | estimatedReviewTime }} minutes to review"

Do you have a certain part of the code base where you have a specific volunteer reviewing every submission that touches it? Have it auto assigned to them – the code to do that looks like this:

automations:
  ui_review:
    if:
      - {{ files | match(term='src/ui/') }}
    run:
      - action: add-reviewers@v1
        args:
          reviewers: [uireviewer1,uireviewer2]

Add this automation to your gitStream.cm file, change where the path is and who the reviewers are and those PRs are no longer your problem 🙂

There’s lots more that /:\ gitStream can do to help your workflow for your project especially during hacktoberfest, but this is a good start to building your CM pipeline.

Now that you are all set up to clear the spam, add Hacktoberfest to your repo’s topic and publish some issues that you want to get contributions on!