This one is for those tracking where GitClear is headed next. At a high level, our goal for the next 3 months is to integrate Google DORA's benchmark stats alongside Cycle Time, Story Points, and Line Impact.

linkQ4 goal: Community

Start capturing the best ideas from CTOs and freelance engineering managers. Live prototype now here. Couple it with a podcast, and/or engineering newsletter. Give engineering leaders a platform to showcase themselves, so the best CTOs aren't bound to a single company. Offer 50% first year revenue to CTO referrers, which they can split between a payout to themselves and a discount to their client.

linkQ4 goal: Easiest DORA Integration

As evident from reviewing GitClear competitors, support for DORA is in the earliest stages. Getting hooked into a dev team's idiosyncratic build process requires configuration. Tracking when a "critical bug" occurs is more difficult still. And marking when a release has been patched isn't a walk in the park. But, compared to where we've already been (i.e., building Line Impact), implementing DORA is a layup. We will start tracking DORA metrics in September or October, and we'll have it cohesively tied it in with the rest of the GitClear experience by the end of the year.

We'll be eager to hear from users throughout the process of this rollout. We'd love to recruit some pilot users to help us make sure that it takes the minimum possible effort on their end to get all of the tracking set up. We will look to use heuristics to simplify setup (example).

linkQ4 goal: Allow experts to configure team incentives

The metrics most often discussed as means to understand the health of a dev team include:

Release count. How often does the team deploy?

Failure/critical bug percent. What percentage of deploys have a failure in them?

Time to resolve failure/critical bug. How many hours does it take to recover from such failures?

Cycle time: time from first commit on issue to release. How long is the team averaging between the first commit on a PR, and the code for the PR being deployed?

Story points (or PRs/tickets closed as fallback). How much work from the issue tracker is getting done?

Line Impact. What is the rate at which the team is evolving their git repos?

These kind of blend into metrics commonly used to gauge code health. The question becomes: which metrics are most applicable to my team? Our working theory is that the "the most useful metric" is driven by the challenges a team experiences. "The biggest challenge" for a company seems to vary based on size:

Enterprise challenge: don't get mired in process. DORA-style metrics best validate that the team can still make releases quick, and that critical bugs don't linger. These are core tenets of a enterprise companies like Google (who funded the research, complete with percentile buckets).

Mid-size challenge: high issue tracker velocity while maintaining quality. Story Points Completed and Cycle Time are the cornerstones of a healthy mid-sized company. Releases generally aren't too encumbered on a 10-30 member team.

Startup challenge: outpace competitors bound by process. Line Impact lights the path to victory. Small teams simply need to launch their product fast while maintaining test coverage and documentation. Story Points and releases are unlikely to be high priority to a small team.

In Q4, we will blend these signals into the "Highlights" section, letting a team season their metrics to taste.

Beyond that, we will highlight Line Impact's appraisal of whether documentation and test goals are being met

linkQ4 goal: better explain how & why Line Impact changes

While we have recently published a help page to qualitatively describe why Line Impact changes over time, it can still be vexing to debug the specific reason(s) that Line Impact scores change over time. This imperfect transparency may hide anomalies in Line Impact processing. We will implement a system to better describe changes to Line Impact that exceed a given threshold.

linkQ4 stretch goal: freemium version

We're going to get to this at some point. We have another server coming online in the next few weeks, which should give us enough asynchronous bandwidth to at least manage a few months' processing for hobbyists, especially for open source projects.

linkGot more ideas?

GitClear Founders are standing by if you have more ideas for the roadmap that you'd like to contribute: Our rate of growth continues to beat our expectations, with 460% revenue growth over the past year alone. We are deeply grateful to the many small and large companies trusting GitClear to make git clearer! 🙏