DEV Community: Vi Project Management

"Any Update?" We Read 2,398 GitHub Issues to See Who Gets an Answer

Vi Project Management — Mon, 26 Oct 2026 12:46:55 +0000

Every year, about 100,000 new GitHub issues get a comment asking "any update?". That is roughly 280 a day, and the number has stayed close to that level for ten years. We read 2,398 of these issues from 2025 to see what happens around the question. The typical person waited 38 days before asking. After they asked, 60% never got a reply from a maintainer, and only 23% got one within a week.

This is not an article about lazy maintainers. Most open source maintainers are volunteers, and silence on a public tracker usually means "no news yet", not "we don't care". It is about what the question itself tells you: someone is waiting, they can't see where things stand, and asking is the only tool they have.

How common is "any update?" on GitHub?

GitHub's issue search counts issues by the year they were opened. Here is how many issues from each year have at least one comment containing "any update":

2016: 89,935
2017: 68,689
2018: 80,176
2019: 87,583
2020: 100,988
2021: 96,068
2022: 95,286
2023: 105,994
2024: 105,021
2025: 102,495

That is about 5 to 9 issues in every 1,000. The rate for 2025 (5.3 per 1,000) is lower than for 2019 (9.0), but we would not read that as an improvement. Issues opened in 2025 have had less time to collect the question, and automated tools may be opening a larger share of new issues, which would make the total larger without adding people who wait.

Related phrasings add more. "Any updates" appears in about 422,000 issues across all years and "any news" in about 198,000, with some overlap.

Which languages hear it most?

For issues opened in 2025, grouped by the main language of the repository, per 1,000 issues:

Dart: 9.6
C++: 9.1
TypeScript: 8.9
C#: 8.6
Go: 8.4
PHP: 7.5
Swift: 6.5
Kotlin: 6.3
Python: 5.7
Rust: 5.7
JavaScript: 3.6
Java: 3.6

We don't have a good explanation for the spread. JavaScript and Java have a very large number of small personal and learning repositories, which probably lowers their rate. Treat this list as a description, not a ranking of communities.

How long do people wait before asking?

In our 2025 sample, the median person asked 38 days after the issue was opened. A quarter asked within 10 days, and a quarter waited more than 120 days.

The more telling number is the silence before the question. Counting from the last comment by a maintainer (or from the opening of the issue, if no maintainer had commented), the median gap was 31 days. People rarely ask "any update?" in the middle of an active conversation. They ask after a month of nothing.

Who asks?

Two out of three people who asked (68%) had not opened the issue themselves. They found an existing issue, recognised their own problem in it and joined the wait. So one silent issue usually has more than one person behind it, and most of them never say anything at all. They subscribe, or they leave.

82% of the people asking had no prior relationship with the repository: GitHub labels them "none", meaning they were not members and had never contributed code there.

Do they get an answer?

Of the 897 times someone other than a maintainer asked "any update?":

40% got a reply from a maintainer at some point afterwards
23% got that reply within 7 days, and 15% within a day
60% never got a maintainer reply after asking
21% had to ask two or more times, and one issue was asked seven times

When an answer did come, it often came fairly quickly: the median was 3.7 days, although a quarter of those replies took more than 45 days.

Two thirds of these issues (66%) are closed today. In a third of all cases (34%), the issue was closed without any maintainer reply after the question was asked. We did not check why each one was closed: some were probably fixed, some closed by a stale bot, some marked as duplicates. From the person's side, the result looks the same: they asked, and the next thing they saw was the issue closing.

The question shows up in large, well-run projects too. Among the repositories that appeared most often in our sample were FreeCAD, Prusa firmware, Home Assistant, Microsoft's VS Code and Office JS, Anthropic's Claude Code and Google's ADK.

Why does this matter outside open source?

On a public tracker, the person waiting is usually a user who isn't paying anyone. In a company, the person waiting is a customer, and the same pattern costs more.

The work is often going fine. A developer picked the request up, fixed it, a reviewer approved it. But the customer can't see any of that, so from where they sit, a month of quiet looks exactly like a month of nothing. Then they write "any update?", someone on the team stops what they are doing to find out where the task is, writes a reply, and goes back to work. Multiply that by every open request.

The data suggests that the fix is not "reply faster". Even projects that answer usually do it within a few days. What people are missing is visibility: a way to see where their request stands without having to ask.

What stops customers from asking?

Three things help, and none of them need a bigger support team:

Give every request a status link. The customer should be able to open one page and see whether their request is received, in progress or done, without logging in to your tools.
Send updates on events, not on a schedule. A message when work starts and a message when it is actually finished is better than a weekly "still working on it".
Send "done" only when it is really done. "Done" should mean the work passed review and reached the last step of your process, not that a developer pushed a first commit. Early "done" messages create the next "any update?".

