Account-wide defaults for contribution, governance, security, and support.
Write it once. Inherit it everywhere.
GitHub gives a repository named .github a special job: any file it holds from a fixed,
documented list is served as the default for every other repository on this account that does
not ship its own copy.
Nothing here is application code, and nothing here builds. Apart from this README and the
LICENSE, every file in this repository exists to be served to other repositories, so a new
repository starts with a real code of conduct, a real security policy, and working issue forms on
day one, without copying a single file.
Important
A repository's own file always wins. These are fallbacks, not mandates. Drop a
CONTRIBUTING.md into any repository and it immediately overrides the one here, for that
repository only.
| File | What it does |
|---|---|
CODE_OF_CONDUCT.md |
Behavioral standards and the enforcement ladder |
CONTRIBUTING.md |
Branching, commits, tests, coding style, and the pull request process |
GOVERNANCE.md |
Who decides what, and how access survives any one person leaving |
SECURITY.md |
How to report a vulnerability privately, and what to expect back |
SUPPORT.md |
Which channel answers which kind of question |
.github/FUNDING.yml |
The Sponsor button |
.github/pull_request_template.md |
Prefills every new pull request description |
.github/ISSUE_TEMPLATE/ |
Structured issue forms, plus the chooser config (config.yml) |
.github/DISCUSSION_TEMPLATE/ |
Category forms for Discussions |
That is the complete supported set: GitHub serves these file types as defaults and no others.
Apart from this README and the LICENSE, the repository holds nothing else on purpose.
Three rules govern everything here:
- This repository must stay public. Defaults are not served from a private
.githubrepository, not even to private repositories. - Files must live on the default branch. A file on a feature branch is inert.
- Local beats default. For the Markdown documents this is decided file by file: a repository
can ship its own
SECURITY.mdand still inherit everything else. The forms are decided per directory: a repository that ships a single issue form of its own stops inheriting the whole set, not just the form it replaced.
Issue and discussion forms are path-locked and only work from .github/ISSUE_TEMPLATE/ and
.github/DISCUSSION_TEMPLATE/. The five Markdown documents may sit at the repository root, in
.github/, or in docs/; they are kept at the root here for readability.
GitHub serves only the documents listed above as defaults. Two files here are not among them:
LICENSE, explicitly unsupported as a default; every repository needs its ownREADME.md, including this one
Both stay because they govern and explain the rest, not because they travel. Everything else in the repository inherits, which is the whole reason it is here.
The forms here apply the shared taxonomy from
tannergolden/standards: prefixed names such as
type: bug and status: needs triage, which sort predictably and keep what a thing is separate
from the stage it is at. All sixteen forms declare a type: and status: needs triage at creation,
and the two whose subject already implies an area declare that too: area: ui/ux for the
Accessibility Report, area: dx for the tooling and setup category. The area: names offered as
checkboxes in the other forms come from the same vocabulary but are read by a human at triage rather
than applied automatically.
That taxonomy is not part of a repository's stock label set. A repository provisions it by
running 🎯 Apply Standards once, which syncs data/labels.yml over the API, create-or-update
and never pruning, so labels added by hand survive. Until that runs, a form naming a label the
repository does not have still files the issue normally; it simply arrives without that label and
gets triaged by hand.
The stock labels a new repository is born with keep working alongside the taxonomy, and two of them
carry platform behavior worth keeping: good first issue feeds GitHub's contributor discovery and
the repository's /contribute page, and help wanted feeds community-discovery search.
Changes here reach every repository on the account the moment they merge, so treat them as production documents:
- Keep the language project-agnostic. These render inside repositories with different stacks, audiences, and maturity levels.
- Use absolute links. A relative link resolves against the consuming repository, where the target usually does not exist.
- Promise nothing a repository might not have. Hedge references to Makefiles, CI gates, and Discussions categories; a default renders everywhere, including where those are absent.
- Prefer additive edits. Tightening a rule here tightens it everywhere at once.
Inherit the defaults and write nothing; that is the intended path. Override only when a repository genuinely differs: a different disclosure process, a different contribution workflow, a different support channel. When you do override, copy the file into that repository and edit it there.
Sensible defaults, everywhere, by default.
Built with ❤️ by @tannergolden. Distributed under the MIT License.