App-Design für einen Code-Review-Posteingang

Struktur des Code-Review-Posteingangs

Dieses Desktop-App-Design zeigt einen GitHub-Posteingang für Review-Anfragen und Erwähnungen als vertikal geordneten Arbeitsbereich. Eine linke Leiste beginnt mit „All 5“, gefolgt von „Participating“, „Mentions“ und „Review requests 2“. Die Hauptspalte gruppiert die Arbeit dann in Review-Anfragen, CI-Checks, zugewiesene Issues und Aktivitäten. Diese Abfolge macht aus mehreren Engineering-Signalen einen einzigen Scan-Pfad, während die getrennten Kategorien genug Kontext bewahren, um zu entscheiden, was zuerst Aufmerksamkeit braucht.

Eine Review-Anfrage als Beleg

Der erste Review-Eintrag nennt open-design/web PR #2371, trägt den Titel „feat: orbit briefing card“ und zeigt „3 of 5 reviewers approved · waiting on you + cody“. Darunter führt der Dateipfad „src/components/OrbitBriefingCard.tsx“ zu einem kompakten Diff mit entfernten und hinzugefügten Zeilen. Diese Kombination lässt Reviewer den Freigabestatus mit einer konkreten Änderung verbinden. Der Kompromiss ist die vertikale Dichte: Der Code-Auszug liefert nützlichen Kontext, macht den ersten Eintrag aber deutlich höher als die zweite Anfrage.

Anwendungsfälle der Engineering-Triage

Das Design unterstützt mehrere unterschiedliche Aufgaben, ohne so zu tun, als wären sie dieselbe Art von Arbeit. Review-Anfragen verlangen eine Antwort oder Freigabe, CI-Checks melden einen fehlgeschlagenen Prüfzustand, zugewiesene Issues stehen für eigene Backlog-Arbeit, und Aktivitäten dokumentieren eine abgeschlossene Änderung. Getrennte Bereiche machen die Aufgabengrenzen sichtbar. Der Kompromiss: Zusammengehörige Signale bleiben über die Seite verteilt, statt zu einem universellen Wert verdichtet zu werden.

Lesefluss im Arbeitsbereich

Der Arbeitsbereich nutzt eine breite Hauptspalte und eine kompakte Navigationsleiste statt gleich großer Dashboard-Kacheln. Das ausgelieferte CSS setzt eine maximale Seitenbreite von 1280px, und das sichtbare Layout gibt den Ereignisbereichen den Großteil der horizontalen Fläche. Diese Proportion trägt lange Repository-Namen, Pull-Request-Titel, Zeitstempel und Codezeilen, ohne jeden Eintrag in eine eigene Kartenspalte zu zwingen. Der Preis ist ein langer vertikaler Scan, besonders wenn die Review-Anfrage ihren eingebetteten Diff enthält.

Vom Filter zum Detail

Das Suchfeld oben zeigt Type / to search, hat aber keinen Such-Handler. Die Seitenleistenfilter funktionieren dagegen auf den mitgelieferten lokalen Gruppen: Participating zeigt Review-Anfragen und zugewiesene Issues, Review requests zeigt die Review-Gruppe, und Mentions zeigt nur die Gruppe mit der Erwähnungsmarkierung der Quelle. Diese Markierung hängt an den zugewiesenen Issues und nicht an der Review-Zeile mit Antwortbedarf. Die Filterung ist lokales Darstellungsverhalten, keine verbundene GitHub-Suche und kein Posteingangsdienst.

Zustandswechsel durch Farbe

Farbe trägt den Zustand über sonst ähnliche Zeilen hinweg. Grün kennzeichnet offene oder gesund wirkende Repository-Zustände, Gelb Arbeit, die auf eine Antwort wartet, Rot den fehlgeschlagenen Test und Violett den gemergten Aktivitätseintrag. Die Issue-Labels nutzen getrennte blaue und rosa Pills für „backend“ und „p1“. Das beschleunigt das Scannen gegenüber dem Lesen jedes Satzes, doch Farbe bleibt ergänzend: Jeder Zustand steht zusätzlich als Text da, sodass die Bedeutung erhalten bleibt, wenn Farbe allein nicht genügt.

Funktionsgrenze

Die Quelle implementiert lokales Kategoriefiltern und erzeugt ausgehende GitHub-Links für Zeilen und Titel. Diese Links zeigen auf ein festes Repository und verwenden die angezeigten Beispielkennungen; ihre Existenz bestätigt weder die dargestellten Pull Requests noch Issues oder CI-Ergebnisse. Suche, authentifizierter Abruf des Posteingangs, persistenter Review-Status und echte Testausführung sind nicht implementiert. Namen, Zahlen, Zeitstempel, Freigabestatus und Code-Auszüge bleiben illustrative Inhalte für das Designszenario.