Closed rrrutledge closed 5 months ago
I'll write up a quick summary here first.
We have a central internal team that maintains and operates a Kusto Cluster that holds several databases of metadata from our version control platforms (GitHub & Azure DevOps). This data comes from the version control platforms' APIs. Putting it in Azure Data Explorer enables it to be queried via kusto queries, which enables certain operations to be done that would take much longer if the person who wanted to query had to do all the API calls to get the data. Kusto query language is a variation on SQL queries. There is also data on reporting relationships in another Kusto cluster that allows it to be determined who reports to who.
We are identifying InnerSource pull requests as pull requests where the most common approvers for pull requests in a given repository have a manager they report to who is not the same person as the manager of the person who submitted the pull request. By measuring how many reporting levels you have to go up before the reporting manager is the same, we can determine approximately how far apart in the company the owning team is from the pull request submitter.
We use this data to produce a few other metrics or tools:
The last metric can be combined with string matching to find InnerSource friendly repositories whose title or README has a given string value.
Thank you for this summary, @JustinGOSSES. This work may be a pattern on its own, or it may be an addition to the Introducing Metrics in InnerSource pattern.
Q: Is it useful to share approaches to this measurement if it depends on a company-specific internal metrics store?
Some thoughts:
A lot of the metrics are specific to individual repositories. This sounds like it could be useful. There is a CHAOSS-inspired approach to gathering metrics. There are program-specific metrics and also project-specific metrics. This is related to a portal for exploring project and metrics. Raw contributions are a subset of the overall area of community engagement (e.g. orbit.love/model).
Q: How can we work on this in a tangible way together?
Some thoughts:
Have a repo where we can have an example portal and iterate on it together. This could go in the innersource commons. The idea is that the portal would have metrics and presentation of projects.
A (Google?) doc where we can each put our point of view.
Q: Will we get lost if we try to work on something as big as a portal (instead of something simpler first)?
Let's split this up:
Here are some elements to think about:
Q: Why do we need this information?
Some thoughts:
Keep an idea on adoption? Provide a convincing argument of something?
Out of the discussion around this topic, the following GitHub discussion was created: https://github.com/InnerSourceCommons/ispo-working-group/discussions/60
We have some PRs in the Managing InnerSource Projects handbook to create a place to document this stuff.
We have a place to document our metrics now! Check out https://github.com/InnerSourceCommons/managing-inner-source-projects/blob/master/CONTRIBUTING.md#metrics
This might be solved with #74 , now we have a place to document metrics, the Managing InnerSource Projects book. The original topics was not external yet, thus, moved to challenge.
Duplicate of Microsoft metrics, sort of :)
closing
Duplicate of Microsoft metrics, sort of :)
closing
@jeffabailey think this is enough of a duplicate to close? Contribution distance is basically the same concept so if you have measures of it, you're measuring cross org contributions https://innersourcecommons.gitbook.io/managing-innersource-projects/measuring/goals/use_gqm
Have a pattern describing this approach - https://patterns.innersourcecommons.org/