Where does CONTRIBUTING.md go?

The repository root, `.github/` or `docs/`. GitHub finds it in any of the three and links it automatically from the new-issue and new-pull-request pages, and shows a banner to first-time contributors.

What should it actually say?

The things a newcomer cannot work out from the code: how to get it running, whether to open an issue before a large change, what you will and will not accept, and how long a review takes. Everything else is optional.

How is it different from a README?

The README is for people using the project; CONTRIBUTING is for people changing it. Setup instructions appear in both because the audiences overlap, but the README stops at "how do I run this" and CONTRIBUTING carries on into "and what happens when I send a patch".

Should I say how long reviews take?

Yes, and it is the most useful sentence in the file. An unanswered pull request is the commonest reason a first-time contributor never returns. Naming a window — even a slow one — turns silence into something expected rather than a rejection.

CONTRIBUTING.md template for a repository

Fill it in and copy it Open in the editor Opens as CONTRIBUTING.md, ready to edit. Nothing is uploaded.

The shape of it — edit here, or open the full template

Markdown

Result

Runs entirely in this tab. Open the full editor to work on a real document.

Fill it in and take it

The whole file is below. Type into the boxes to replace the placeholders, then copy it or save it — nothing here is sent anywhere, and there is nothing to sign up for.

# Contributing

<!--
  CONTRIBUTING.md is linked automatically by GitHub from the new-issue and
  new-pull-request pages. Its job is to answer the questions a first-time
  contributor would otherwise have to ask: how do I run this, what will you
  accept, and how long will you take.
-->

Thanks for considering it. This file covers how to get the project running and
what happens to a pull request once you open one.

## Getting set up

```sh
git clone https://github.com/you/project.git
cd project-name
npm install
npm test
```

If `npm test` does not pass on a clean checkout, that is a bug — please open an
issue rather than working around it.

## Before you start something large

Open an issue first. A short conversation about the approach saves a large pull
request being turned down for a reason that had nothing to do with the code.

Small fixes — a typo, a broken link, an obvious bug — need no discussion. Send
them straight in.

## Making a change

1. Branch from `main`
2. Make the change, with tests
3. Run `npm test` and `npm run lint`
4. Write a commit message that says what changed and why

<!-- If you use conventional commits, semantic versioning or a changelog file,
     say so here — it is the single most common reason a first pull request
     needs a second round. -->

## Opening the pull request

Fill in the template. The section reviewers read first is *how to test it*, so
say what they should observe rather than just which command to run.

Expect a first response within a week. If it has been longer, a comment on the
pull request is welcome and not rude.

## What gets accepted

- Bug fixes, with a test that fails without the fix
- Documentation, including small corrections
- Features that were discussed in an issue first

## What usually does not

- Reformatting unrelated files, which makes the real change unreviewable
- New dependencies, unless the alternative is genuinely worse
- Changes to the public API without a deprecation path

## Reporting a bug

Include the version, what you expected, what happened instead, and the smallest
example that reproduces it. A reproduction is worth more than a description.

Security issues go to **security@example.com** rather than to the issue
tracker.

## Code of conduct

Taking part means following the [Code of Conduct](CODE_OF_CONDUCT.md).

CONTRIBUTING.md is the file GitHub links from the new-issue and new-pull-request pages, and shows as a banner to anyone opening their first pull request. It goes in the repository root, .github/ or docs/.

Its job is narrow: answer the questions a first-time contributor would otherwise have to ask in public.

The four that matter

How do I run this? Clone, install, test — the exact commands, on a clean checkout. If the test suite does not pass from a fresh clone, say so, because otherwise the contributor assumes they broke it.

Should I ask first? Say where the line is. Typos and obvious bugs go straight in; anything large gets an issue first. Without that sentence, someone spends a weekend on a pull request you were always going to turn down.

What do you accept? Two short lists — what usually goes in, what usually does not. Reformatting unrelated files and new dependencies are the two worth naming explicitly, because both feel helpful and neither is.

How long will this take? The most useful sentence in the file. An unanswered pull request is the commonest reason a first-time contributor never comes back. Naming a window, even a slow one, turns silence into something expected.

Keep the process rules where they are checked

Conventional commits, changelog entries, sign-offs — anything a reviewer will send a change back over belongs in this file rather than in a maintainer’s head. Better still, in a lint rule, with this file explaining it.

Two files, not one

CONTRIBUTING is about the work; a code of conduct is about behaviour. Link each from the other and let them stay short. Security reporting is a third thing again — give it an email address here, and a SECURITY.md if the project is large enough to need one.

Common questions

Where does CONTRIBUTING.md go?: The repository root, `.github/` or `docs/`. GitHub finds it in any of the three and links it automatically from the new-issue and new-pull-request pages, and shows a banner to first-time contributors.
What should it actually say?: The things a newcomer cannot work out from the code: how to get it running, whether to open an issue before a large change, what you will and will not accept, and how long a review takes. Everything else is optional.
How is it different from a README?: The README is for people using the project; CONTRIBUTING is for people changing it. Setup instructions appear in both because the audiences overlap, but the README stops at "how do I run this" and CONTRIBUTING carries on into "and what happens when I send a patch".
Should I say how long reviews take?: Yes, and it is the most useful sentence in the file. An unanswered pull request is the commonest reason a first-time contributor never returns. Naming a window — even a slow one — turns silence into something expected rather than a rejection.
Do I need a code of conduct too?: They are separate files with separate jobs: CONTRIBUTING is about the work, a code of conduct is about behaviour. Link one from the other. GitHub surfaces both in the same places.