Repo Ops: The .github Directory for Org-Wide Settings
The .github directory is repo policy as code — issue forms, workflows, owners files, and community defaults — and org-level repos inherit it everywhere.
Netbay Developer Relations
Netbay Engineering
On this page
The most underrated folder in any repository is the one that starts with a dot. The .github directory is where your repository's policy lives as files: the forms that shape how issues and pull requests get opened, the workflows that enforce checks, the ownership map, the dependency configuration. Nothing here is atmosphere — GitHub reads these exact files and behaves differently because of them. And one level up, an organization-level .github repository sets the defaults for every repository that does not define its own.
What belongs in .github
A sane small install looks like this:
find .github -maxdepth 2 -type f | sort
# .github/CODEOWNERS
# .github/dependabot.yml
# .github/ISSUE_TEMPLATE/bug.yml
# .github/ISSUE_TEMPLATE/config.yml
# .github/PULL_REQUEST_TEMPLATE.md
# .github/CONTRIBUTING.md
# .github/workflows/ci.yml
# .github/workflows/triage.ymlEach file is a lever pulled from git instead of from a settings page:
- Codeowners files map paths to reviewers (see the monorepo post for the deep dive).
- Dependabot config schedules dependency updates for every manifest.
- Issue and pull request templates shape how contributors file things.
- Community files — contributing guide, code of conduct, funding metadata — are read by GitHub when people interact with the repo.
- The workflows directory carries every automation this series has been assembling.
Templates: the front door
The issue template directory is where effort should concentrate first. Form schemas, structured as YAML with required fields and dropdowns, mean every bug report arrives with a reproduction attempt and a version; blank issues can be disabled wholesale. A pull request template that asks for the ticket number, the change summary, and the test plan does for reviews what the issue form does for bugs. Both are configuration, both get reviewed in the same PR that introduces the feature they describe.
The org default repository
GitHub has a second, quieter convention: an organization-owned repository literally named .github. Files placed there become the defaults for every repository in the organization that lacks its own copy. A default contributing guide, code of conduct, and workflow surface across a fleet of repositories — especially young ones — without anyone copying files around. The precedence rule is the whole safety net: repository-local files always win over the org default, so a team can intentionally differ while the default covers everything that does not try.
The pattern is worth using even for a small organization: put the community files and default workflows in the org-level .github repository, let new projects inherit good manners, and keep per-repo overrides explicit and visible. For a team of one the defaults still pay off: the next repository you open starts above zero instead of from a blank folder, and the convention is already in place before the first contributor arrives.
Conventions that compound
A few habits keep .github from becoming a dumpster:
- Name workflow files by purpose, not by date; the file list is your audit trail.
- Keep templates short — every extra prompt is a tax on reporters.
- Treat the directory as code: it is reviewed, versioned, and tested like the application it describes. A folder that outgrows what one config file should do is telling you something — split it into a small workflow per concern, and let the org default carry the boring five percent that every repo shares anyway.
- Reuse via references instead of copy-paste. Of course, the directory you scaffold is itself a scaffold you can script:
# bootstrap a minimal .github for a new repository
mkdir -p .github/ISSUE_TEMPLATE .github/workflows
cp templates/bug.yml .github/ISSUE_TEMPLATE/bug.yml
cp templates/CODEOWNERS .github/CODEOWNERS
printf 'version: 2
updates: []
' > .github/dependabot.yml
git add .github && git commit -m "chore: add repo conventions"Where this actually pays
The return on a tidy .github directory is compounding: onboarding copies pasted from READMEs disappear, bug reports arrive shaped, every repository has an owner in the file instead of an expectation in someone's head. The org-level default then propagates all of that for free. It is the rare infrastructure change whose cost is a handful of files and whose dividend is every future contributor.
Takeaway: make repo policy a directory, let org defaults cover the silence, and keep the folder small and reviewed. The automation you drop in .github — the schema checks, the triage loops, the mirrors — runs happily in a Lucknow DC01 VPS from Netbay, deployable in under 60 seconds at netbayhosts.in.
Keep reading
Follow along on a real VPS
Deploy Linux in under 60 seconds
These guides are written against Ubuntu, Debian, and RHEL-family images — the same ones on NetBay.
Deploy an instance