While other bots do this already (i.e., SafeSettings), it would be beneficial for this bot to include such functionality as well. After all, users of this bot may not be using others and assigning teams access to repositories falls under the purview of "syncing teams."

Decision Points

• Repo name property- should it just be Name, or Name and NamePattern?
  • Leaving it as "Name" makes consumption easier though increases development. Most likely that is worth it- make the consumer experience great.

Schema Options

Teams:
- Name: Some_Team
  Repos:
# Pattern matching can be done, though specific technique must be chosen and documented.
  - NamePattern: SomeName-*
    Permission: Write
  - Name: SomeSpecificRepo
    Permission: Admin

OrganizationMembersGroup: my_org_git_users
GitHubTeams:
  - name: Team A
    group: AZU_SOME_TEAM_USERS
  - name: CloudEnablement
    group: AZU_CE_ADMINS

Some way to make the name of the Team that is beings synced different than the group it's syncing to. This also facilitates more Team-scoped metadata later.

• Perhaps use a configurable glob style syntax for discovery?
  • https://docs.microsoft.com/en-us/dotnet/core/extensions/file-globbing#get-all-matching-files
• Must flatten full list to validate no duplicates
  • If duplicate detected, fail operation
  • Failure of an operation would be reported either by the Action or the GitHub App as a commit/PR status. Do not embed reporting logic in Core

Why allow this? To leverage CODEOWNERS as a means to delegate trust for team creation

Some mechanism should be added to this app to support for enabling/disabling Enterprise features.

• Perhaps a flag at the App level- IsEnterprise:boolean.
• False by default (to minimize setup by non-enterprises).
• Enables/disables registration of Enterprise specific endpoints (i.e., list Orgs in Enterprise)

As title says.

For example, if the display name is

• Team 1

Then in GitHub, it should be displayed as

• Team 1

At the moment, it is being set to

• Team-1

Feature suggestion, with no clear implementation yet: support for Team Templates.

As title says:

Many calls are cached for two reasons:

1. To mitigate bumping into the GitHub API rate limit
2. To make this application feel "snappier" since some calls can be very time consuming for larger orgs.

This isn't necessarily a v1 requirement, but certain calls (i.e., listing members of an org) NEED to be ran in the background on some set cadence (even when this hooks into GitHub events- we need to validate at some point that no event was missed, after all).

Admins and Organizations should be able to provide a list of Team Names that should never be synced by this bot. There have been reported cases where such Teams were communicated out to their coworkers, but folks were still adding said Teams.

This is mainly problematic when the underlying groups may contain many, many, thousands of users. However, in all cases that I've heard of, it isn't the size of the team that is the problem... it's moreso that the large team simply shouldn't be used via this bot.

One issue that is present with large teams- due to API rate limits, this bot WILL run into issues syncing large teams (>1000 users).

I'm not entirely sure how it happened but it seems like when a team listed in the file doesn't actually exist in AD it may create a team as private.

A valuable feature for this bot to add is the ability to manage Copilot teams: https://docs.github.com/en/rest/copilot/copilot-business?apiVersion=2022-11-28#add-teams-to-the-copilot-business-subscription-for-an-organization

Note that this functionality should be marked as Beta and/or should include extra wrappers in case of failures- failure to set this due to API changes should not cause the whole bot to fail.

Schema Options

I'm leaning towards Option 2 as it promotes the reuse of an existing team for granting Copilot Access while still granting the flexibility of having a designated team for Copilot access. With the top level property of Option 1, reuse for general repo access would not be possible.

The bot could support both concepts, though that may cause undue confusion 🤔 for now I am in favor of choosing one or the other.

Option 1 - New top-level property

OrganizationOwnersGroup: Some_Org_Owner_Group
OrganizationMembersGroup: Some_Group_To_Sync_For_Organization_Membership
GitHubTeamNames:
- Some_Team_To_Sync
AdditionalSecurityManagerGroups:
- Name: Some_SecurityManager_Team
- Name: Some_SecurityManager_Team_2
  DisplayName: Some Security Manager Team 2
