Merge-Reviews ohne Ping-Hölle: Wie Draft-Notes die GitLab VS Code Extension besser machen

Kontext: „Improving Merge Reviews“ mit Timo Keber (SEQIS Group GmbH)

In „Improving Merge Reviews“ von Timo Keber (SEQIS Group GmbH) geht es um ein sehr konkretes, aber im Alltag spürbares Problem: Die GitLab VS Code Extension bildet nicht alle Review-Funktionen der GitLab-Weboberfläche ab. Konkret fehlen Draft-Notes und Batch-Reviews – zwei Bausteine, die aus Sicht vieler Entwicklerinnen und Entwickler entscheidend sind, um Merge-Requests effizient, konzentriert und ohne Benachrichtigungs-Spam („Ping-Hölle“) zu bearbeiten.

Wir haben die Session genau verfolgt, weil sie exemplarisch zeigt, wie Open-Source-Contributions in komplexen Produktökosystemen funktionieren – und wo es hakt. Keber führt uns von der Problemwahrnehmung über die Architektur der Extension bis zu den ersten Implementierungsschritten. Sein Ziel: Feature-Parität zwischen Browser-UI und VS Code, sodass Reviews dort stattfinden können, wo die meiste Entwicklungszeit verbracht wird – in der IDE.

Warum Draft-Notes in der IDE wichtig sind

Wer GitLab im Browser nutzt, kennt das Prinzip: Während eines Reviews lassen sich Kommentare als Draft (unveröffentlicht) vormerken und am Ende gesammelt veröffentlichen. Das verbessert drei Dinge:

• Fokus: Man bleibt im Review-Flow, statt ständig kontextzuwandern zwischen Kommentieren und Senden.
• Signal statt Rauschen: Ein gebündelter Review erzeugt eine Benachrichtigung – nicht zehn.
• Qualität: Man sieht das Gesamtbild, bevor man die Anmerkungen finalisiert, und vermeidet damit inkonsistente Rückmeldungen.

In der GitLab VS Code Extension fehlt genau dieses Verhalten: Kommentare werden sofort veröffentlicht, wodurch pro Kommentar eine E-Mail/Notification fällig wird. Das hat zwei unmittelbare Konsequenzen, die Keber klar benennt:

• Es entsteht Benachrichtigungs-Spam – die „Ping-Hölle“, die dazu verleitet, Notifications abzuschalten.
• Es fehlt die Batch-Veröffentlichung. Wer konzentriert in VS Code reviewt, muss für Drafting/Batching wieder auf die Web-UI wechseln.

Aus unserer Sicht ist das ein Paradebeispiel für „Feature-Parity als Developer Experience“: Die IDE-Experience sollte nicht nur „ungefähr“ das Browser-Verhalten nachempfinden, sondern in den kritischen Workflows deckungsgleich funktionieren.

Architekturüberblick: Wie die GitLab VS Code Extension denkt

Keber fasst die Architektur so zusammen, dass sie auch für Extension-Neulinge greifbar bleibt. Wichtig sind vier Bausteine:

1) Extension Host und TypeScript-Code

• Die GitLab-Extension ist in TypeScript geschrieben und bindet sowohl die VS Code API als auch die GitLab API an.
• Der Extension Host stellt die Debugging- und Laufzeitumgebung für die Entwicklung bereit.

2) WebViews (mit Vue)

• Der UI-Teil (z. B. die Merge-Request-Ansicht) wird in einer WebView gerendert.
• Die GitLab-Extension nutzt dafür Vue, um Inhalte darzustellen und Benutzerinteraktionen aufzunehmen.

3) Issuable Controller

• GitLab fasst Merge Requests als „Issuable“ zusammen. Die Extension implementiert dafür Issuable Controller.
• Diese Controller vermitteln zwischen WebView und Extension-Code – und publizieren wiederum Richtung GitLab API.

4) GitLab Service und API-Schicht