This is what we built Vi to do. Customer requests come in by email or a client portal and become tasks. The team moves them through its own workflow, and developers finish their part from the IDE. When the request reaches the final step, the customer gets an email automatically, and they can check a status link at any point in between. We call this closing the loop, and you can see the full chain on our customer request to code page. The helpdesk features are part of Vi's Business plan; details are on the helpdesk page.

How we did this

Counts by year and language come from GitHub's issue search: issues opened in each period, with and without "any update" in:comments. Search counts are estimates and the language is the repository's main language.
The 2025 sample is up to 200 issues per month from the same search, 2,398 issues in total, read through the GitHub API on 24 October 2026. Pull requests were excluded.
GitHub search is broad: in 1,122 of the 2,398 issues we actually found a comment matching "any update", "any updates", "any news" or "any progress". The rest matched on word forms or text we did not count. We only used these 1,122.
We removed 225 cases where the question was written by a maintainer (for example, a maintainer asking a contributor), leaving 897 questions in 738 repositories.
A "maintainer" is anyone GitHub labels as owner, member or collaborator of the repository. Some projects have people who triage issues without that label, so the real reply rate may be somewhat higher than 40%.
The sample is drawn by creation date, not at random from all issues, so popular repositories can appear more than once. No repository makes up more than 2% of the sample.

The scripts and raw data are available on request.

Check your own repository

You can run the same measurement on any public GitHub repository with the free Any Update? Checker. It reads the 30 most recent issues with the question, uses the method above, and shows the result next to the study's numbers. It runs in your browser and needs no sign-up.

Originally published on the Vi blog.

FAQ

How many GitHub issues ask "any update?"

About 100,000 issues opened each year get at least one comment containing "any update", according to GitHub's search. The yearly number has been between roughly 69,000 and 106,000 since 2016.

How long do people wait before asking for an update?

In a sample of 897 questions on 2025 issues, the median wait was 38 days after the issue was opened, and the median silence from maintainers before the question was 31 days.

What share of "any update?" questions get answered?

40% got a reply from a maintainer after asking, and 23% within a week. The other 60% received no maintainer reply afterwards, and a third of all the issues were closed without one.

Does this mean open source maintainers are slow?

No. Most maintainers are volunteers with no obligation to reply, and a closed issue is often a fixed one. The point of the data is that people waiting on work can't see its status, so they ask, and a lot of those questions go unanswered.

How can a software team stop customers asking "any update?"

Give each request a status page the customer can open at any time, send updates when the work actually changes state, and only send "done" when the work has passed review and is finished. Tools that connect customer requests to the team's workflow, such as Vi, can do the notifications automatically.

What Is Git-Aware Project Management?

Vi Project Management — Wed, 15 Jul 2026 20:51:02 +0000

Software teams often plan work in one place and build software somewhere else.

Tasks live on a project board.

But the real work happens in the IDE, Git branches, commits, pushes, pull requests, and code changes.

That creates a gap.

A developer may finish the code, commit the changes, push the branch, and still forget to update the board. The project board may say “In Progress”, while the real development work is already done.

That is the problem Git-aware project management tries to solve.

What is Git-aware project management?

Git-aware project management means connecting project tracking with real development activity.

Instead of treating tasks as isolated cards on a board, the project management system stays connected to actions like:

commits
pushes
task completion
workflow updates
branch activity
development status from the IDE

The goal is simple:

Project status should reflect real development work, not only manual status updates.

Why traditional boards fall behind

Most project management tools depend on manual updates.

A developer works in the IDE, commits through Git, pushes changes, and then has to open a browser-based board to update the task.

That creates context switching.

It also means the board depends on someone remembering to update it.

For software teams, this can lead to:

outdated project boards
disconnected code and task progress
extra manual status updates
less accurate visibility for team leads and managers

The problem is not that developers are careless.

The problem is that project tracking is often separated from where development actually happens.

A better workflow

A Git-aware workflow connects the development flow to the project flow.

For example:

A developer works on a task in the IDE.
The task stays connected to the Git work.
The developer commits and pushes changes.
The task can be closed from the development environment.
The project board updates automatically.

This reduces the need to jump between the IDE, terminal, Git, and browser just to keep the board updated.

Git-aware does not mean reading all source code

A Git-aware project management tool does not need to inspect or store a team’s source code by default.

For many teams, the useful part is the connection between the task and development metadata:

which task was completed
which commit or push was related to it
when the workflow moved forward
whether the board is still in sync with the real work

Teams should stay in control of how much code context appears on the board.

Why I am building Vi

I’m building Vi, a Git-aware project management tool for software teams.

The idea is to help developers complete tasks directly from the IDE, while commits, pushes, task completion, and board updates stay connected.

The core idea is:

Developers stay in the IDE.

Git activity stays connected to the task.

The board updates automatically.

Project management should not depend on developers remembering to update the board manually.

It should stay in sync with the real work.

I wrote the full article here:

https://useviapp.com/what-is-git-aware-project-management

I’d love feedback from software teams:

Does your project board usually reflect real development work, or does it fall behind?

Originally published here:
https://useviapp.com/what-is-git-aware-project-management