Automating GitHub Docs maintenance
The GitHub Docs team maintains everything on docs.github.com. Our content and tooling live in the open source docs repo, where we run a growing suite of GitHub Actions workflows to handle repetitive project management tasks. The workflows we rely on daily are all publicly visible, and while new to Actions? Start with the GitHub Actions documentation.
Why project management belongs in Actions
The GitHub Docs team documents every aspect of GitHub and manages a steady stream of community contributions, which adds up to a lot of issues and pull requests to track. Any hour spent juggling project boards is an hour not spent on content improvements. Since our work lives in GitHub issues and project boards, we can reach it through GitHub's REST and GraphQL APIs — and Actions gives us a streamlined wrapper for driving that automation.
Before Actions, automating this kind of work meant writing a script from scratch, wiring up an Octokit library, or standing up a Probot app. Actions replaces all that glue with a YAML workflow file. We can invoke the full API surface through github-script and the GitHub CLI, pull an action from the Marketplace, or build our own action.
The practical win is turnaround time: a workflow file takes a fraction of the effort of a standalone script or app. Because the workflows are YAML, every team member — engineers and non-engineers alike — can read and contribute to them.
Workflows we can't live without
Our Actions usage spans CI/CD, automated API docs generation, and link checking, but the project management workflows below do the heaviest lifting in our open source repo.
Triage, spam, and stale issues
When a contributor opens an issue, the Triage new issues workflow slaps a triage label on it and moves it to the "Triage" column of our project board, so maintainers always know where fresh community input lands.
Large open source projects attract spam, and ours is no exception. The Check for Spammy Issues workflow closes issues with too few words — a reasonable spam heuristic for our repo. When an issue is otherwise thin on detail, we ask for more info; if the author never replies, the No response workflow closes it with a friendly note, keeping maintainer attention on actionable work.
Routing API-related issues
Sections like the REST API reference are generated by internal tooling and can't be edited directly in pull requests from outside contributors. The Transfer REST API issue to rest-api-description workflow moves such issues into the open source OpenAPI repo. A companion workflow, Copy to REST API issue to docs-content, duplicates internal issues to a private repo while keeping the original public issue visible to the community.
Guiding pull requests to merge
Community contributors searching for work often watch for the help wanted label. When a maintainer adds that label, Move help wanted issues automatically places the issue on a board where contributors can find it.
On the pull request side, the Check unallowed file changes workflow greets incoming PRs with a validation pass against files that shouldn't be modified from outside. For everything else, Triage new pull requests labels and boards the PR with a triage label, just like issues.
Once maintainers approve, Move and unlabel ready to merge PRs lines it up for a team member to merge. A post-merge Merge notification workflow tells the contributor when their changes will go live on docs.github.com.
Contributors sometimes step away from work-in-progress, for any number of reasons. The Public Repo Stale Check workflow comments with a gentle nudge and, if activity still doesn't pick up, closes the PR. Returning authors can always reopen a closed PR, and our Actions-based triage picks it up from there.
Try them yourself
The workflows above are a sample of how we keep our documentation repo moving without losing time to manual board management. Our full workflow directory is open for browsing. If you spot an improvement, file a discussion — or send a pull request, and our Actions will take it from there.