• Der GitLab Service übernimmt das Senden/Empfangen in Richtung GitLab API.
• Heute sind Kommentare in der Extension stark auf GraphQL ausgerichtet. Draft-Notes in GitLab hingegen laufen über einen separaten REST-Endpunkt.

Daraus ergibt sich der zentrale Architekturpunkt, den Keber adressiert: Die Extension muss WebView-Interaktionen und lokale Zustände so strukturieren, dass sowohl GraphQL-Kommentare als auch REST-basierte Draft-Notes konsistent erzeugt, angezeigt und später zusammengeführt werden können.

Das Problem unter der Haube: GraphQL und REST kollidieren

Wie so oft steckt die Komplexität nicht in der UI, sondern in den Details der Daten- und API-Flows. Keber benennt zwei Friktionen:

• Unterschiedliche APIs: „Normale“ Kommentare werden per GraphQL abgewickelt, Draft-Notes jedoch via REST. Felder, Mutations, Rückgabestrukturen – all das ist unterschiedlich.
• Tightly Coupled Code: Die Extension ist heute eng auf GraphQL-Kommentarobjekte zugeschnitten. Es gibt keine abstrahierte Trennung, die Draft-Notes (REST) einfach danebenstellen würde.

Er zeigt es an einem Service-Beispiel: Der CreateNode-Weg ist voller GraphQL-spezifischer Logik – von alten und neuen Mutations bis zu Ergebnisprüfungen. Für Draft-Notes gibt es dagegen „nur“ einen REST-Endpoint mit einem Body. Was trivial klingt, passt im bestehenden Code jedoch nicht gut zusammen. Es braucht also einen Brückencode, der beide Welten zusammenführt und den Comment-Flow für die WebView abstrahiert.

Kommunikationsfluss: WebView ↔ Extension ↔ GitLab

Für Draft-Notes reicht ein reiner Downstream („WebView schickt, Extension sendet an GitLab“) nicht. Keber baut daher eine wirklich bidirektionale Kommunikation auf:

• WebView → Extension: Nutzeraktionen (z. B. „Start Review“, Kommentar als Draft vormerken) werden an den Issuable Controller geschickt.
• Extension → WebView: Der Controller rendert aktualisierte Zustände zurück in die WebView. Dazu injiziert Keber Feature-Flags direkt ins HTML, damit die WebView den Kontext kennt und richtig reagiert.

Diese bidirektionale Schicht ist essenziell, weil Drafting nicht nur ein „Senden“-Problem ist, sondern ein Sichtbarkeits- und State-Problem: Nutzer müssen sehen, welche Kommentare Drafts sind, welche veröffentlicht wurden und was zur Veröffentlichung ansteht. Ohne sauberen Ping-Pong zwischen WebView und Extension bleibt das UI inkonsistent.

State-Persistence: Der lokale Speicher als Sicherheitsnetz

Ein weiterer Baustein ist Kebers Idee eines State-Persistence-Layers: Unveröffentlichte Draft-Notes werden lokal persistiert. Das klingt banal, ist in einer VS Code Extension aber entscheidend:

• Schutz vor Datenverlust: Entweder weil der Extension Host neu startet, ein Reload passiert oder Netzwerkprobleme auftreten.
• Grundlage für Batch-Veröffentlichung: Der „Warenkorb“ der Review-Kommentare muss zuverlässig wiederhergestellt werden.

In der Demo-Phase ist das Konzept noch nicht bis zum Ende umgesetzt, aber seine Rolle ist klar: Ohne lokalen Entwurfsspeicher wird Batch-Review schnell fragil.

UX und Maintainer-Feedback: Tempo rausnehmen, Klarheit schaffen

