Kostenloses Tool

Any Update? Checker

Wie lange warten Menschen bei einem GitHub-Repository, bevor sie „any update?“ fragen, und wie oft bekommen sie eine Antwort? Geben Sie ein beliebiges öffentliches Repository ein und sehen Sie selbst.

Probieren Sie:

So funktioniert es

  1. Der Checker fragt die öffentliche API von GitHub, wie viele Issues das Repository hat und wie viele davon einen Kommentar mit „any update“ enthalten.
  2. Dann liest er die Kommentare der 50 neuesten dieser Issues und findet in jedem die erste Frage „any update?“, „any news?“ oder „any progress?“; Fragen der Maintainer selbst werden übersprungen.
  3. Für jede Frage misst er, wie viele Tage seit dem Öffnen des Issues vergangen waren und ob ein Maintainer (Owner, Member oder Collaborator) danach geantwortet hat. Das Ergebnis für jedes Repository wird 24 Stunden gespeichert, eine erneute Prüfung geht also sofort.

Was die Zahlen bedeuten

„Any update?“ schreiben Menschen, wenn sie nicht sehen können, wo etwas steht. In unserer Studie mit 897 solcher Fragen in GitHub-Issues aus 2025 warteten die Menschen im Median 38 Tage, bevor sie fragten, und 60 % erhielten danach keine Antwort von einem Maintainer.

Ein langsameres oder ruhigeres Repository ist kein schlechteres. Wenn ein Projekt aber weniger solcher Fragen möchte, lautet die übliche Antwort: Fortschritt sichtbar machen — Pull Requests mit Issues verknüpfen, Labels wie „planned“ oder „in progress“ verwenden und eine kurze Notiz hinterlassen, wenn sich Pläne ändern.

Die vollständige Studie lesen

Beliebte Repositories, monatlich geprüft

Wir führen dieselbe Prüfung einmal im Monat für 20 bekannte Open-Source-Projekte durch. Die Zahlen beschreiben, wie sichtbar der Fortschritt für Menschen ist, die auf Issues warten, nicht wie gut ein Projekt ist oder wie hart seine Maintainer arbeiten. Klicken Sie auf ein Repository, um das vollständige Ergebnis zu sehen.

Repository Hauptsprache Median der Wartezeit vor der Frage (Tage) Keine Antwort eines Maintainers Sterne
react/reactJavaScript12884 %252.540
microsoft/vscodeTypeScript1482 %195.399
flutter/flutterDart2196 %181.272
vercel/next.jsJavaScript3468 %143.488
golang/goGo26100 %139.901
kubernetes/kubernetesGo2462 %129.074
nodejs/nodeJavaScript7533 %123.730
rust-lang/rustRust12737 %121.948
godotengine/godotC++5854 %120.215
supabase/supabaseTypeScript2443 %115.051
microsoft/TypeScriptGo5353 %111.820
angular/angularTypeScript8573 %101.481
home-assistant/corePython1580 %92.266
elastic/elasticsearchJava3567 %78.692
grafana/grafanaTypeScript2995 %77.896
hashicorp/terraformGo2892 %50.244
docker/composeGo10888 %38.849
dotnet/runtimeC#3940 %18.441
n8n-io/n8nTypeScript——210.431
pytorch/pytorchPython——105.472

Zuletzt aktualisiert:

Bei welchen Sprachen „any update?“ am häufigsten vorkommt

In unserer Studie erhielten Issues in Dart-, C++- und TypeScript-Repositories mehr als doppelt so oft einen „any update?“-Kommentar wie Issues in JavaScript- und Java-Repositories. Das sagt vermutlich mehr über die Art des Projekts als über die Sprache aus: SDKs, Frameworks und Apps mit vielen Endnutzern hören die Frage häufiger.

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

In 2025 geöffnete Issues, gruppiert nach der Hauptsprache des Repositories: „any update?“-Kommentare pro 1.000 Issues. Die vollständige Studie lesen

Wie man „any update?“-Fragen reduziert

Menschen fragen „any update?“, wenn sie nicht sehen können, wo ihr Issue steht. Ein paar Gewohnheiten machen die Antwort sichtbar, bevor jemand fragen muss:

  1. Sagen Sie, wie es weitergeht, sobald ein Issue gesichtet ist: geplant, braucht mehr Informationen oder nicht geplant. Ein Label genügt.
  2. Verknüpfen Sie Pull Requests und Commits mit dem Issue, damit der Fortschritt direkt im Issue sichtbar wird.
  3. Wenn sich Pläne ändern oder die Arbeit stockt, hinterlassen Sie eine kurze Notiz. „Nicht in diesem Release“ ist eine Antwort; Schweigen nicht.
  4. Close the Loop: Wenn die Korrektur ausgeliefert wird, sagen Sie es der Person, die gefragt hat, und nennen Sie die Version, in der sie enthalten ist.

Fragen

Was misst der Any Update? Checker?

Er misst, wie oft Menschen in den Issues eines GitHub-Repositorys „any update?“ fragen, wie lange sie vorher gewartet haben, wie oft ein Maintainer danach geantwortet hat und wie oft Menschen mehr als einmal fragen mussten.

Verwendet er dieselbe Methode wie die Studie?

Ja. Er zählt Kommentare mit „any update“, „any updates“, „any news“ oder „any progress“, ignoriert Fragen von Maintainern und behandelt die GitHub-Rollen Owner, Member und Collaborator als Maintainer. Personen, die Issues ohne eine dieser Rollen sichten, zählen nicht als Maintainer, daher kann die angezeigte Antwortquote etwas niedriger sein als die tatsächliche.

Warum liest er nur die 50 neuesten Issues?

Jedes Issue eines großen Repositorys zu lesen, würde Minuten dauern. Die 50 neuesten Issues mit der Frage geben ein faires Bild davon, wie das Projekt heute damit umgeht. Bei großen Repositories sind die Zahlen eine Schätzung, keine vollständige Zählung.

Was wird gespeichert?

Das Ergebnis für jedes Repository wird 24 Stunden auf unserem Server gespeichert, eine erneute Prüfung geht also sofort. Ihre IP-Adresse wird nur verwendet, um das Limit von 5 Repositories pro Stunde durchzusetzen.

Funktioniert er mit privaten Repositories?

Nein. Er liest nur öffentliche Daten von GitHub, daher werden private Repositories als nicht gefunden angezeigt.

Genug von „any update?“-Kommentaren?

Verbinden Sie Ihre GitHub-Repositories mit Vi. Neue Issues landen in der Warteschlange Ihres Teams, werden zu Aufgaben, wenn Sie sie annehmen, und die Person, die das Issue geöffnet hat, erhält einen Kommentar, wenn die Arbeit erledigt ist — ohne fragen zu müssen.

GitHub-Issue Aufgabe in Vi Automatisches Update im Issue