The Sharing index measures how broadly information is shared among team members by looking at who’s reviewing whose PRs.
Which reports use the Sharing index?
Find the Sharing index in reports like Team health insights and Review collaboration.
What does the Sharing index measure?
Knowledge sharing happens when engineers are familiar with multiple areas of the code base and share that knowledge with others. There are two main ways to increase your team’s knowledge sharing. Engineers can work on multiple areas of the code base, or engineers can review each other’s code.
Since it’s not always practical for an engineer to work on multiple areas of the code base, reviewing code is a valuable opportunity to engage with different areas of the code base. This allows engineers to know more parts of the code and ensures no one person is a knowledge silo for a particular part of the code.
The Sharing index helps you determine whether you are increasing the proportion of users participating in code reviews and the balance of those reviews, or whether you tend to consolidate the group of people doing code review for your organization.
This metric is helpful in identifying knowledge silos and people who are isolated in their code reviews. Find the outliers and take action to help them get involved.
Tip: Also use the Review radar in Review collaboration to identify high-impact reviewers and other review patterns that you can address to reduce knowledge silos and increase your Sharing index.
How is the Sharing index calculated?
The Sharing index measures knowledge sharing on a scale of 0 to 1.
- 0 represents the least possible knowledge shared, meaning one person is doing all the reviews
- 1 represents a perfectly even distribution of work
Flow uses a variation of the Gini Coefficient (external site, opens in new tab) to calculate the Sharing index. The Gini Coefficient comes from the field of economics and is commonly used to measure the wealth distribution in a society. When you hear TV pundits say things like “the top 1% owns 40% of the wealth of a country” they are resting on this field of research.
As data points for the calculation, Flow uses:
- The total number of PRs merged during the time period.
- The number of available reviewers. A user counts as an available reviewer if they are a member of the selected team and committed code or commented on a PR during the selected time period.
- The number of active reviewers. A user counts as an active reviewer if they were an available reviewer and they reviewed a PR in the selected time period.
- The number of submitters. A user counts as a submitter if they are a member of the selected team who created a PR merged during the time period.
Understanding the Sharing index
In Flow's case, think of a PR comment as a unit of wealth. In a perfect world, everyone performs an equal number of reviews and the wealth is evenly distributed. In a highly unbalanced world where one person performs all the reviews, they have hoarded all the review-based knowledge available.
In practice, PR reviews are not the only way to share knowledge, just as there are other forms of wealth that aren’t considered in a Gini Coefficient. However, we have found that the Sharing index makes for a good signal for management. You can use it to help identify engineers who are not part of the everyday flow of reviews, as well as find hard-to-spot silos and other anti-patterns that can bubble up. The Sharing index adds a nice tool to help your team collaborate and share knowledge via reviews.
Use the Sharing index to manage your team’s broader trend toward or away from that imagined ideal of shared knowledge, keeping in mind that perfect distribution is rarely achievable nor is it desired.
Tip: We suggest aiming to have your Sharing index at or above 0.6. If your Sharing index is below 0.3, make knowledge sharing a focus for your team. Aiming for a perfect 1 is rarely desirable given the complexity of PR reviews.
What data is included in the Sharing index?
A pull request is counted toward the Sharing index if it is merged and has a review. It doesn't matter whether it’s merged from one feature branch to another or is merged into the main branch.
Pull requests aren't counted toward the Sharing index if they're:
- created by a user who is excluded from reports
- created by a hidden user
- an excluded pull request
- from a deleted repository
Comments on pull requests won’t be counted toward the Sharing index if:
- The comment is excluded
- The comment's author is excluded from reports
- The comment's author is a hidden user