Keber berichtet, dass er schnell konstruktives Feedback von den Maintainerinnen und Maintainern erhalten hat – inklusive der Ansage, bei UX-Fragen das Tempo zu drosseln. Das ist typisch für produktnahe Open-Source-Projekte: Eine Extension, die viele Teams täglich nutzen, kann keine halbfertige UX-Experimente ausrollen. Die Richtung stimmt – Draft-Notes und Batch Reviews sind ein echtes Bedürfnis – aber die Umsetzung muss langlebig und konsistent sein.

Für Contributor heißt das: Architektur und API-Design zuerst stabilisieren, dann UI-Feinschliff. Und genau so geht Keber vor.

Die Demo: „Start Review“ und erste Draft-Notes in VS Code

Im praktischen Teil zeigt Keber die Extension im Live-Build sowie im Extension-Host (Debug-Session). Spannend sind zwei Punkte:

• „Start Review“-Button: Eine neue, bewusst unspektakuläre UI-Aktion, die sich an der Web-UI orientiert. Sie schaltet in den Draft-Modus.
• Draft-Note-Posting: Aus der WebView heraus wird eine Nachricht an den Issuable Controller gesendet, der wiederum den REST-Endpoint für Draft-Notes anspricht.

Was heute schon geht:

• Normale Kommentare wie gehabt erzeugen (GraphQL-Weg).
• Draft-Notes erstellen, sobald „Start Review“ aktiv ist.
• Draft-Notes veröffentlichen – aktuell über einen VS Code Befehl, noch ohne dedizierten UI-Button.

Noch offen:

• Visuelle Unterscheidung von Drafts vs. veröffentlichten Kommentaren in der Extension-Ansicht.
• Vollständiges CRUD für Draft-Notes (Keber sagt: „CRUD ohne D“, teils auch ohne Update – also kein vollständiges Löschen/Updaten).
• Batch-Veröffentlichung als flüssiger, sichtbarer Flow in der UI (nicht nur als Command verfügbar).

Technische Knackpunkte im Detail

1) Typ-Unions für REST- und GraphQL-Nodes

Kebers Lösungsrichtung: Eine Typ-Union, die REST-Draft-Notes und GraphQL-Kommentare unter einem gemeinsamen Dach zusammenführt. Damit kann die WebView mit einem konsistenten Kommentarmodell arbeiten, während der Issuable Controller intern die Unterschiede handhabt.

• Vorteil: UI- und View-Logik werden einfacher; die Quelle (REST vs. GraphQL) ist ein Implementierungsdetail.
• Herausforderung: Mappings für Felder, IDs, Status (Draft vs. veröffentlicht) und Übergänge („Publish“) müssen sauber definiert werden.

2) Feature-Flags in der WebView

Um die WebView kontextsensitiv zu steuern, injiziert Keber Feature-Flags in das HTML. So kann das Vue-Frontend wissen, ob Drafting in der aktuellen MR aktiv ist und welche Aktionen erlaubt sind.

• Vorteil: Kein harter Coupling an Extension-internen Zustände, stattdessen deklarative Schalter.
• Herausforderung: Synchronität und Korrektheit beim Wechseln von MRs und beim Refresh der WebView.

3) API-Brücke im GitLab Service

Der bestehende CreateNode-Pfad im GitLab Service ist GraphQL-getrieben. Für Drafts wird zusätzlich ein REST-Aufruf gebraucht. Das heißt:

• Doppelte Pfade: REST für Draft, GraphQL für Regular.
• Einheitliche Fehlerbehandlung: Beide Pfade müssen konsistent auf Erfolg/Fehler reagieren und den UI-State korrekt updaten.
• Migrationsfähigkeit: Falls GitLab die API in Zukunft ändert (z. B. Drafts auch in GraphQL anbietet), sollte die Abstraktion das verkraften.

4) Bidirektionale Events zwischen WebView und Extension

Die WebView muss nicht nur „Sende Draft“ können, sondern auch neue Zustände empfangen: Welche Drafts liegen an? Wurde veröffentlicht? Gibt es Server-Feedback? Ohne diese Rückkanäle bleibt die UI stumm.

