This is the fourth post in a multi-part series on using GitHub for Government. In previous posts, we’ve discussed what the public can see and do with GitHub and what Drupal code should and shouldn’t be in a public repository. In this post we’ll discuss users and permissions on organizational accounts, and in the final post, we’ll look at developer workflows.
If your developers peer review each other’s code, if you have multi-person teams and want to control roles and permissions for code access, or if your organization’s code sticks around longer than your developers, a GitHub Organization is a powerful tool made with someone like you in mind. An organization:
- simplifies management of group-owned repositories
- centralizes your organization’s code
- allows you to set up roles and permissions that can be applied to different groups of users across multiple repositories
- Simplifies Git-based workflows for teams of any size
How do you create a GitHub Organization?
Only existing GitHub users can create an organization, so to start you’ll need at least one member of your organization to have a GitHub user account. Once a user is logged in, they can create a GitHub organization by following the steps outlined here. An organization is similar to a user profile, in that it can be named and have its own code repository. There are different paid account options, which correspond to different numbers of private repositories that your organization can own. There is also a free organization option, which contains your free open source code projects, but you have to pay to work on any private projects.
Once set-up, an organization works similarly to a user account - it is paid, it can add users to the organization, and it can add users to its private projects. An organization owns the projects that are created within them, so no single user controls the fate of a project. For reference, Acquia has a GitHub organization that you can review. There you’ll see different actions taken by members of the organization, and you can also see some of the Acquia GitHub organization members.
Who controls an organization?
Organization repositories have varying levels of permissions. Authorized members of an organization can manage issues, which means they can include issues or label them, can associate issues with milestones on the agency’s project roadmaps, and can delegate issues to members of the team who are going to work on them.
Does the public see all of an organization’s members and their activity?
The short answer is no. As mentioned above, when you look at the Acquia GitHub organization page, you can see the public members listed, but there may be organization members who are not public, and therefore won’t be listed. User visibility can be toggled on and off, depending on whether a project, and user association, needs to be kept private or is something that can be shared publically. This is a helpful feature if you’re working on projects that require discretion.
User activity on public projects, however, is always public, no matter the user. But users who are private members of an organization can comment on issues as themselves, without the public knowing that they have any association with that organization. Here’s an example:
User X is a private member of Organization Y, so when you visit the Organization Y page, you won’t see them listed as a member. User X replies to an issue in the Organization Y issue queue, but appears to be a member of the public, because they have chosen to make their association with Organization Y private. There are instances, however, when User X may want to show their association with Organization Y, especially in a situation where authority is needed, and they can prove their authority by sharing their association with the organization.
In the next post in this series on GitHub for Government, we’ll discuss developers and workflows.
