Introduction
Most engineering teams already collect a large amount of development data.
They know how many pull requests are opened, how many builds fail, how many security alerts exist, and how long changes take to reach production. The difficult part is turning all of that information into something that helps engineers make better decisions.
Code quality is a good example.
Looking at one repository can tell you whether that repository has a problem. Looking across multiple repositories can reveal whether the organization has a broader engineering pattern.
For example:
Repository A → Healthy
Repository B → Improving
Repository C → Increasing failures
Repository D → High technical debt
That is where organization-level code quality trends become useful.
GitHub has been expanding its code-quality capabilities around repository and organization-level visibility, giving engineering teams more ways to understand code health and identify patterns across their development environment. GitHub's current Code Quality features include analysis of issues such as maintainability problems and provide organization-level views for understanding quality trends.
The important point is that a code-quality dashboard should not become another management scorecard. It should help engineering teams identify where code needs attention and whether quality is improving over time.
What Are Code Quality Trends?
A code-quality trend is the change in software-quality indicators over time.
Instead of asking:
"How many issues exist today?"
ask:
"Is the number of issues increasing or decreasing?"
For example:
January 820 issues
February 760 issues
March 690 issues
April 620 issues
The trend tells a more useful story than a single snapshot.
The same principle can be applied across repositories:
Organization
│
├── API Service
├── Web Application
├── Background Worker
├── Mobile Backend
└── Infrastructure
Each repository can contribute quality signals to an organization-level view.
Why Organization-Level Visibility Matters
Imagine an organization with 50 repositories.
A platform team may notice:
Repository A → 12 quality issues
Repository B → 18 quality issues
Repository C → 5 quality issues
Those numbers alone are not very useful.
Repository A may contain 20,000 lines of code while Repository C contains 200,000.
A better analysis asks:
How large is the repository?
How old are the issues?
Are new issues being introduced?
Are developers fixing existing issues?
Which categories are increasing?
Which teams are improving?
Are critical services affected?
This changes the conversation from:
"Who has the most issues?"
to:
"Where is engineering quality improving or deteriorating?"
That is a much healthier use of engineering analytics.
Code Quality Is More Than Bug Count
One of the most common mistakes is treating code quality as a simple bug counter.
Code quality can involve several dimensions:
Code Quality
│
├── Correctness
├── Maintainability
├── Reliability
├── Security
├── Testability
├── Complexity
└── Consistency
A repository may have no obvious bugs but still contain code that is difficult to maintain.
For example:
public async Task<object> ProcessAsync(
object request)
{
// Hundreds of lines of mixed logic
}
The code may work today.
But if business logic, database access, validation, logging, and external API calls are all mixed together, future changes can become expensive.
That is a maintainability problem even if there is no immediate functional defect.
GitHub Code Quality
GitHub's Code Quality capabilities are designed to help identify and analyze code-quality issues as part of the development workflow. GitHub documentation describes Code Quality analysis as a way to identify problems in code and track them through repositories and organizations.
The important engineering idea is that quality analysis should become part of the development lifecycle:
Developer
|
v
Code Change
|
v
Pull Request
|
v
Quality Analysis
|
+--> Issues
|
+--> Review
|
v
Merge
This is more effective than discovering quality problems months later during a large refactoring project.
Repository-Level vs Organization-Level Analysis
There are two different perspectives.
Repository Level
A repository-level view answers:
"What is happening in this codebase?"
Useful for:
Developers
Repository maintainers
Technical leads
Reviewers
Organization Level
An organization-level view answers:
"What patterns are appearing across our codebases?"
Useful for:
These views should complement each other.
Organization
|
+--> Repository A
+--> Repository B
+--> Repository C
+--> Repository D
An organization-level trend should lead engineers back to the repositories where the actual work needs to happen.
A Simple Quality Trend Model
Suppose an organization tracks quality findings each month.
Month Findings
January 950
February 910
March 875
April 820
May 790
The trend is positive.
But now consider:
New Findings
January 100
February 140
March 180
April 220
May 250
At first glance, total findings are falling.
But new findings are increasing.
That tells us the organization may be fixing old problems while simultaneously introducing new ones.
This is why a single metric is rarely sufficient.
Measure New Issues and Resolved Issues Separately
A useful model is:
Net Quality Change =
New Issues - Resolved Issues
For example:
Month New Resolved Net
January 100 120 -20
February 130 110 +20
March 150 140 +10
This provides more context than simply looking at the total number of open findings.
A healthy engineering process should ideally avoid continuously creating quality debt faster than it removes it.
Trend Analysis Across Repositories
Consider four repositories:
| Repository | Open Findings | New This Month | Resolved | Trend |
|---|
| Orders API | 42 | 8 | 15 | Improving |
| Payments | 18 | 3 | 4 | Stable |
| Identity | 75 | 21 | 5 | Worsening |
| Reporting | 31 | 4 | 12 | Improving |
The Identity repository deserves attention.
Not because it has the highest absolute number, but because:
New Issues = 21
Resolved = 5
The quality debt is moving in the wrong direction.
That is a much more actionable insight.
Avoid Comparing Teams by Raw Issue Counts
Raw counts can create misleading conclusions.
Imagine:
Team A → 100 findings
Team B → 40 findings
It would be tempting to say Team B has better code quality.
But suppose:
Team A → 2 million lines of code
Team B → 100,000 lines of code
The comparison changes completely.
Repository size, age, complexity, language, architecture, and application type all affect quality metrics.
Use normalized measures carefully.
For example:
Findings per 10,000 lines of code
can sometimes provide additional context.
However, even normalized metrics should not be treated as a universal quality score.
Code Quality and Pull Requests
Quality analysis becomes more useful when connected to pull requests.
Consider:
Pull Request #142
|
+--> 3 quality findings introduced
|
+--> 1 existing issue resolved
|
v
Reviewer
This gives the reviewer additional context.
The question is not simply:
"Does this PR pass CI?"
It becomes:
"Does this change introduce avoidable quality problems?"
This is especially useful for larger repositories where a reviewer cannot manually inspect every maintainability concern.
Quality Gates
Some organizations may want quality rules to prevent problematic changes from merging.
Conceptually:
Pull Request
|
v
Build
|
v
Tests
|
v
Code Quality
|
+---- Fail ----> Fix
|
v
Review
|
v
Merge
This is a quality gate.
However, quality gates should be introduced carefully.
If every warning blocks every pull request, developers may start ignoring the system or spending time fixing low-value issues.
A better approach is to prioritize meaningful findings.
For example:
Critical
High
Medium
Low
The exact classification depends on the analysis tool and organizational policy.
Quality Trends and Technical Debt
Technical debt is often difficult to see because it accumulates gradually.
A team may add:
5 minutes here
10 minutes there
30 minutes somewhere else
over hundreds of changes.
Eventually, simple modifications become difficult.
Code-quality trends can help make this accumulation visible.
For example:
Technical Debt Trend
Q1 █████
Q2 ██████
Q3 ████████
Q4 ██████████
The chart itself is not the solution.
The useful question is:
"Why is technical debt increasing?"
Possible reasons include:
The trend is a signal that should lead to investigation.
A .NET Example
Consider this ASP.NET Core service:
public async Task<Order> CreateOrderAsync(
CreateOrderRequest request)
{
// Validate request
// Check inventory
// Calculate price
// Save database record
// Call payment service
// Send email
// Write audit record
// Large amount of mixed logic
}
This may work, but it creates several maintainability concerns.
A cleaner design could separate responsibilities:
public async Task<Order> CreateOrderAsync(
CreateOrderRequest request)
{
await validator.ValidateAsync(request);
var order = await orderService.CreateAsync(request);
await paymentService.ProcessAsync(order);
await notificationService.SendAsync(order);
return order;
}
The second version is easier to reason about and test.
A code-quality tool may identify some of these maintainability problems automatically, while architectural decisions still require human judgment.
Use Quality Trends With Human Review
Automated analysis is useful, but it does not understand the entire business context.
For example:
if (customer.IsPremium)
{
ApplyDiscount(customer);
}
A static analyzer can examine code structure.
It cannot determine whether the business requirement itself is correct.
This gives us an important separation:
Automated Analysis
|
+--> Code-level problems
Human Review
|
+--> Business correctness
+--> Architecture
+--> Design intent
The strongest engineering workflow uses both.
Tracking Quality by Repository Type
Different repositories naturally have different quality profiles.
For example:
| Repository Type | Important Quality Signals |
|---|
| ASP.NET Core API | Reliability, security, maintainability |
| Background Worker | Reliability, error handling |
| Frontend | Maintainability, performance |
| Infrastructure | Security, configuration safety |
| SDK/Library | API stability, compatibility |
| Data Pipeline | Reliability, correctness |
| Test Repository | Coverage, maintainability |
This makes organization-level analysis more meaningful.
A single quality score across every repository is usually too simplistic.
Measuring Quality Over Time
A useful dashboard could show:
Organization Code Quality
Open Findings
1,240
New Findings
182
Resolved Findings
231
Repositories Improving
34
Repositories Worsening
7
Then provide repository-level drill-down:
Identity Service
|
+--> Quality Trend
+--> New Findings
+--> Resolved Findings
+--> Pull Requests
+--> High-Priority Issues
This follows a useful analytics principle:
Start broad, then allow engineers to investigate the underlying data.
Don't Turn Quality Into an Individual KPI
This deserves special attention.
Code-quality data can be useful for improving engineering systems.
It becomes harmful when used as:
Developer A → 12 findings
Developer B → 8 findings
and then interpreted as a performance ranking.
That approach can encourage developers to:
Quality metrics should primarily describe the health of the software and development process.
They should not become a simplistic employee score.
Common Mistakes
Mistake 1: Looking Only at Total Findings
Total findings do not show whether the situation is improving.
Mistake 2: Comparing Repositories Directly
Repositories have different sizes, languages, ages, and purposes.
Mistake 3: Treating Every Finding as Equally Important
A minor maintainability issue and a serious security problem should not receive the same attention.
Mistake 4: Ignoring New Findings
A repository may reduce its backlog while continuing to introduce new problems.
Mistake 5: Blocking Every Pull Request
Overly aggressive quality gates can slow development without providing proportional value.
Mistake 6: Treating Automation as Architectural Judgment
Static analysis can identify patterns. It cannot replace experienced engineering review.
Mistake 7: Using Quality Metrics to Rank Developers
This creates bad incentives and can damage trust in engineering analytics.
Troubleshooting Quality Trends
| Problem | What to Check |
|---|
| Findings suddenly increase | Check recent large changes or new analysis rules |
| Repository looks worse than another | Compare size, age, language, and architecture |
| Quality gate blocks too many PRs | Review thresholds and finding severity |
| Findings remain unresolved | Check ownership and backlog prioritization |
| Trend suddenly changes | Verify analyzer/version changes |
| Dashboard numbers look inconsistent | Check analysis scope and reporting period |
| Developers ignore findings | Reduce low-value noise and prioritize actionable issues |
A sudden change in quality metrics does not necessarily mean that the code suddenly became worse.
A change in the analysis configuration can also affect the numbers.
Best Practices
Track Trends, Not Just Snapshots
Historical movement provides more useful information than today's number alone.
Combine Multiple Signals
Use:
New findings
Resolved findings
Open findings
Severity
Age
Repository size
Pull request trends
Prioritize High-Impact Issues
Not every finding deserves immediate engineering effort.
Keep Quality Gates Practical
Block changes only when the benefit justifies the development friction.
Review Analyzer Changes
When the underlying analysis rules change, document the impact on historical comparisons.
Drill Down Into Repositories
Organization-level metrics should help teams find the actual source of the problem.
Keep Human Judgment
Quality tools should support engineers, not replace engineering judgment.
Treat Quality as a Team Responsibility
The objective is to improve the codebase, not create a ranking system.
Advantages
Better Organization-Wide Visibility
Engineering teams can identify quality patterns across multiple repositories.
Earlier Detection
Problems can be identified during development rather than after production incidents.
Trend-Based Decision Making
Teams can determine whether quality efforts are actually improving the codebase.
Easier Prioritization
Repositories with worsening trends can receive additional attention.
Better Pull Request Feedback
Quality analysis can provide another signal during code review.
Disadvantages and Limitations
Metrics Can Be Misleading
A single number cannot fully describe software quality.
Repository Differences Matter
Different systems have different technical and business requirements.
False Positives Are Possible
Automated analysis may identify patterns that are acceptable in a particular context.
Quality Improvement Takes Time
Reducing technical debt does not always produce immediate business value.
Dashboards Can Create Metric Fatigue
If developers receive too many low-value findings, they may stop paying attention.
Configuration Changes Affect Trends
Changing analyzers or rules can make historical comparisons difficult.
A Practical Organization-Level Strategy
A team starting with organization-wide code-quality tracking can keep the process simple.
Step 1: Establish a Baseline
Record the current state of repositories.
Open Findings
New Findings
Resolved Findings
High-Priority Findings
Step 2: Group Repositories
Classify repositories by:
Service
Library
Infrastructure
Frontend
Data
Step 3: Track Monthly Trends
Do not judge the system from one snapshot.
Step 4: Identify Worsening Repositories
Focus engineering attention where the trend is moving in the wrong direction.
Step 5: Investigate the Cause
Look at recent pull requests, architectural changes, dependencies, and development practices.
Step 6: Measure Improvement
After introducing quality improvements, check whether the trend changes.
The goal is a feedback loop:
Measure
|
v
Understand
|
v
Improve
|
v
Measure Again
A Useful Engineering Health Dashboard
A mature dashboard could combine code quality with other engineering indicators:
Engineering Health
│
├── Code Quality
│ ├── Open findings
│ ├── New findings
│ └── Resolved findings
│
├── Delivery
│ ├── PR cycle time
│ └── Deployment frequency
│
├── Reliability
│ ├── Incidents
│ └── Failed deployments
│
└── Security
├── Vulnerabilities
└── Security findings
This is more useful than treating code quality as an isolated number.
For example, if quality findings increase while deployment frequency also increases dramatically, the engineering team may need to investigate whether delivery pressure is affecting maintainability.
Again, the correlation does not automatically prove causation.
It simply provides a useful signal for investigation.
Conclusion
GitHub Code Quality trends become much more useful when they are treated as an engineering feedback mechanism rather than a simple list of problems. Looking at one repository tells you what is happening today, while organization-level trends can show where quality is improving, where technical debt is growing, and where teams may need additional engineering attention. The important part is to avoid reducing software quality to one number. Combine new findings, resolved findings, severity, repository context, pull request activity, and human review to understand the bigger picture. Used this way, code-quality analytics can help engineering teams make better decisions without turning developers into metric targets. The real goal is simple: find problems earlier, understand why they are appearing, and steadily make the codebase easier to maintain.
Join the conversation! Your thoughts help the community grow.