Open-Source Project on GitHub

You published a small utility library to a public repo, wrote a decent README, and forgot about it. Eight months later it has 4,000 stars, a dependency footprint you can no longer see the edges of, and an issue tracker that fills faster than you can read it. Strangers open PRs from forks, file bugs without a version number, and ask in the issues why their unrelated framework is broken. The code is the same size it always was; the project around it has become a second job.

The scenario forces a set of decisions that have nothing to do with writing code: how untrusted contributions run in CI, how to keep the issue tracker legible, how to cut releases that downstream consumers can trust, and how to do all of it without burning out. Each decision has a wrong default that looks convenient and turns out to be a liability — the sharpest one being a CI trigger that can hand a stranger your secrets.

Triage Before Code

The first thing that breaks at scale is the inbox. A 600-item tracker where every report says "doesn't work" is indistinguishable from no tracker at all. Issue forms (.github/ISSUE_TEMPLATE/*.yml) fix this at the source by making version, environment, and a reproduction required fields — a report that cannot be filed without a repro is a report you can act on. Labels turn the remaining pile into a queue: bug, needs-repro, and good first issue let you and contributors sort by what is actionable rather than reading top to bottom.

The triage decision that pays off later is keeping a handful of good first issue tickets open at all times. They are the only realistic on-ramp for new contributors, and a project with none of them quietly concentrates all work on the maintainer.

The Permission Model for Fork PRs

A pull request from a fork runs in a fundamentally different trust context than one from a branch on your repo. By design, a pull_request workflow triggered by a fork gets a read-only GITHUB_TOKEN and no access to your repository secrets. That is not a limitation to work around — it is the security boundary that lets you run a stranger's code at all. The contributor's tests run, the build runs, but nothing the workflow does can push to your repo or read a deploy key.

A typical PR-gate workflow stays inside that boundary deliberately:

name: CI
on: pull_request
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

The pull_request_target Trap

GitHub offers a second trigger, pull_request_target, that runs in the context of the base repository — with a read-write token and access to secrets. It exists for legitimate jobs like labeling a PR or posting a welcome comment, where you need write access but never touch the contributor's code. The danger is checking out the PR's head under it:

# DANGER: do not do this
on: pull_request_target
jobs:
  build:
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}  # attacker code
      - run: npm ci && npm run build   # runs with your secrets

That combination runs arbitrary attacker-supplied code with a write token and your secrets in scope — a documented, repeatedly-exploited path to exfiltrating credentials and pushing to the base repo. For anything that builds or executes contributor code, the answer is plain pull_request, and any job that genuinely needs a secret goes behind an environment approval gate so a human signs off before the secret is exposed.

Releases and Downstream Trust

Once people depend on the library, releases become a contract. Tag-driven releases — push v2.3.0, an Action builds the artifact, creates a GitHub Release with generated notes, and attaches the build output — give downstream consumers a stable, signed point to pin to. The version number itself is a signal: SemVer tells a consumer whether an upgrade is safe to take automatically, and breaking that promise once teaches everyone to pin exact versions, which defeats the point.

Community Infrastructure

Three files carry most of the weight. CONTRIBUTING.md sets expectations so PRs arrive shaped correctly; CODE_OF_CONDUCT.md gives you grounds to moderate; and SECURITY.md is the one that prevents real damage — it points vulnerability reporters at a private channel (GitHub Security Advisories or an email) instead of a public issue. Without it, the default behavior of a well-meaning reporter is to disclose the exploit publicly before a patch exists. Routing questions to Discussions rather than Issues keeps the actionable queue clean.

Maintainer Load

The project outlives your enthusiasm only if the load is bounded. A documented scope ("we do not accept X") lets you close out-of-scope requests without a debate each time. A stale-issue bot auto-closes abandoned reports so the tracker reflects reality. And declining to promise a response SLA you cannot hold is not rudeness — it is the difference between a sustainable project and an abandoned one.