Feature and its Use Cases
I would like to propose adding a Teams Mode to the existing Network page in Org Explorer to visualize GitHub organization teams, their members, and team relationships.
What the feature would do:
The existing Network page visualizes repositories and contributors. A new Network / Teams toggle could allow users to switch between the current repository-contributor network and a team-oriented view.
In Teams Mode:
GitHub organization teams would be displayed as visually distinct hexagonal nodes.
Team members would be displayed as contributor/avatar nodes.
Connections between teams and members would represent team membership.
Team nodes could show useful information such as team name, privacy, description, and member count.
Member tooltips could show their GitHub username, avatar, and the number of teams they belong to.
For organizations with multiple loaded orgs, an organization filter could allow users to focus on a particular organization.
Optional Team Management:
For users who provide a GitHub PAT with the required organization write permissions, Teams Mode could also support basic membership management:
Drag a member node onto a team to add them to that team.
Provide a context action to remove a member from a team.
Show optimistic UI feedback when a membership is changed.
Gracefully handle permission/API errors and revert the UI when an operation fails.
Users without the required PAT permissions would still be able to use Teams Mode as a read-only visualization.
Use Cases
This could be useful for:
Understanding how contributors are organized across GitHub teams.
Discovering which contributors collaborate within the same working groups.
Identifying contributors who belong to multiple teams.
Exploring team structure in large organizations without manually navigating GitHub's team pages.
Giving maintainers a visual way to manage team membership when appropriate permissions are available.
The feature would build on the existing Network page and Org Explorer architecture rather than introducing a completely separate visualization.
Additional Context
The proposed feature is intended to extend the existing Network visualization rather than replace it.
The implementation could reuse the existing D3 force-graph, GitHub service layer, caching mechanism, and PAT-gated action pattern already present in Org Explorer.
A possible flow would be:
Network page → Network / Teams toggle → Teams graph → select/filter organization → explore team/member relationships
For the visualization, team nodes could use hexagons to clearly distinguish them from the existing repository and contributor nodes.
For team management, GitHub's organization team membership APIs could be used, with write operations enabled only when the user's PAT has the required organization permissions.
The feature could also include loading skeletons and empty/error states for organizations that have no teams or where team information cannot be accessed.
References
GitHub REST API endpoints that could be used include:
GET /orgs/{org}/teams
GET /orgs/{org}/teams/{team_slug}/members
PUT /orgs/{org}/teams/{team_slug}/memberships/{username}
DELETE /orgs/{org}/teams/{team_slug}/memberships/{username}
The initial proposal is open to discussion regarding the exact UX, PAT permissions, and whether team management should be included in the first iteration or treated as an optional enhancement.
Code of Conduct
Feature and its Use Cases
I would like to propose adding a Teams Mode to the existing Network page in Org Explorer to visualize GitHub organization teams, their members, and team relationships.
What the feature would do:
The existing Network page visualizes repositories and contributors. A new Network / Teams toggle could allow users to switch between the current repository-contributor network and a team-oriented view.
In Teams Mode:
GitHub organization teams would be displayed as visually distinct hexagonal nodes.
Team members would be displayed as contributor/avatar nodes.
Connections between teams and members would represent team membership.
Team nodes could show useful information such as team name, privacy, description, and member count.
Member tooltips could show their GitHub username, avatar, and the number of teams they belong to.
For organizations with multiple loaded orgs, an organization filter could allow users to focus on a particular organization.
Optional Team Management:
For users who provide a GitHub PAT with the required organization write permissions, Teams Mode could also support basic membership management:
Drag a member node onto a team to add them to that team.
Provide a context action to remove a member from a team.
Show optimistic UI feedback when a membership is changed.
Gracefully handle permission/API errors and revert the UI when an operation fails.
Users without the required PAT permissions would still be able to use Teams Mode as a read-only visualization.
Use Cases
This could be useful for:
Understanding how contributors are organized across GitHub teams.
Discovering which contributors collaborate within the same working groups.
Identifying contributors who belong to multiple teams.
Exploring team structure in large organizations without manually navigating GitHub's team pages.
Giving maintainers a visual way to manage team membership when appropriate permissions are available.
The feature would build on the existing Network page and Org Explorer architecture rather than introducing a completely separate visualization.
Additional Context
The proposed feature is intended to extend the existing Network visualization rather than replace it.
The implementation could reuse the existing D3 force-graph, GitHub service layer, caching mechanism, and PAT-gated action pattern already present in Org Explorer.
A possible flow would be:
Network page → Network / Teams toggle → Teams graph → select/filter organization → explore team/member relationships
For the visualization, team nodes could use hexagons to clearly distinguish them from the existing repository and contributor nodes.
For team management, GitHub's organization team membership APIs could be used, with write operations enabled only when the user's PAT has the required organization permissions.
The feature could also include loading skeletons and empty/error states for organizations that have no teams or where team information cannot be accessed.
References
GitHub REST API endpoints that could be used include:
GET /orgs/{org}/teams
GET /orgs/{org}/teams/{team_slug}/members
PUT /orgs/{org}/teams/{team_slug}/memberships/{username}
DELETE /orgs/{org}/teams/{team_slug}/memberships/{username}
The initial proposal is open to discussion regarding the exact UX, PAT permissions, and whether team management should be included in the first iteration or treated as an optional enhancement.
Code of Conduct