Fixes land faster than ever. Shipping them takes longer.

An analysis of every issue (6,485) and pull request (7,327) in opencrvs/opencrvs-core from May 2018 to 4 October 2026, including project board status history, reviews and release tags. Most charts cover 2022 onwards; board history starts in October 2023.

Most of the change lines up with the Events V2 rewrite. On the time charts, the shaded area is the period before V2 work began in November 2024, and dashed lines mark 1.9 (V2 ships) and 2.0 (pre-V2 services removed).

Issues in each board stage, weekly

Completed, not yet closed
Waiting for release or in QA
In development
In code review

Open issues by their latest project board status at the end of each week. Work in development and review stays between 15 and 60 items; finished work waiting to ship grew to 315 before the 2.1 release closed about 170 of them. Dashed lines mark the 1.9, 2.0 and 2.1 releases.

Findings

Events V2 is where the change starts. Most improvements begin in late 2024, when V2 work began, not when 1.9 shipped. From January 2025 to April 2026, PRs to V2 code got a first review in a median of 2 hours against 20 for older code, and merged in about half the time at the same size. The cost shows in 1.9 and 2.0, which had the most bugs and regressions.
Work gets built quickly. On the project board, the median time from In Development to Completed was 5–10 days through 2025–26, down from 18–26 days in the first three quarters of 2024. Development and code review alone take a median of 1–4 days in 2026.
Reviews are fast. The median wait for the first human review fell from 14–25 hours in 2024 to 2–3 hours in 2026, and 85% of PRs got one within 3 days in Q2 and Q3 2026. PRs are bigger than in 2023 (median 80–170 changed lines in 2025–26, against 30–70 in 2023), and size is the clearest predictor of waiting: PRs under 50 lines merge in a median of 4 hours, PRs over 1,000 lines in 5 days.
Finished work waits to ship. Issues marked Completed waited a median of 21–49 days before being closed in 2026, against 1–16 days in 2024. Issues are closed when a release ships, so this is release wait. The queue of Completed-but-open issues grew from about 50 at the start of 2025 to 315 in September 2026; 199 are still waiting after 2.1.
The open backlog has tripled. 300 open issues in early 2022, 977 today. Since late 2024 more issues were opened than closed in most quarters. Median age of an open issue is 270 days; 68% are older than six months.
Closure counts are unreliable. 44% of all closures (2,412 of 5,505) happened in batches of eight or more within minutes. Most are release or QA batches, but 749 were clean-up sweeps of year-old issues, and 748 of those were marked "completed". "Not planned" has been used 62 times in the repo's history.
Quality is improving. Regressions per 100 merged PRs went from 43 (1.9) to 31 (2.0) to 17 (2.1, still early). The share of completed items sent back from QA fell from 18–22% in 2024 to 5–18% in 2025–26. Fewer PRs get "changes requested" (1–6% in 2025–26, 9–25% in 2022–23); that could mean better PRs or lighter review, so watch it next to regressions.
2.1, the first release on V2 alone, had far fewer bugs than recent releases. 38 bugs were raised per 100 merged PRs during the 2.1 cycle, against 88 for 1.9 and 98 for 2.0, even though 2.1 had the best issue type coverage (78%). 1.9 needed 88 bug fixes across its patch releases after shipping; 2.0 has needed 11 so far.
Most of each release's scope arrives after the cycle starts. 86% of the issues in the 2.0 milestone and 70% of those in 2.1 were created during the release cycle. About half of the added issues are bugs, the rest new features and tasks. Issues moved between milestones aren't counted yet, so the real number of scope changes is higher.
AI-assisted work is now a fifth of PRs. 17–21% of merged PRs from July to September 2026 have an AI co-author, up from 4–6% in March to June and almost none before. Q3 2026 also had 369 merged PRs from 16 authors, the highest per-author rate since 2022, and the share of closed PRs that were merged fell from about 88% to about 80%. PR counts are not comparable across these periods without that context.

Before and after Events V2

