Interested in bringing GitHub Enterprise to your organization?
Start your free trial for 30 days and increase your team’s collaboration. $21 per user/month after trial expires.
Curious about other plans?
After the public beta announcement at GitHub Satellite, we’ve continued adding to the internal repository visibility and it’s now generally available as of October 28. We’d like to thank all of the beta participants for their engagement and feedback during this beta period. Your input played a critical role in creating this feature and the direction that brought the product to where it is today.
We received over 100 unique enterprise customer requests and countless more individual developer reports, all enthusiastic about bringing the innersource methodology to their businesses. The internal repository visibility allows an enterprise-owned repository to be read by any member of any organization that belongs to an enterprise account.
We wanted our customers to have this feature quickly, but we knew we had some work to do after launch. Some of the feedback we received during the beta was expected, like requests for API support and more specific search capabilities. What we didn’t expect was that many users, including some internal to GitHub, thought that these repositories were internal to a specific GitHub organization. Here’s why we think that happened:
We made a few precise changes to internal repositories to help our users.
The first and second changes were almost entirely responses to customer feedback, which we’ll cover in the following sections.
At launch, we needed to provide an interface that allows you to create an internal repository and understand the core differences from internal, public, or private options. Let’s take a look at the interface before and after we made a few updates.
In the new repository dialog at launch, “GitHub” is both the name of an enterprise account and organization. We’re telling the user that all members of the GitHub account can see this repository. Since we can’t see what kind of entity “GitHub” is, it wasn’t clear who could see the repository. This led users to believe that the visibility was organization-wide instead of across the enterprise account. For clarity, we added the enterprise account’s avatar to the dialog and changed the text to state that “enterprise members” of the enterprise account will be able to see this organization-owned repository. This removes ambiguity between the organization and enterprise account names.
During the beta, one of the most interesting things we learned is that the members of organizations belonging to an enterprise account didn’t really notice that they were members of an enterprise account rather than a collection of GitHub organizations. While this was not disruptive to the user’s regular behavior, it was a primary cause of confusion around who could (or should) be able to see an internal repository. To address this, a distinct role description for enterprise members was added that we link directly in the new repository creation dialog.
Without valuable input from our users, we wouldn’t have been able to create this feature or improve the user experience. We can’t express our thanks enough and hope you’ll continue collaborating with us. Ready to give us more feedback? Share your comments with us. Be sure to select “Teams, organizations, or Enterprise accounts” where our product team will be watching for items related to internal repositories.
With the upcoming release of GHES 2.20, we’re adding the internal repository visibility to our on-premises offering and creating a uniform experience for both Cloud and Server platforms. Stay tuned for more updates as we continually improve your experience.