"Who are we helping" metric

[MaineC]

Some InnerSource projects essentially provide platform capabilities for the organisation, meaning that they "only" have internal teams as customers. Understanding and talking about the customer value and business value of these platforms sometimes can be tricky.

With a bit of a workaround though it becomes easier: Look at issues and PRs created and check which team (filtered down to e.g. product teams with external customers) the reporter is assigned to. Then provide aggregate information on how many times each of these teams was unblocked by solved issues and how many times such teams were able to unblock themselves with PRs.

[zkoppert]

Wow, this would certainly be interesting!

When you mention "teams" would that correlate to teams in a github organization or are you thinking that would connect to some type of active directory system that could be queried for a username's team membership?

[MaineC]

Active directory would be lovely. But as a first approximation I believe regular GitHub teams could already be helpful. While those can be cluttered, I can imagine that one could provide a whitelist of team names to use for this so that anything like "I love Open Source" GitHub teams that my user may be part of in that organisation can be filtered away (though come to think of it, it would be interesting if it's the open source lovers that produce more PRs internally also ;) )

[spier]

Awesome InnerSource metric in the making here :)
I can imagine this to be a helpful metric for many people.

Worth noting that the "who are we helping" could be a combination of
a) who is using the project (similar to the dependents view in GitHub)
b) who is opening issues/PRs on our repo

[MaineC]

Note for myself - someone pointed out a step in between that might be helpful here:

https://github.com/marketplace/actions/team-labeler-action ... adds team labels to PRs which can then likely could be used in a later step to compute statistics per team/label.

[MaineC]

Looking into this a bit more - the action above seems to rely on it's users to feed it with the github user/ team relationship. So in addition to keeping users in the right teams on github one would also need to update that configuration.

In an ideal world, I would like to only feed in team names to consider and commenters found only check if their team matches one of the pre-configured team names.

The trouble with that though: The GitHub REST API seems to only allow retrieving entire team+members data, but I see no link from a pr/issue comment -> user -> team. The workaround I found online also relies on retrieving the entire team-membership data up-front. Am I missing something here? Otherwise I'd try to make team names to consider configurable, retrieve team membership up-front (though for large organisations this could mean trouble) and continue from there.

[github-actions]

This issue is stale because it has been open 21 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[singha04]

Some InnerSource projects essentially provide platform capabilities for the organisation, meaning that they 'only' have internal teams as customers. Understanding and communicating the customer value and business value of these platforms can sometimes be tricky.

[MaineC]

https://a-a-ron.github.io/innersource-completed-pluralsight/rollout-checklists/ ... also details several InnerSource related metrics that are based on a notion of identifying where PRs are coming from.