# GitHub Enterprise: ansible-community & ansible-collections GitHub Org

**URL:** <https://forum.ansible.com/t/github-enterprise-ansible-community-ansible-collections-github-org/46639>\
**Category:** Project Discussions\
**Tags:** infra-and-security\
**Created:** [November 10, 2026, 6:57pm UTC](https://forum.ansible.com/t/github-enterprise-ansible-community-ansible-collections-github-org/46639 "2026-11-10T18:57:59Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![gundalow](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/gundalow/32/99_2.png) [@gundalow](https://forum.ansible.com/u/gundalow)\
**Post date:** [November 10, 2026, 6:57pm UTC](https://forum.ansible.com/t/github-enterprise-ansible-community-ansible-collections-github-org/46639/1 "2026-11-10T18:57:59Z")

</div>

Hi folks

# Summary

The [ansible-collections](https://github.com/ansible-collections/) & [ansible-community](https://github.com/ansible-community) and other Ansible related GitHub Orgs will move under Red Hat’s **GitHub Enterprise agreement**. This should not be a visible change, though we want to give our community a heads up, just in case you notice any differences

This will happen week of 16th November

# Details

There are many reasons why we are making this change, for the community the benefits are:

- Increased GitHub Runner capacity
- Benefit of Red Hat’s format support agreement with GitHub
- Access to GitHub’s Enterprise auditing and security features
- [CodeRabbit](https://www.coderabbit.ai/)

## Out of scope

- We will not be changing any [GitHub Branch Rulesets](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets) as part of this, we learned some lessons when we required signed-commits in the `ansible` org. Any potentially disruptive changes will be made independently and shared via #infra-and-security and #News & Announcements > Newsletter in advance.

# Questions

Feel free to ask

---

<div class="post-metadata">

**Author:** ![gundalow](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/gundalow/32/99_2.png) [@gundalow](https://forum.ansible.com/u/gundalow)\
**Post date:** [November 10, 2026, 10:34pm UTC](https://forum.ansible.com/t/github-enterprise-ansible-community-ansible-collections-github-org/46639/2 "2026-11-10T22:34:08Z")

</div>

[@SteeringCommittee](https://forum.ansible.com/groups/steeringcommittee) one issue I’ve just become aware of is that Outside Collaborators (non Red Hatters), can’t be members of teams. This is a technical requirement. It’s not an issue currently as the GitHub Orgs are stand-alone, and there’s no concern about accidental access to other Red Hat repos under the Enterprise.

I’ll need to audit the existing teams we have in the upstream GitHub Orgs, though I believe this would impact the Steering Committee GH team, which we use for repo permissions and code owners. We can script that.

Do we ever use `@steeringcomittee` as a comment?

Is having the “teams” and permissions defined in config files ok?

---

<div class="post-metadata">

**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\
**Post date:** [November 11, 2026, 6:59am UTC](https://forum.ansible.com/t/github-enterprise-ansible-community-ansible-collections-github-org/46639/3 "2026-11-11T06:59:19Z")

</div>

Right now [Sign in to GitHub · GitHub](https://github.com/orgs/ansible/teams/steering-committee) does contain a few community members, but only a subset (IIRC the reason why not all were added was because every person costs money). [Sign in to GitHub · GitHub](https://github.com/orgs/ansible-community/teams/steering-committee) is more complete (though it misses @dbrennand and @acozine), and [Sign in to GitHub · GitHub](https://github.com/orgs/ansible-collections/teams/steering-committee) is almost complete (the rotating core member is missing).

Also right now being members of the team means whether you have commit rights in some repos, like ansible-documentation, which also means that while we could manually add all SC member GH usernames in [ansible-documentation/.github/CODEOWNERS at devel · ansible/ansible-documentation · GitHub](https://github.com/ansible/ansible-documentation/blob/devel/.github/CODEOWNERS) for all the lines, and you need to manually add all the people to every repo they should have write access to. It would be good to automate this, otherwise this is a security and maintenance nightmare. (It might still be, depending on how good the automation is.)

Also right now we already have the situation that not all Ansible release managers (and SC members in general) have appropriate access to ansible/ansible-documentation, which means that for example @mariolenz cannot trigger the workflow that creates the porting guide PRs, and cannot merge these PRs. (Fortunately @gotmax23 and me have access, and @oranod is around to help, so this wasn’t a big problem yet, but it’s not really great either.)
