How to set up a new open source repository correctly

Start Right or Refactor Later

A repository set up correctly from the start attracts serious contributors. One missing file signals carelessness. Here is the setup every maintainable project needs.

Essential Files

LICENSE -- Without this, default copyright applies. Choose MIT for maximum adoption, Apache 2.0 for patent protection, GPL if you need copyleft. GitHub lets you choose during repo creation.

.gitignore -- Use github.com/github/gitignore for language-specific templates. Never commit node_modules, .env, or build artifacts.

README.md -- Cover: what the project does, how to install it, a quick usage example, and how to contribute. Short is fine. Missing is not.

GitHub Repository Settings

# Branch protection rules (Settings then Branches)
# Require PR before merging to main
# Require status checks (CI) to pass
# Require at least 1 approval
# Dismiss stale approvals on new commits
# Restrict force pushes to main

Issue and PR Templates

Create .github/ISSUE_TEMPLATE/bug_report.md and .github/ISSUE_TEMPLATE/feature_request.md. These prompt contributors to provide structured information. A .github/pull_request_template.md auto-fills the PR description box with your checklist.

Automating Project Health

GitHub Actions can enforce contribution standards automatically. Add a workflow that runs on every PR to check: whether the PR description contains required sections (What, Why, Testing), whether the branch name follows your naming convention, and whether the PR is linked to an open issue. Tools like danger/danger-js make this straightforward -- define rules in a Dangerfile and they run as a CI check. Automated checks catch process violations early and reduce the manual review burden on maintainers, which is especially valuable as your project grows beyond a handful of contributors.