Repository navigation
"Who are we helping" metric #115
Description
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.
Reacted by Zack Koppert and Moritz Schmitz von Hülst
Activity
zkoppert commentedon Sep 12, 2023
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 commentedon Sep 12, 2023
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 commentedon Oct 14, 2023
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 commentedon Dec 6, 2023
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 commentedon Feb 13, 2024
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 commentedon Mar 14, 2024
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 commentedon May 17, 2024
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 commentedon May 17, 2024
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.
britbufkin1225-web commentedon Jun 12, 2026
Hi! I’m interested in helping with this issue as a first contribution.
Before I start, I wanted to clarify the expected direction for the metric. Should this focus on identifying where PRs/issues are coming from, such as author, organization/team, assignee, or repository metadata? Or is the goal to add documentation/research around possible InnerSource-style metrics before implementation?
I’d be happy to start with a small scoped piece if there is a preferred direction.