Feature and its Use Cases
What is the feature?
A new "Teams Explorer" dashboard inside OrgExplorer that fetches team data from the GitHub API and renders an interactive relationship graph. This graph maps Team parent nodes to their respective member contributors (avatars) and assigned code repositories. Additionally, users with admin PATs can drag and drop developer nodes into teams to update memberships visually.
How would users benefit from it?
Auditing Permission Models: Mentors and org administrators can quickly see which contributors belong to which write/triage/admin teams across different repositories.
Visual Team Management: Simplifies managing permissions. Instead of digging through multiple submenus in GitHub's organization settings page, admins can perform drag-and-drop actions in a unified graph dashboard.
Onboarding Awareness: New GSoC students or contributors can visually explore the organization structure and identify who belongs to the frontend, backend, or documentation sub-teams.
What scenarios would this feature address?
Organizing GSoC students into sub-groups during coding periods.
Auditing repository access rights across nested organization teams.
Analyzing team collaboration density.
Additional Context
Proposed Implementation Outline:
API Services:
Retrieve org teams via GET /orgs/{org}/teams.
Query team members via GET /orgs/{org}/teams/{team_slug}/members.
Mutate membership allocations using PUT /orgs/{org}/teams/{team_slug}/memberships/{username}.
Visualization:
Extend D3 or the existing canvas force-graph model (similar to NetworkPage) to represent Teams and member orbits.
Support HTML5 pointer event drops to trigger memberships updates.
Addresses the open item outlined in
FeatureWishlist.md
Code of Conduct
I would like to work on this issue !
Feature and its Use Cases
What is the feature?
A new
"Teams Explorer"dashboard inside OrgExplorer that fetches team data from the GitHub API and renders an interactive relationship graph. This graph maps Team parent nodes to their respective member contributors (avatars) and assigned code repositories. Additionally, users with admin PATs can drag and drop developer nodes into teams to update memberships visually.How would users benefit from it?
Auditing Permission Models: Mentors and org administrators can quickly see which contributors belong to which write/triage/admin teams across different repositories.
Visual Team Management: Simplifies managing permissions. Instead of digging through multiple submenus in GitHub's organization settings page, admins can perform drag-and-drop actions in a unified graph dashboard.
Onboarding Awareness: New GSoC students or contributors can visually explore the organization structure and identify who belongs to the frontend, backend, or documentation sub-teams.
What scenarios would this feature address?
Organizing GSoC students into sub-groups during coding periods.
Auditing repository access rights across nested organization teams.
Analyzing team collaboration density.
Additional Context
Proposed Implementation Outline:
API Services:
Retrieve org teams via
GET /orgs/{org}/teams.Query team members via
GET /orgs/{org}/teams/{team_slug}/members.Mutate membership allocations using
PUT /orgs/{org}/teams/{team_slug}/memberships/{username}.Visualization:
Extend D3 or the existing canvas force-graph model (similar to NetworkPage) to represent Teams and member orbits.
Support HTML5 pointer event drops to trigger memberships updates.
Addresses the open item outlined in
FeatureWishlist.mdCode of Conduct
I would like to work on this issue !