# A new top level property
CopilotLicenseTeams:
- Name: Some_Copilot_Team
- Name: Some_Copilot_Team_2
  DisplayName: Some Copilot Team 2
Teams:
- Name: Some_Team
- Name: Some_Team_2
  DisplayName: Some Team 2

Option 2 - New property on Teams

OrganizationOwnersGroup: Some_Org_Owner_Group
OrganizationMembersGroup: Some_Group_To_Sync_For_Organization_Membership
GitHubTeamNames:
- Some_Team_To_Sync
AdditionalSecurityManagerGroups:
- Name: Some_SecurityManager_Team
- Name: Some_SecurityManager_Team_2
  DisplayName: Some Security Manager Team 2
Teams:
- Name: Some_Team
- Name: Some_Team_2
  DisplayName: Some Team 2
- Name: Some_Team_3
  DisplayName: Some Team 3
# A new property on individual Teams
  CopilotEnabled: true

What would I need to change/update to leverage this in a new GHEC Enterprise against a new LDAP environment?

• Development requirements
• Running app locally
• Debugging tips and tricks
• Running app in production (this should cover the question above)

It would be great to have the functionality to denote a group of people as the org owners. It would save a lot of manual effort as we add additional org owners to our larger orgs.

For this to work properly, we wouldn't want to remove org owner rights if they fall out of the existing group. That would put us at risk of having an unmanageable org if we have a sync failure. I would prefer removing org owners manually when needed.

The sync bot should be able to cancel in-flight invitations in the case where a GitHub User has joined the Organization Member group after getting access to an individual team.

This will help resolve an issue some users are facing- where they are never added to GitHub Teams due to an existing Org Member Invitation being present.

For my own sanity, the bot must output additional details when performing operations. For example,

• Any time the bot is trying to add a user to the team, if the user doesn't exist and/or is "dormant" the sync bot must clearly state so. At this point in time, the bot does output users with Issues... However, additional clarity could be had by clearing separating/categorizing what "type" of issues are found with the user. More thoughts are needed on this.
• If an Org has not granted the app the proper permissions, some operations will fail. The logs must clearly call attention to the fact that the bot does not have permissions, and that folks must poke the Org Owners to update said permissions (by requesting the updated permissions request from the bot).

This feature will only be useful for Enterprise customers.

Requires the following Issue to be completed first: #59

While the OrganizationMembersGroup exists to control Org Membership, there has been an increase in asks to allow for individual teams to simply grant an assumption of Membership. As one of the tenets of a good app (in my opinion) is to not make assumptions on others behalf, I am opening this Issue to catalog my thoughts on a potential solution (in addition to recording this ask).

Solution Idea

A new boolean property: AssumeMembershipViaTeams.

By default, this will remain false and optional. Organization's may choose to set this to true. Doing so should cause the app to skip Organization Membership checks for individuals as the assumption as set via this property will be that any member of a team should be a member of the Org.

Risk

This may complicate a future enhancement around the ability to remove Org Members, but with proper segregation of components this should not prove too difficult to implement.

It seems to sync on an interval, which is cool but it would be nice to sync right on merge so it happens "right away" after merging.

As title says 🙂

It would be advantageous if this bot could support nesting Teams.

The team sync yaml could be enhanced to support something like the following:

# This property is used to control the addition of general Members to your Organization.
OrganizationMembersGroup: Some_Group_To_Sync_For_Organization_Membership
# This property is used for syncing all other GitHub Teams. Please note that users must also be a part of the `OrganizationMembersGroup` for the synchronization of the teams below to function properly.
GitHubTeamNames:
- Team: Some_Team_To_Sync
  FollowChildren: true 
- Team: Some_Other_Team_To_Sync
  Children:
  - Team: Some_Child_Team_To_Sync
    Children:  Some_Child_Team_To_Sync
  - Some_Other_Child_Team_To_Sync

On pr to default branch create a check suite and check run which will verify that the AD group already exists and fail if it doesn't.

Also emit some information in the check run result such as how many people will be added to the team once merged.

• Choose testing tooling
• Add tests