Up For Grabs: a curated index of open source tasks for new contributors

What Up For Grabs solves, and who it is actually for

The problem is not that open source lacks beginner-friendly work. It is that the label good-first-issue is applied inconsistently, and a newcomer has no way to tell whether a maintainer will answer a question or let a pull request sit for a month. Up For Grabs takes a different position: it is a list of projects that have, in the project's own words, "curated tasks specifically for new contributors". The curation is the product. A project appears because someone opened a pull request to add it, not because a crawler found a label.

The audience is therefore narrow and specific. On one side, maintainers who are willing to answer a first-time contributor's questions and who have issues they consider appropriate entry points. On the other, people who have never sent a patch to a stranger's repository and want the social contract to be clear before they start. If you already know which projects you want to work on, this site adds nothing you cannot get from GitHub's own label filters. It is a discovery tool for the undecided, not a workflow tool for the committed.

How the site is built: Jekyll, Astro, and a repository in transition

The repository layout shows two build systems living side by side. The older path is Jekyll: _config.yml, _data/, _includes/, _layouts/, a Gemfile and Gemfile.lock, and a Dockerfile that ends with `bundle exec jekyll serve`. The newer path is Astro: astro.config.mjs, src/, tsconfig.json, vitest.config.ts, eslint-new.config.mjs, and package.json scripts named dev, build and preview that all call astro. The npm scripts also keep the old lint and test targets for javascripts/*.js and tests/**/*.js.

The Dockerfile pins the older path to Ruby 4.0-slim-trixie, installs bundler 4.0.3, exposes port 4000 and runs Jekyll with --watch and --force_polling bound to 0.0.0.0. The Node side declares `"node": ">=24"` and `"npm": ">=11"` under engines. Two toolchains, two entry points, one website. The README points readers at docs/how-it-works.md for the architecture rather than describing it inline, which is a reasonable choice for a repository whose main content is data files.

The practical consequence is that instructions written for one build path will not work on the other. A contributor who runs the Astro dev server will not reproduce a Jekyll layout bug, and vice versa. The repository itself acknowledges the split through file naming: eslint.config.mjs for the legacy JavaScript and eslint-new.config.mjs for src/**/*.astro, src/**/*.vue, *.mjs and src/**/*.ts.

Running the site locally with Docker on port 4000

The repository ships a docker-compose.yml that builds the image, maps port 4000, and bind-mounts the working directory into /app so edits on the host appear inside the container. The compose file is short enough to quote in full:

version: "3"
services:
  app:
    build: .
    ports:
      - "4000:4000"
    volumes:
      - ".:/app"

Start it with the standard compose command, then open http://localhost:4000. The container's CMD runs `bundle install` and then Jekyll with `--watch --force_polling`, which is why the bind mount matters: --force_polling exists precisely so file changes made on the host are picked up inside the container.

docker compose up

The first run installs the Ruby gems, so expect a pause before the server answers. If you prefer the Node toolchain, package.json defines `dev`, `build` and `preview` as Astro commands, and the engines field requires Node 24 or newer with npm 11 or newer. The README does not document a rollback or teardown step for either path, and it does not state which path the deployed site currently uses.

Listing a project is a pull request, not a form submission

The README's only instruction for adding content is to follow docs/list-a-project.md and open a pull request. That means the directory's contents are reviewed by humans before they appear, and that a listing can be rejected or edited. It also means the site cannot scale by crawling. Every entry costs someone a review.

This is the design decision that most shapes what Up For Grabs is. A label-based aggregator can index thousands of repositories overnight and will include projects that never respond to newcomers. Up For Grabs trades coverage for a weaker but more useful promise: someone looked at this project and decided it belongs here. The cost is staleness. Nothing in the repository's documentation describes an automated check that a listed project still has open beginner tasks, and the repository is content plus a static site generator, so the freshness of any individual entry depends on maintainers and contributors updating it. Treat a listing as a pointer to a project, not as a guarantee about any specific issue.

Where Up For Grabs is the wrong tool

If you want a machine-readable feed of open beginner issues across GitHub, this is not it. There is no documented API, no CLI, and no published data endpoint in the README; the deliverable is a website backed by data files in the repository. You would be reading a rendered page or cloning the repository to parse _data/ yourself, and the schema for those files is not reproduced in the README.

The second limitation is scope. Up For Grabs lists projects, not tasks. It will tell you that a project welcomes new contributors; it will not tell you which issue is unclaimed right now, who is mentoring it, or whether the person who filed it is still active. You still have to open the project and check. Anyone who expects the directory to remove that step will be disappointed, and anyone maintaining a project that wants a continuously updated board of its own issues should look at the issue tracker itself rather than at this index.

The third is the split toolchain. A contributor who wants to change the site's rendering has to determine whether the page they care about is generated by Jekyll or by Astro before writing any code. The README does not resolve that question; it delegates to docs/how-it-works.md.

Compared with filtering GitHub by label

The obvious alternative is GitHub's own search for the good-first-issue label, which Up For Grabs itself lists as a topic. The difference is in who does the filtering. GitHub search matches a string on an issue; it returns every repository that has ever applied the label, including abandoned ones and projects where the label is a triage marker rather than an invitation. Up For Grabs matches on a maintainer's decision to be listed, which is a much smaller set and a different kind of signal.

That trade runs in both directions. GitHub search is current by construction: it reflects the issue tracker as it is today. Up For Grabs is current only as often as someone updates the repository. If your goal is to find the largest possible pool of candidate issues, GitHub search wins on volume and freshness. If your goal is to avoid wasting a weekend on a project that will not answer you, the curated list is the better starting point, provided you still verify the individual issue before you start work.

Maintenance, licensing and what the repository does not settle

The last push to the repository was on 2026-09-21, and the repository is not archived, so the project is being touched. That says nothing about how quickly a listing request or a pull request will be reviewed, and the README does not publish a review cadence.

Licensing is genuinely ambiguous. The package.json declares `"license": "MIT"` for the tooling, while the repository's license metadata is reported as NOASSERTION, and the top-level entries include both a LICENSE file and a licenses/ directory. If you intend to reuse the site's content, templates or data files rather than just read the website, read the LICENSE file and the licenses/ directory directly instead of trusting the package.json field, which describes the npm package and not necessarily the site content. Nothing here is legal advice.

The upgrade cost is the unfinished migration. Until the Jekyll and Astro paths are consolidated, contributors pay a small tax on every change: two lint configurations, two test setups, two ways to run the site. The npm scripts give the current commands, and the Dockerfile gives the older one. Check both before assuming a single workflow.

Editorial conclusion

Up For Grabs suits two groups: maintainers who have labelled issues they are willing to mentor a stranger through, and newcomers who want a directory that filters for that intent rather than a raw label search. It does not suit anyone looking for a package, an API or an automated issue feed, because the repository is the website itself and listing is a pull request against docs/list-a-project.md. Before you spend time on it, read CONTRIBUTING.md, check which of the two build paths still applies to the part you want to change, and confirm the issue you plan to work on is still open in the project that owns it, since the site only records the link.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. up-for-grabs/up-for-grabs.net on GitHub