• Typische Events: Draft erstellt, Draft gespeichert, Draft veröffentlicht, Fehler beim Veröffentlichen, Refresh nötig.
• Implementation Hint: Eine schlanke, dokumentierte Message-Schnittstelle reduziert Koppelung und macht die Integration testbar.

„Ping-Hölle“ konkret: Warum ungefilterte Benachrichtigungen schaden

Keber benennt sehr deutlich, was in der Praxis passiert, wenn jede einzelne Anmerkung aus der IDE eine E-Mail triggert:

• Reviewer und Autorinnen verlieren den Überblick; wichtige Nachrichten gehen im Rauschen unter.
• Teams schalten Notifications ab – mit dem Nebeneffekt, dass kritische Hinweise verspätet ankommen.
• Der Review-Flow wird mechanisch: Alle 30 Sekunden poppt die nächste Nachricht auf, statt dass ein sauber kuratierter Review erscheint.

Draft-Notes und Batch-Reviews sind hier kein „Nice-to-have“, sondern ein Workflow-Guardrail: Sie schützen die Aufmerksamkeit aller Beteiligten und fördern bessere, konsistentere Reviews.

Was wir gelernt haben: Praktische Einsichten für Engineers

Aus der Session lassen sich klare Lernpunkte ableiten, die über den konkreten GitLab-Fall hinausgehen:

• Feature-Parität ist kein Luxus: Wer IDE-Workflows anbietet, muss die kritischen UX-Pfade der Web-UI wirklich treffen. Sonst entsteht Zwang zum Kontextwechsel.
• API-Dualität früh adressieren: Wenn eine Plattform ähnliche Entitäten über unterschiedliche APIs anbietet (GraphQL vs. REST), braucht es eine stabile, interne Abstraktion – möglichst bevor die UI wächst.
• Bidirektionale Kommunikation denken: WebViews in VS Code sind eigenständige Frontends. Ohne saubere Ereignis- und Statuskanäle entstehen UI-Geisterzustände.
• Lokale Persistenz einplanen: Drafting ohne verlässlichen Entwurfsspeicher ist riskant. Persistenz ist kein Nachtrag, sondern Teil des Kern-Designs.
• Schrittweise liefern: „Baby-Steps“ sind nicht nur gut für die Code-Stabilität, sondern auch für Review und Maintainer-Feedback.

Nächste Schritte: Was bis zur echten Parität fehlt

Keber skizziert offen, was noch ansteht, bevor die Erweiterung wirklich „Draft-ready“ ist:

• Sichtbarkeit in der MR-View: Drafts müssen klar als solche erkennbar sein – idealerweise mit denselben visuellen Mustern wie in der Web-UI.
• Komplettes Draft-CRUD: Nicht nur Erstellen, sondern auch Aktualisieren und Löschen, inklusive sicherer Fehlerpfade.
• Publish-Flow im UI: Ein Button und ein klarer Statuswechsel (pending → veröffentlicht), nicht nur ein VS Code Befehl.
• Typ-Union etablieren: Das gemeinsame Kommentarmodell braucht saubere Semantik und sollte in allen relevanten Teilen der Extension durchgängig sein.

Wenn diese Bausteine stehen, wird die Extension für viele Teams deutlich alltagstauglicher – gerade für Kolleginnen und Kollegen, die Reviews konsequent in VS Code abbilden möchten.

Entwicklungsrealität: Debugging, Breakpoints, Iteration

In der Live-Demo erlebt man auch die Entwicklungsrealität: Breakpoints, die zur Unzeit stoppen, ein Command, der beim ersten Versuch nicht feuert – nichts Außergewöhnliches, aber ein Hinweis darauf, dass wir es hier mit laufender, echter Arbeit zu tun haben. Die Richtung stimmt, die Meilensteine sind greifbar.

Fazit: Kleine Brücke, großer Effekt

