government.github.com: GitHub's open-source Jekyll site for government and civic-tech stories

Stories, not a software registry: what government.github.com collects and for whom

government.github.com gathers stories of public servants, civil servants and civic hackers using GitHub as part of open-government work. Its 4 stated goals are: sharing real-world GitHub experiences in government settings, demystifying open-source terminology for public-sector audiences, featuring the community of organizations on GitHub, and making it easier for government bodies to start using GitHub.

GitHub owns the repository and hosts the site on GitHub Pages at government.github.com. The source code is available, and the project describes itself as a tool for and by the community. Contributing is open to anyone with a GitHub account.

What the site does not collect is code. It does not register open-source projects by government agencies, link to active code repositories or track contribution metrics. The community page shows a matrix of GitHub organization avatars, and the stories section carries written accounts of specific open-government initiatives. Each story is a Markdown file in the _posts/ directory and follows the standard Jekyll post format, which requires a dated filename and front matter fields. An organization looking to announce open-source projects, publish documentation or accept code contributions would need a different platform for those goals.

_data/governments.yml, _data/civic_hackers.yml and _data/research.yml drive the community page

The community page at government.github.com/community/ is built from 3 YAML files in the _data directory: _data/governments.yml for official government bodies, _data/civic_hackers.yml for individuals and groups building civic technology, and _data/research.yml for research organizations. Jekyll reads these files at build time and generates the organization avatar grid.

Adding an organization to the community page means adding an entry to the appropriate YAML file in the format already used by existing entries. The README does not specify which fields are required or what the valid values are; the existing file content is the only guide. A contributor who picks the wrong category file would have their organization appear in the wrong section of the community page.

Both the files themselves and any contributions to them are released under CC0-1.0, which means they can be freely used, redistributed or built upon without attribution. A researcher compiling a dataset of government organizations on GitHub can pull these 3 files and use them directly. The top-level repository also includes an organizations.json file alongside the YAML data, providing a single machine-readable export of the organization list for use by external tools or APIs without parsing the 3 separate YAML sources.

Local setup requires Jekyll, Ruby, Node.js and 4 shell commands

To run government.github.com locally, the requirements are Jekyll, Ruby, Git and a JavaScript runtime. Node.js is listed as the JavaScript runtime. Running the site locally follows this sequence:

git clone https://github.com/github/government.github.com.git
cd government.github.com
script/bootstrap
script/server

After these 4 commands, the site is accessible at http://localhost:4000. script/bootstrap installs the dependencies; script/server starts the Jekyll development server with file watching. GitHub Desktop installs Git automatically, so contributors using that tool do not need a separate Git installation.

The package.json lists 3 npm dependencies: octicons at ^5.0.1, primer-core at ^6.2.0 and primer-marketing at ^5.2.0. These are GitHub's own CSS and icon packages. The top-level directory also includes a committed node_modules/ folder alongside the package.json and bower.json files, which means the repository ships the installed packages rather than requiring contributors to run npm install separately.

Adding an organization means editing a YAML file and opening a pull request

For content changes, the contribution path is to fork the repository, edit the appropriate file, and submit a pull request. Adding a government organization to the community page means opening _data/governments.yml and adding an entry in the format already used there. Civic tech groups go into _data/civic_hackers.yml, and research organizations into _data/research.yml.

For site design or copy changes, pull requests go to the same repository. If a contributor cannot make the change themselves, filing an issue is the alternative. There is no contributor review process documented beyond the standard pull request workflow, and no required labels, templates or checklists are mentioned in the README. Contributors who do not want to clone the repository can edit individual files through GitHub's web interface in their fork and open a pull request without any local setup.

Story submissions follow the same pull request route. A story that covers a real-world GitHub use case in government, demystifies open-source terminology or helps other government bodies get started would align with the stated goals. A pull request that adds a story without a specific use case may not align, but the review criteria are not written down anywhere in the repository.

Staging on ghe.io needs 2FA credentials that outside contributors cannot obtain

government.github.com uses 2 repositories for deployment. Production is github/government.github.com, the public repository. Staging is a separate repository at government/staging on ghe.io, which is GitHub's Enterprise platform. The staging command is:

script/stage staging

This script generates the compiled _site directory and force-pushes it to the remote staging repository. Authenticating with ghe.io requires a personal access token because the system enforces 2-factor authentication. An outside contributor without a ghe.io account cannot run the staging step.

For small changes, the README says that merging a pull request deploys directly to production without needing staging. Larger changes that need review before going live require access to ghe.io, which limits that path to internal GitHub staff. One documented failure mode for the staging script is that the temporary Git repository inside the _site directory can go wrong, and the fix given is to delete the entire _site directory before retrying. If _site already exists with a broken temporary repository inside, running the script again without clearing that directory will fail. This is the only troubleshooting step given for the staging failure, with no explanation of what causes the corruption or how to prevent it. For contributors who only need to review visual changes, running the site locally at http://localhost:4000 is the accessible alternative.

No automated tests and node_modules committed directly into the repository

The package.json test script is a placeholder. Running npm test on this project prints 'Error: no test specified' and exits with code 1. There is no test suite for the site's HTML output, YAML syntax or link validity. A malformed entry in one of the _data files, or a broken Jekyll template, would not be caught automatically before a pull request is merged.

The top-level directory listing includes node_modules/ as a committed folder, which means the JavaScript dependencies at octicons 5.0.1, primer-core 6.2.0 and primer-marketing 5.2.0 are stored in the repository itself. New contributors cloning the repository get those specific package versions without running npm install. Updating these packages requires committing the changed node_modules/ content, which is a non-standard approach to dependency management.

Alongside npm, the repository includes .bowerrc and bower.json at the root, indicating that Bower is also used for some front-end dependencies. The local setup instructions in the README list only Jekyll, Ruby, Git and Node.js as prerequisites, with no mention of Bower or the npm install step. A contributor who runs only the 4 commands given in the README will start the Jekyll server without having explicitly run a Bower install; whether the committed node_modules folder covers those dependencies or not is not documented.

code.gov catalogues US federal repositories by agency; government.github.com covers stories globally

For organizations interested in discovering what open-source code government agencies have published, code.gov is a US-specific registry that lists federal projects with metadata: agency name, repository URL, project status and contact information. It covers projects on any source code hosting platform, not just GitHub. government.github.com, by contrast, is GitHub-specific, includes organizations from any country, and focuses on community membership and stories rather than project catalogues.

A developer looking for federal government open-source code to contribute to would find code.gov's agency-organized project metadata more useful. A researcher who wants to know which government bodies worldwide are on GitHub, or who wants to map the civic tech community across countries, would find the 3 YAML files at government.github.com more relevant.

Because the _data files are CC0-1.0, anyone building their own civic tech directory can use them as source data. A developer who forks the repository, strips the GitHub Pages deployment setup, and points the site at a different source platform would have most of the structure for a platform-agnostic equivalent.

Editorial conclusion

government.github.com fits open-government advocates and GitHub staff who want to add an organization to the community map or submit a civic tech story. Contributing means a fork and a pull request to 1 of the 3 YAML data files. Skip it if you need a code project registry or coverage of organizations on non-GitHub platforms, since the site collects stories and community members, not code repositories. Before contributing, check the format of an existing entry in _data/governments.yml or _data/civic_hackers.yml to match the convention already in use.

Frequently asked questions

Official sources

1. github/government.github.com on GitHub
2. Issues
3. Project website
4. README