My open source project is brand new and already has contributors. Here's what I did.

Description and use

A brand‑new open‑source project attracted contributors by labeling issues by skill, using spec‑style issue templates, simplifying setup, reviewing PRs quickly, and publicly thanking contributors.

Problem

A brand‑new open‑source project struggled to attract contributors and make the codebase approachable for newcomers.

Outcome

The project saw an increase in contributors and pull requests after implementing skill‑based issue labeling, spec‑style issue templates, clearer setup instructions, fast reviews, and public thanks.

Workflow

• Label issues by skill and type
• Write issue templates as specs with problem, scope, out‑of‑scope, acceptance criteria
• Simplify README and create a single .env setup step
• Ensure setup steps work on a fresh database
• Review PRs quickly and merge
• Publicly thank contributors

Evidence

I added two labels: frontend and backend. Right now I have 58 open issues, 41 tagged frontend and 33 tagged backend.

Source

The issue my first contributor picked up was tagged frontend, good first issue, and help wanted. It was also written so that someone who had never seen the codebase could start.

Source

I rewrote the README to be a short overview, and added a CONTRIBUTING guide plus issue forms for bugs, features, integrations, and docs, so new reports come in with the details I need.

Source

The PRs came with a clear description of what changed, why, and how to try it. That made them easy to review, and I could merge quickly.

Source