Events V2 is a rewrite of how OpenCRVS defines and processes life events. Work on it started in November 2024, when the events and toolkit packages were created. It shipped alongside the old system in 1.9 (November 2025), and the old backend services (gateway, workflow, search, metrics, user-mgnt, config) were removed during the 2.0 cycle in April and May 2026.

The rewrite had a cost: 1.9 and 2.0 had the highest bug and regression rates measured, 1.9 needed about 20 patch releases, and the backlog doubled during 2025. It also changed how fast work moves. Changes to V2 code are reviewed within hours instead of a day, and merge in about half the time at the same size. 2.1, the first release on V2 alone, had the lowest bug rate of the five releases measured.

What merged PRs changed, per quarter

Code that predates V2
Events V2 code
Both
Other: tests, CI, Helm charts, shared UI

A PR counts as V2 or pre-V2 when at least 80% of its changed code files are in that area. Events V2 code is packages/events, packages/toolkit, the client's v2-events folder, and the event, conditional and field configuration in commons. Docs, lockfiles, CI config and translations are ignored. After 2.0, most "both" PRs touch V2 and the parts of the client shared with the old UI.

Median hours to merge by PR size, January 2025 to April 2026

Events V2 code
Code that predates V2

Both codebases were in active use in this period. Only 15 PRs over 1,000 lines touched pre-V2 code, so that pair of bars is the least reliable.

January 2025 to April 2026	Events V2 code	Code that predates V2

What to keep in mind

Only 8 people made at least five PRs in each codebase. For them, V2 PRs got a first review after 4 hours instead of 20, but V2 PRs merged faster for only 4 of the 8. Part of the difference is who worked where, and where the team's attention was.
Board tracking widened in 2025, which pulls cycle-time medians down. The PR numbers in this section aren't affected by that.
AI co-authorship rose from July 2026, at the same time as the 2.1 improvements.
For KR 2.1, use Q3 2026 onwards as the baseline. Earlier numbers come from a different codebase and process.

Cycle time from the project board

In Development to Completed

Median days
85th percentile days
Median days in development and review

Grouped by the quarter the issue reached Completed. Covers the 1,498 issues that went through In Development or In Code Review before Completed (48–202 per quarter). Development and review means In Development until the first post-review status such as Ready for release or Ready for QA.

Completed to closed (release wait)

Median days, grouped by the quarter the issue closed.

Issue flow and backlog

Issues opened and closed per quarter

Closed individually
Closed in a release or QA batch
Closed in a clean-up sweep
Opened

A batch is eight or more closures with less than five minutes between each. Batches whose issues mostly had no milestone and a median age over 180 days count as clean-up sweeps. All other batches count as release or QA batches.

Open issues at end of quarter

Reconstructed from open and close dates. Today's count (977) is lower than end of Q3 because about 170 issues were closed with the 2.1 release on 2 October.

Age of the 977 open issues

333 open issues have no issue type set; 287 are bugs.

Pull requests

Time from PR opened to merged

Median days
85th percentile days

Human-authored PRs only; Renovate, Dependabot, GitHub Actions and ocrvs-bot are excluded. Grouped by merge quarter.

Wait for first human review

Median hours
85th percentile hours

From the PR being opened, or marked ready for review if it started as a draft, to the first review by someone other than the author. Review bots (Copilot, Greptile, Cursor, CodeRabbit) are excluded; they reviewed about 2% of 2026 PRs.

Merged PRs with an AI co-author

Share of merged human-authored PRs where at least one commit has a Co-authored-by trailer from an AI tool (Claude, Copilot, Greptile). 98% of merged PRs were found in git history. Tools that don't add a trailer, such as inline completions or chat, aren't counted, so this is a lower bound. 15 more PRs were opened by AI agent accounts since October 2025 and are excluded with other bots.

PR size and waiting, 2025–26

Changed lines	Merged PRs	Median hours to merge	Median hours to first review

Merged PRs per quarter and active authors

Merged PRs
Merged PRs per author (right axis)

Active author means anyone with at least one merged PR that quarter: 9 to 20 people per quarter, 66 over the repo's life.