„Improving Merge Reviews“ von Timo Keber (SEQIS Group GmbH) macht deutlich, wie viel Wirkung ein vermeintlich kleines Feature haben kann. Draft-Notes sind kein kosmetisches Extra, sondern ein Hebel gegen Benachrichtigungsstress und für konzentrierte, hochwertige Reviews. Die technische Herausforderung – GraphQL und REST sauber zu verbinden, bidirektionale Events zu etablieren und einen robusten lokalen State einzuziehen – ist real. Aber der Nutzen rechtfertigt die Mühe.

Für uns als Zuhörerinnen und Zuhörer bleiben drei Sätze hängen:

• Reviews gehören dorthin, wo Entwicklung stattfindet – in die IDE.
• Feature-Parität ist ein Qualitätsversprechen, kein Marketingwort.
• Iteratives Liefern, frühes Maintainer-Feedback und saubere Abstraktionen sind die Zutaten, mit denen man komplexe Extensions stabil erweitert.

Praktische Takeaways für deine Arbeit

• Wenn du eine VS Code Extension baust, behandle die WebView wie ein eigenes Frontend mit klarer Message-Schnittstelle. Nur so gelingt echte Bidirektionalität.
• Plane eine interne Typ-Union, wenn du Entitäten aus unterschiedlichen APIs zusammenführen musst. Entkopple UI von API-Spezifika.
• Setze auf lokalen Entwurfsspeicher, wenn Nutzer Entitäten „zwischenparken“ (Draft) wollen. Es schützt vor Datenverlust und erleichtert Batch-Operationen.
• Mache Batch-Aktionen sichtbar und steuerbar: Ein klarer Publish-Button ist mehr als Komfort – er ist ein UX-Vertrauensanker.
• Hole früh UX-Feedback ab. Besonders in Tools, die täglich im Einsatz sind, zahlt sich geduldiges Feinschleifen aus.

Ausblick

Die vorgestellten Schritte bringen Draft-Notes in greifbare Nähe. Sobald visuelle Unterscheidung, vollständiges CRUD und ein durchgängiger Publish-Flow in der UI vorhanden sind, wird die GitLab VS Code Extension ein deutlich runderes Review-Erlebnis liefern. Die „Ping-Hölle“ weicht dann einem ruhigen, planbaren Review-Takt – genau das, was produktive Teams brauchen.

Und bis dahin gilt: Baby-Steps, saubere Abstraktionen und ein Blick auf das, was die GitLab-Weboberfläche bereits gut gelöst hat. So entsteht echte Feature-Parität – und damit bessere Merge-Reviews direkt in VS Code.

• 

  

  JavaScript and (Non) Blocking UI

  Klemens Loschy von SEQIS fokusiert sich in seinem devjobs.at TechTalk "JavaScript and (Non) Blocking UI" auf eine Problemstellung aus dem Gebiet der eventloops in JavaScript und demonstriert einen Lösungsweg.

  Jetzt ansehen
• 

  

  Atlassian Forge Custom UI Testing und Asynchronität

  Daniel Kleißl von SEQIS spricht in seinem devjobs.at TechTalk über eine Eigenheit von Forge beim UI Testing und zeigt in einer Live Demo, wie das Team dieses Problem gelöst hat.

  Jetzt ansehen

• 

  

  Alexander Weichselberger, Managing Partner von SEQIS

  Der Managing Partner von SEQIS Alexander Weichselberger spricht im Interview über die Kerngedanken des Unternehmens, aktuelle Projekte, den Bewerbungsprozess und warum der Blick über den Tellerrand auch wichtig ist.

  Jetzt ansehen

• 

  

  Markus Schwabeneder, Senior Agile Architect bei SEQIS

  Markus Schwabeneder von SEQIS erzählt im Interview über seine frühen Anfänge mit dem Programmieren, wie er dann über Umwege zu seiner aktuellen Arbeit gekommen ist und gibt Tipps für Anfänger.

  Jetzt ansehen