The Problem With Community Contributions

Static Site Generators (SSGs) have become a staple of the Jamstack ecosystem, and it’s common for their content to live directly in a GitHub repository. That architecture opens up an elegant contribution model: community members fork the repo, add their content, and open a pull request. Projects like CSS-Tricks’ Serverless Site and Coding Fonts Site, the Jamstack Site Generator Site, and Free Developer Stuff all rely on this pattern.

The approach has clear advantages. SSGs are cheap to deploy, often free for a proof of concept, and highly secure since they serve only static files with no server-side attack surface. Scaling is handled by the host you’re already using. But perhaps the biggest benefit is that content itself lives in the repo, which means any change is a pull request.

The downside is the barrier to entry. Contributors who want to help need to understand forking, branching, file structure, Markdown formatting, and required fields. They may even need to run the site locally to verify their submission looks correct. That technical learning curve filters out people who genuinely want to contribute but aren’t familiar with Git workflows.

What if the entire process were reduced to filling out an HTML form?

The GitHub Query Parameter Trick

GitHub has a documented feature: you can pre-fill a pull request against any repository by appending query parameters to a special URL. This comes straight from GitHub’s official documentation.

The workflow is straightforward. Instead of posting form data to a database, you construct a URL that points to GitHub’s new pull request page, with the user’s content encoded as query parameters. A small piece of JavaScript grabs the form input, builds a readable string, encodes it, and appends it to that URL. When the user submits the form, they’re taken straight to GitHub with the pull request already drafted.

The Serverless Site Demo

Let’s see how this works in practice using CSS-Tricks’ Serverless site as an example. Currently, contributing to the Resources category means forking the repo and adding a new Markdown file. All the resource files live in this folder, and examining a sample file shows the required structure:

The front matter fields are Title, URL, Author, Tags, and a text snippet describing the link. These map directly to form fields. With Bulma for styling, the form looks like this:

<div class="columns container my-2">
  <div class="column is-half is-offset-one-quarter">
  <h1 class="title">Contribute to Serverless Resources</h1>

  <div class="field">
    <label class="label" for="title">Title</label>
    <div class="control">
      <input id="title" name="title" class="input" type="text">
    </div>
  </div>
  
  <div class="field">
    <label class="label" for="url">URL</label>
    <div class="control">
      <input id="url" name="url" class="input" type="url">
    </div>
  </div>
    
  <div class="field">
    <label class="label" for="author">Author</label>
    <div class="control">
      <input id="author" class="input" type="text" name="author">
    </div>
  </div>
  
  <div class="field">
    <label class="label" for="tags">Tags (comma separated)</label>
    <div class="control">
      <input id="tags" class="input" type="text" name="tags">
    </div>
  </div>
    
  <div class="field">
    <label class="label" for="description">Description</label>
    <div class="control">
      <textarea id="description" class="textarea" name="description"></textarea>
    </div>
  </div>
  
   <!-- Prepare the JavaScript function for later -->
  <div class="control">
    <button onclick="validateSubmission();" class="button is-link is-fullwidth">Submit</button>
  </div>
    
  </div>
</div>

The accompanying JavaScript function handles the rest:

  • Collect the user’s input for each field
  • Assemble everything into a single content string
  • Encode that string in a human-readable format
  • Append the encoded data to the GitHub new pull request URL
GitHub pull request screen showing a new file with content.

After submit, the user lands on GitHub with a fully prepared pull request in the correct file location. One caveat remains: contributors still need a GitHub account. But that’s far less intimidating than teaching them how to fork and manage a pull request from their own clone.

Better Form UX and Beyond

Because this form lives on your own site, you have complete styling control. You can design it to match your brand and integrate it naturally with the rest of your pages. The JavaScript that builds the URL can also be extended to interact with other services before generating the link.

The demo includes a further refinement: asking users for nothing more than a URL and their tags. A fetch to a metadata API handles everything else. For instance, hitting https://metadata-api.vercel.app/api?url=https://css-tricks.com returns the page’s title and meta description, which populate the form fields automatically. Instead of requiring four inputs, the user only provides two.

Using It for Your Own Static Site

You can think of this as a minimal CMS tailored to any SSG with content in a Git repository. The same pattern works regardless of your generator, your content structure, or the type of submission, since it’s ultimately just constructing a custom Git pull request URL with pre-filled data. Customize the form to match your field requirements, update the query parameters, and deploy. That’s all it takes to transform what could be a frustrating contributor experience into a simple submission.