The Directory Browser seeks to address three of the most common customer questions we receive:

The answers to these questions lies within the Directory Browser:

open_in_new

While the Directory Browser has insights for technical managers and C-level employees, it's probably most valuable for developers themselves. Read on to learn more about how its features combine to deepen your relationship with your repo data.

linkMost Active Contributors

open_in_new

Past six months of activity in the Ruby on Rails Github repo: "Most Active Contributors" column

For each directory or file in your project, we provide a list of which committers have made the biggest impact over the selected time range.

If you're a developer who has to maintain code in this directory, this is the fastest path to discover who to send your questions to. If you're a technical manager who knows the style of code written by their developers, this column foreshadows the style of code written. If you're a C-level sort, this is the fastest way to acquaint yourself with which developers have been working on what areas within your software.

linkLine Impact

open_in_new

Past six months of activity in the Ruby on Rails Github repo: "Line Impact" column

For each directory or file in your project, we'll show how much Line Impact has been accumulated over your selected time frame.

If you're a developer, this information is golden when you're new to a project and trying to quickly grasp where the code is hiding. Continuing the Rails example, most of the the work happening in Rails during the past six month has been in ActiveRecord. More specifically?

open_in_new

Past six months of activity in the Ruby on Rails Github repo: "Line Impact" column

Aside from tests, the most work during the past six months has gone into connection_adapters and associations. Apparently Rails will be launching some juicy new features in those areas for Rails 6.1. Tip o the cap to user kamipo for making that happen.

If you're a manager or C-level user, this data gives you a lens into where your team is spending their energy. Are you maintaining a legacy module that feels like its soaking up time, but you're not sure how much? Instant answers. Same if you're wondering whether tests and documentation are getting written.

linkEstimated Time Spent

open_in_new

When viewing the "All Files" tab, the Estimated Time Spent is the sum of time spent on all files in the selected directory, or in its sub-directories. For example, if Developer A changed the app/something.py file in a commit that took 1 hour, and Developer B changed app/models/fruits/banana.py in a commit that took 3 hours, then the "Estimated Time Spent" for the "app" directory would be 4 hours.

To learn how the "Estimated Time Spent" is calculated for "Debt Inspector" tab, check out the the help page for Tech Debt Inspector.

linkLine Impact Velocity

open_in_new

Past year of activity in the GitClear repo: "Line Impact Velocity" column.

For every file and directory in which 60 or more minutes have been accumulated, we calculate the quotient of Line Impact / Estimated Time Spent. We make this same calculation against your repo as a whole to arrive at your average Impact Velocity (aka "Line Impact per hour"), and the Impact Velocity of a particular file or directory.

Directories with higher velocity are places where one of the two things is happening:

The first phenomenon is pretty self-explanatory. Directories with high velocity indicate low tech debt, and low tech debt make happy engineers.

The second case is a bit more interesting. If you use GitClear's recommendation of rewarding "documentation" and "tests" at a higher Line Impact than standard code (to incentivize development toward those ends), then it's not uncommon to see test and documentation directories lead the way in terms of Line Impact velocity.

linkFile Selected

open_in_new

Past six months of activity in the ReactFiberHooks.js file within the Facebook React Github repo

When you browse down to the individual files, we have one final click for developers: a specific rundown of who has been making the biggest commits within the file lately. When you want to chat about matters related to that file, these are your people.