EMU Feature Request: Enable "Internal" Visibility and Team/Group Access for Managed User Namespaces

[alonsomoya]

Select Topic Area

Product Feedback

Body

The Problem with GitHub Enterprise Managed Users (EMU) and Personal Repository Visibility

As a developer in a GitHub Enterprise Managed Users (EMU) environment, I am encountering a significant limitation that hinders collaboration and InnerSource adoption: the inability to set any visibility other than "Private" for personal repositories owned by my user account.

The Issue

GitHub’s EMU documentation states:

"Members of an enterprise with managed users can only set the visibility of repositories owned by their personal account to Private."

While I understand that this restriction is likely a "secure by default" measure, it introduces several critical challenges:

Forced Silos

By locking personal repositories to "Private," individual innovation is hidden. If I build a useful tool or prototype, it cannot be easily discovered by other teams across the enterprise via global search. This creates unnecessary silos within the company.

No Middle Ground

As it stands, I must choose between keeping my work completely invisible (Private) or joining an Organization, which may not always be feasible. The governance and structure of an Organization might extend beyond the scope of my project, or the nature of my work may not align with the objectives or culture of the Organization. This lack of flexibility significantly slows down collaboration and the ability to share projects within my team or department.

Missing the "Seed" Phase

Successful internal tools often begin as small personal projects, the "seed" phase, that later grow into company-wide resources. GitHub’s current setup locks down this phase by making personal repositories invisible to others. Some well-known projects started as personal projects before evolving into dedicated organizations. The inability to share early-stage work without an Organization structure undermines the natural growth of projects within an enterprise.

Here are some articles that mention the importance of this "seed" phase for open-source projects, which can apply to internal tools as well.

Bridging the Technical Gap

While I understand the rationale behind restricting the visibility of personal repositories, especially in terms of security and governance, recent updates (Feb 2024) have introduced features like Secret Scanning and Push Protection specifically for personal repositories. These updates address many of the technical concerns, making it feasible to allow more flexible visibility options.

The Request

I propose that GitHub allows Enterprise Admins to enable the possibility to opt-in for "Internal" visibility for repositories owned by managed user accounts. This would enable personal repositories to be discoverable within the enterprise without exposing them to the public.

Additionally, if opening the repository to all users within the enterprise isn't feasible, users should still be able to bind explicit access rights to Enterprise Teams/Groups. This would allow sharing the repository with specific teams or groups, making it easier to collaborate with larger groups (e.g., an entire department or community of practice) without the need to move the project to an Organization. This provides an effective solution where broad access isn't possible but collaboration with teams can still be achieved.

Thank you for considering this request.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