Feature request: Support slicing the collaborator graph by teams instead of organizations

[bbatha]

GitHub recommends for most companies that they have a single large organization, and that you use teams to break down access rather than organizations. The collaborators graph is an awesome feature, but unfortunately gives little insight if you are running in the recommended configuration.

[larsxschneider]

True. However, companies as large and diverse as Autodesk, Adobe or others need more than one GitHub organization for various reasons.

That being said - I am have chart for you in the pipeline that shows collaboration across repositories within a single organization! Stay tuned!

[ghost]

@larsxschneider since our company is exploring a mono-org approach, I was wondering, once a chart is available for cross-repository collaboration, what can we expect our take away to be (what should we learn from that visualization)?

I'd just like to make sure we'll be able to effectively use the new chart, and to what degree we may still need the cross-team chart.

[larsxschneider]

@destroyerofbuilds @bbatha I experimented a bit today with cross repository collaboration. Unfortunately, I wasn't able to find a useful visualization, yet.

We have >>10k organization repositories on our appliance and many products span over multiple repositories. Naturally there is strong collaboration amongst those repositories. Therefore, I don't think this way will lead to useful results.

@bbatha mentioned that s/he wants to see collaboration by team. Well, our bigger products have multiple teams working on them. Again, naturally there is a strong collaboration between those teams.

I wonder about your configuration... how many repositories do you have in your mono-org setup? Do you see a good way to cluster these repositories? Would it be even necessary to cluster them or are all your repositories completely independent projects?

[bbatha]

I wonder about your configuration... how many repositories do you have in your mono-org setup?

We have about 1800.

Do you see a good way to cluster these repositories?

Instead of clustering by repository, I'd like to see clustering by team. Chances are teams with similar membership (or similar contributions to repositories) should be a single team.

Would it be even necessary to cluster them or are all your repositories completely independent projects?

They frequently are not. We have a pretty common pattern (which is relatively easy to identify if naming conventions are followed) of:

app-api app-api-client-$lang (usually 3-5 of these depending on the team's domain) app-frontend