GitHub is a closed-source platform for open-source communities. It allows us to collaborate on documentation and code, both internally and with a broader audience.
If you don’t have a GitHub account, you must use your work email (rather than your personal email) to sign up, as this helps us with records retention and identification. If you do have a GitHub account, please add your work email to your profile as your primary email.
1. Complete your profile
Include the following:
- Name: Your first or first and last name.
- Company: Your government agency. (If you also use GitHub for personal projects, consider specifying “
agency(work) + personal projects” to make it clear that some of your GitHub projects may be personal in nature.)
- Location: Your primary work location (city, state).
- Photo: A headshot photo, or an image that is unique to you.
2. Set up local Git configuration
- Use your work email rather than your personal email for work-related commits. This only applies to people with more than one email address tied to their GitHub account. Note that this is different than setting notifications to go to a specific email address.
- If you’re using your work computer for personal projects on GitHub and want your personal email tied to those commits, you can set your GSA email as part of the global
.gitconfig, then override on a repository level with your personal email, or use a tool like karn. If you have both emails in your GitHub settings, they will both be tied to your GitHub account anyway.
3. Adjust notification settings
Take a look at your notification settings. In particular, it’s suggested that you turn off
Automatically watch repositories. You may also want to take a look at tips for filtering GitHub notifications in email.
4. Join the 18F organization
An admin will add you, after which you’ll need to accept their invite from the email or by going here.
You may need access to other GitHub organizations, depending on your job. If that applies to you, your team will get you added as part of their onboarding.
5. Make your membership public
Go to the 18F people page. Click where it says private next to your name. Change that to public.
Abide by the TTS Code of Conduct. If you see anyone violating our Code of Conduct, see the reporting section.
Do not store sensitive information in GitHub, including environment variables, private configuration data, or sensitive information about the public (including but not limited to PII). In the event that such variables or configuration data is pushed to a GitHub repository accidentally, even momentarily, consider it compromised and revoke or change the credentials immediately. Do not delete the commit itself. Then immediately follow the directions on the incident response handbook page. If you’re unsure how to protect this information, consult with Infrastructure on GitHub or in the #admins-github channel in Slack. Some projects use Citadel to store secrets. Also refer to the TTS Handbook page on sensitive information and guidance on sensitive information in our open source policy.
Ask TTS Tech Portfolio before integrating a service with GitHub. Many websites offer the option to “Sign in with GitHub” and may further request permission to access your “personal user data.” Providing this level of access can not only share your public or private email address, but it can also grant the ability to access TTS private repositories. For this reason, we ask that all organization members refrain from authorizing integrations and request any desired integrations through an TTS Tech Portfolio issue.
Ask TTS Tech Portfolio before creating private repositories. We pay GitHub for the ability to create private repositories and need to bill clients for repositories created on their behalf. Before you do anything, drop into #admins-github and explain what you’d like to do and why. Be sure to include a link in your repo README to a document that explains why it is private. (See the Exceptions section of the 18F Open Source policy.)
You do not need approval to create public repositories.
Ask TTS Tech Portfolio before deleting repositories. As a government team, we can’t delete repositories without TTS Tech Portfolio first reviewing them for information that they may need to retain (including issues, pull request comments, commit history, and other information). Archiving is preferred in most cases. If you want to delete a repository, go to #admins-github and explain what you’d like to do and why, and wait for approval before deleting it. This approval is generally contingent on no substantive content having been created within the repository (e.g. new issues, commits, substantive comments). In cases where the content of a repository is no different than that of another repository, it may be considered for deletion.
Handoff to partner agencies
By the time engagements end, repositories developed for another agency should be transferred. After transferring the repository to the client’s organization, create a fork of it in one of our organizations. This is so that:
- We have a record of the repository and the work done for that partner.
- We have a copy of the code, should they decide to delete the transferred repository, make it private, etc.
If the repository is no longer in use, it should be archived.
See Intro to GitHub.
Working with outside collaborators
Giving contractors and federal partners access to your repository is both allowed and encouraged to facilitate the flow of ideas and build a stronger, more decentralized community.
Confusingly, no one should be an “outside collaborator” in GitHub parlance. Instead, we should manage repo access exclusively via teams.
Here’s our current process to address both operational and security concerns:
- If the user is a member of the federal government, confirm we have an active inter-agency agreement (IAA) or other legal document authorizing the work.
- If the user is a contractor, confirm we have an active and valid contract with them, or their company.
- Ask the collaborator(s) to go through the first three setup steps.
- They will need to confirm they’ve done this before you continue.
- They will also need to add an e-mail address to the GitHub profile so we can contact them later when doing clean-up in our org.
- Do not ask the admins to add the collaborator to the 18F or OPP teams as detailed in step 4.
- (Ask #admins-github to) create a team whose access we can turn off/on with one button. Separate a staff-only team from a contractor/mixed/collaborator team for a project, and name it something like
Project name - Collaborators | Skillset. You only need to set a
parent teamfor your new team if you need your team to inherit existing permissions from an existing team (for example, if this team should automatically have access to a base set of repos). If your new team is for external collaborators, you will generally not want to add a parent team.
- In the “Description” of the team, put something reasonable plus a point-of-contact email address for the collaborators.
- Ideally this is the address of someone senior — someone you can email if issues come up and who can rally the troops.
- (Ask #admins-github to) add the members to the team.
- Give the team read/write permissions on the relevant repositories. Admin rights should be limited exclusively to TTS staff.
When the engagement is over, you must let #admins-github know so the team can be deleted and access removed.
TTS defaults to using branches, though teams are welcome to decide they prefer using forks instead. Regardless of whether you branch or fork, changes happen via pull requests.
In the process of receiving feedback in a pull request, some individuals on some teams may choose to amend, reorder, or squash commits. This type of “re-writing history” is compliant with the Freedom of Information Act (FOIA) when it occurs on a pull request because git branches are considered a work in progress. These actions are not allowed on the master branch because that is considered the canonical source of information.
If you want to make a suggestion to an TTS project without making a specific change to its code, such as if you aren’t sure how to fix a problem or want clarification before fixing something, file an issue on that project via GitHub. Try searching the list of open issues before you add one; the error you see might already be on the team’s radar.
Teams can give groups of people administrative, write, or read permissions to TTS repositories. Even if you have write access into a repository, we strongly encourage the submission of pull requests for improvements or fixes (see “we prefer branching to forking when we’re working together on TTS projects,” above).
Contractors or external government collaborators should only be added to teams with permissions to the repositories they’re working on. You can create
<project>-partners teams, if necessary.
As discussed in the 18F open source policy, we archive repositories to deprecate them. In short, that means we are no longer maintaining them, including keeping dependencies up-to-date. Inactive repositories are automatically archived via ghad.
If the repository is published as a package, please also mark it as deprecated.
- NPM: Use
- PyPI: Publish with a
Development Status :: 7 - Inactiveclassifier
- Ruby gem: Publish with a post-install message
No approval is needed to archive/unarchive a repository. Feel free to do so yourself, or ask #admins-github for help. Note that archiving a repository is not the same as deleting it.
Once the repository is active, it will need to be maintained, including all security tasks.
Creating a new GitHub organization
Create an issue and follow the steps.
GitHub Actions can be used for continuous integration/deployment on public repositories, but is not currently available for private repositories in (most of) our GitHub organizations for billing reasons.
Document your workflow. There are many different ways to use GitHub, and each different team of people at TTS (likely) uses it differently. That said, teams should document their desired git workflow for each project, such as in your repository’s
contributing.mdfile. The 18F-Site team offers a good example with their GitHub wiki. In TTS’ development guide, there are code review questions that your team may want to go over as you think about documentation.
Do you fork or do you branch? Git allows you to both “fork” and “branch” repositories to make a place to work on changes before you submit them for integration into the main code. Making a fork creates a copy of the repository in your own GitHub account. Making a branch of the main repository means you’re working in your own little space, but it’s still part of the main repository—which helps keep the project organized, since everyone can easily see what teammates are working on.
In GitHub parlance, where repos all have admins, org-wide administrators are called “owners.”
- When you take care of an ask, give it a :check: reaction in Slack. If you have questions about an ask, please start a thread so that the channel stays clean.
- Whenever possible, owners should push decisions as to be as close as possible to those most affected - like whoever owns or last worked on a repo.
- If you aren’t sure about the answer to something, its always better to check with someone else instead of guessing.
- If you aren’t helping out as an owner, please give up your permissions to help minimize our risk.
TTS is heavily involved in the following GitHub organizations:
|@project-open-data||Y||Y, shared with OMB|
1: TTS staff, contractors, and partners who are offboarding need to be removed from all government-owned GitHub organizations.
2: For the ones that are TTS-managed, get help in #admins-github.
We automate some administration of our repositories - see
ghad for more info.
When people join TTS, they get added to the 18F org, and possibly others (in list above). Not everyone will end up using GitHub, but they are granted access by default. The following GitHub teams correspond to the different business units:
- COEs (Centers of Excellence)
- PIF (Presidential Innovation Fellows)
- OA (Office of Acquisition)
- solutions - portfolios will handle adding them to the appropriate team(s) within there
Githug is designed to give you a practical way of learning git. It has a series of levels, each requiring you to use git commands to arrive at a correct answer.