This is the second post in a multi-part series on using GitHub for Government. In the first, we discussed the basics of getting your government agency up and running with GitHub. In this post, we'll take a look at what the public can see and do with GitHub, and in the upcoming posts, we'll discuss what Drupal code should and shouldn't be in a public repository, users and permissions on organizational accounts, and developer workflows.

Here's a quick overview of things that become visible and interactions that become public when a person makes a code repository, or 'repo', public on GitHub.

1. Code becomes downloadable and publicly viewable online. Visitors can browse through folders, click files, and view code through their web browser. (browsing example, view files/code example)

2. The code's change history (the git 'log') also becomes public. This is like a 'track changes' history. For every saved change, Git keeps track of the changes made, user who made the change, the date the change was made, and a message logged by the user. These changes can be viewed online and in copies of the source code.

Examples:

• A list of logged changes, authors, and messages viewable online on GitHub (here)
• A single change, its author, and the author's message on GitHub (here)
• A list of changes in a visitor's copy of the repository (here)
• A single change in a visitor's copy of the repository (here)
• All past releases are visible and downloadable online (here) and in a visitor's copy of the code base (here)

While there is no obligation for code maintainers to respond to public input, public repositories on GitHub do open a few new channels for the public to interact with a project:

• GitHub users can submit comments about saved changes, also known as 'commits' (example here)
• GitHub users can submit proposed changes to code as 'pull requests,' so that the project maintainers know they can consider 'pulling' changes into the main codebase (example here)
• GitHub users can copy ('fork') and maintain their own versions of any project they have access to (forking a project: begin here, end here)

Recommendations:
Your government agency should use an organizational GitHub account to publicly host open source code. GitHub is the easiest and most user-friendly way to release code to the public.

If you are interested in 'open sourcing' your code, but people in your organization are wary of creating new, unknown, or unsupervised channels of communication with the public, disable the Wikis and Issues features. To the public, releases on GitHub will feel like a normal but 'bare bones' use of the software.

Regarding this 'bare bones' use – it is perfectly respectable to make code public, but not use GitHub as a forum for discussion or community engagement. Just because a repository is public, the owner of the repository is not obligated to communicate with the GitHub community or manage development in public view. Linus Torvalds, the creator of Linux and Git, uses GitHub to host Linux (x), but he does not manage development publicly there. Similarly, there is a mirror of Drupal's authoritative git repository on GitHub here, but the wiki and issue tracker are disabled. Discussion, collaboration, and issue tracking for these projects happens somewhere else. For your agency, you can decide on a project-by-project basis if your roadmap and issue tracker should be private or public, and take place on GitHub or elsewhere.

In the next post in this series on GitHub for Government, we'll discuss what Drupal code should and should not be included in a public repository.