Releases and quality

Minor release	Days since previous minor	Merged PRs in cycle	Patch releases	Regressions	Per 100 PRs

Regressions are issues labelled "1.9 regression", "2.0 regression" or "2.1 regression"; the label did not exist before 1.9. Tagged releases per quarter went from 2–4 in 2024 to 5–8 in 2025–26, mostly 1.9.x patches.

Share of completed board items that were moved back from a QA status to Ready to build, In Development or Backlog: . Reopened issues are rare, 1–2% of issues created in 2025–26.

Bugs per release

Release	Codebase	Bugs raised during cycle	Per 100 merged PRs	Bugs fixed in patch releases	Issues with a type

Bugs are issues with issue type Bug. The cycle runs from the previous minor release to this one, and includes bugs against any version. Bugs fixed in patch releases are bugs in milestones such as 1.9.1 or 2.0.3. Untyped issues aren't counted, so earlier releases are undercounted more; the last column shows how many issues created in the cycle had any type.

Release scope changes

Release	Issues in milestone	Planned before cycle	Bugs added	Other added	Share added

Counts issues in each release milestone (such as 2.0 or 1.9.0, not patch milestones). Planned before cycle means the issue was created before the previous minor release shipped. Added means it was created after that and before this release shipped. This undercounts scope changes: existing issues moved into the release, and issues moved out to a later release, need milestone change history, which wasn't fetched.

Proposed sprint metrics for KR 2.1

None of these need story points, and all of them can be computed from GitHub every sprint with the data used here. Report each as a rolling median over the last three sprints, because single-sprint numbers swing a lot. Use Q3 2026 onwards as the baseline, since earlier numbers come from a different codebase and process.

Metric	What it tells you
Cycle time: In Development to Completed, median and 85th percentile	How long building a change takes once someone starts. The 85th percentile shows stuck work.
Work in progress: issues in In Development and In Code Review	Whether the team is starting more than it finishes. Rising WIP usually comes before rising cycle time.
Time to first review, median and 85th percentile	Whether PRs wait for attention.
Release wait: Completed to closed, and the number of Completed-but-open issues	How long finished work waits before anyone can use it. Currently the largest part of lead time.
Net flow: issues opened minus issues closed, excluding sweeps	Whether the backlog is growing.
Backlog age: share of open issues older than six months	Whether the backlog is still a usable plan.
Quality: bugs raised and regressions per 100 merged PRs per release, bugs fixed in patches, and QA bounce-back rate	Whether speed is coming at the cost of defects, and how many escape into production.
Scope change: issues added to the release milestone after the cycle starts, and issues moved out	How stable the release plan is. Bugs found in QA and new features are worth tracking separately.
Context only: merged PRs per author, median PR size, share of PRs with an AI co-author	Helps explain changes in the others. Not targets; all of them shift with working habits and tools.

Changes that would make the numbers trustworthy

Move every issue through In Development on the board. Only about half of board issues do today, so cycle time covers that half.
Close stale issues as "Not planned" instead of "Completed", so sweeps stop counting as delivered work.
Set an issue type on every issue, so bug counts are complete. 22% of issues created in Q3 2026 and 333 open issues have none.
Link PRs to issues through the Development sidebar or "Closes #NNNN". About 37% of issues closed in 2025–26 are linked.

Metrics to avoid

Raw issue lead time (opened to closed) as an engineering speed measure. It is mostly release cadence and clean-up timing.
Total issues closed. One sweep can close 170 issues in an afternoon.

What this data can't show

Which project board a status change came from. The token can't read organisation projects, so status changes from several boards are mixed together. Most transitions follow one workflow (Backlog, Ready to build, In Development, In Code Review, Ready for release, Ready for QA, Completed).
Who closed about 1,300 issues since 2024. Their close events aren't visible to this token, most likely because an app closed them.
Effort or size of issues, work outside opencrvs-core (country config, farajaland, docs, infrastructure), and work before 2020, when only 79 issues were created here.