GSoC 2026: Pull-Requests, Code-Ablehnung und der Weg zu sauberer Software

Die zweite Woche meines Google Summer of Code (GSoC) 2026-Projekts bei CircuitVerse brachte eine harte Lektion: Code zu schreiben, ist nur die halbe Miete. Die andere Hälfte besteht darin, diesen Code so zu gestalten, dass er von den Projektverantwortlichen akzeptiert wird – und das war alles andere als einfach.

Es gab abgelehnte Pull Requests, schmerzhafte Review-Kommentare und einen frustrierenden Kampf mit einem harmlosen Zwei-Buchstaben-Wort in Ruby. Doch am Ende stand ein bereinigter, geprüfter und eingereichter Codebeitrag, der die Grundlage für die LTI 1.3-Integration zwischen CircuitVerse und Canvas bildet. Hier ist die Geschichte dahinter.

CircuitVerse und Canvas: Warum LTI 1.3 der Standard sein muss

CircuitVerse ist eine Open-Source-Plattform, die es Studierenden ermöglicht, digitale Schaltkreise direkt im Browser zu entwerfen und zu simulieren. Das aktuelle Projekt zielt darauf ab, CircuitVerse nahtlos mit Canvas zu verbinden – einem der weltweit am häufigsten genutzten Learning Management Systems (LMS) an Hochschulen.

Die Technologie, die diese Verbindung ermöglicht, heißt LTI (Learning Tools Interoperability). Stellen Sie sich LTI wie einen universellen Stecker vor, der es Bildungs-Tools wie CircuitVerse erlaubt, sich in jedes LMS wie Canvas einzufügen. So können Studierende sich einmal anmelden, Aufgaben bearbeiten, ihre Arbeiten einreichen und ihre Noten automatisch zurück an Canvas übermitteln – ganz ohne die Kursseite zu verlassen.

Es gibt zwei Versionen von LTI:

• LTI 1.1: Älter, mit einer einfacheren (aber unsicheren) Authentifizierungsmethode namens OAuth 1.0.
• LTI 1.3: Der moderne Standard, der von Canvas empfohlen wird und eine robustere Sicherheit bietet.

Meine Aufgabe ist es, CircuitVerse vollständig auf LTI 1.3 umzustellen – ein komplexer, aber notwendiger Schritt, um die Kompatibilität und Sicherheit zu gewährleisten.

Montag–Dienstag: Warum ein einfacher Fix zu einem Albtraum wurde

Zu Beginn der Woche reichte ich einen Pull Request ein, der einen Bug in der bestehenden LTI 1.1-Grading-Funktion von CircuitVerse beheben sollte. Die Funktion sorgt dafür, dass CircuitVerse die Punkte eines Studierenden nach Abschluss einer Aufgabe automatisch an Canvas zurückmeldet.

Doch mein PR wurde von einem Reviewer kritisch unter die Lupe genommen. Zwei Kommentare trafen mich wie ein Schlag:

• „Es scheint, als wäre das gesamte Schema sortiert. Dieses Problem wurde upstream behoben.“

Was das bedeutet: Ich hatte unbewusst eine riesige, irrelevante Änderung in der Datei schema.rb vorgenommen – einer Datei, die die Struktur der CircuitVerse-Datenbank beschreibt. Als ich auf meinem Rechner einen Befehl ausführte, um diese Datei neu zu generieren, hatte Rails (das Framework, auf dem CircuitVerse basiert) automatisch alle Datenbankspalten alphabetisch sortiert. Das Ergebnis? Ein Diff mit Hunderten von geänderten Zeilen, die mit meinem eigentlichen Fix nichts zu tun hatten. Der Reviewer hatte es sofort erkannt.

• „Hier wird die Gem-Version zurückgestuft.“

Noch schlimmer: Ich hatte versehentlich eine Sicherheitsaktualisierung rückgängig gemacht. CircuitVerse nutzt die Bibliothek jwt (JSON Web Tokens), die kürzlich von Version 2.x auf 3.x aktualisiert worden war. Mein Branch hatte die Version ungewollt zurückgesetzt, weil eine andere Bibliothek (webpush, genutzt für Browser-Benachrichtigungen) nicht mit jwt 3.x kompatibel war. Das hatte eine Kettenreaktion ausgelöst, die ich nicht bemerkt hatte.

Die Lösung: Ich musste die Änderungen im schema.rb rückgängig machen, jwt wieder auf Version 3.2.0 hochstufen und webpush auf eine kompatible Version zurücksetzen. Drei Dateien. Sorgfältige Git-Operationen. Ein neuer Commit. Und schließlich der erneute Push des korrigierten Pull Requests.

Diese Erfahrung hat mir eine wertvolle Lektion vermittelt: Prüfen Sie immer Ihr Diff, bevor Sie einen Pull Request öffnen. Ein Diff zeigt alle Änderungen im Vergleich zum Hauptzweig. Wenn etwas Unerwartetes auftaucht, sollte es überprüft werden.

Mittwoch: Der Pull Request, den ich schließen musste

Nach den Korrekturen und dem erneuten Einreichen des Pull Requests kam eine ernüchternde Nachricht: Der PR musste geschlossen werden. Der Grund? Die von mir entwickelte Gradings-Funktion basierte auf der veralteten Bibliothek ims-lti, die LTI 1.1 mit OAuth 1.0 nutzt. Doch mehrere andere Dateien im Projekt hingen von derselben Bibliothek ab – und eine Änderung hätte an unerwarteten Stellen zu Fehlern geführt.

Es fühlte sich frustrierend an, aber mein Mentor gab mir einen wichtigen Hinweis: Bevor ich die Gradings-Funktion anpasse, muss ich zunächst die zugrundeliegende Bibliothek aktualisieren. Das bedeutete, ims-lti durch eine moderne Alternative zu ersetzen, die LTI 1.3 unterstützt.

Mittwoch–Donnerstag: Code-Review als Lernchance

In der Zwischenzeit wurde ich gebeten, einen anderen Pull Request zu prüfen – einen automatisierten Vorschlag von Dependabot, der die Bibliothek ims-lti von Version 1.2.9 auf 2.3.7 aktualisieren wollte.

Bei der Analyse der Änderungen zwischen den Versionen fiel mir auf:

• In Version 2.x wurde die Unterstützung für die OAuth-Bibliothek komplett entfernt – genau diejenige, auf der LtiScoreSubmission (die Gradings-Funktion) basierte.
• Eine Klasse namens IMS::LTI::ToolProvider, die für die Identitätsüberprüfung von Studierenden beim Start von CircuitVerse in Canvas zuständig ist, existiert in Version 2.x nicht mehr.

Hätte ich diesen Pull Request akzeptiert, wären alle LTI-Starts und Gradings-Funktionen stillschweigend ausgefallen. Ich verfasste eine detaillierte Review mit diesen Erkenntnissen und empfahl, den PR erst nach einer vollständigen Migration auf LTI 1.3 zu akzeptieren. Der PR wurde nicht gemergt.

Code zu prüfen, erfordert ein geschultes Auge – und diese Übung war eine wertvolle Lernerfahrung.

Donnerstag: Warum „Upstream Sync“ manchmal alles andere als einfach ist

Bevor ich neuen Code schreiben konnte, musste ich sicherstellen, dass meine lokale Version von CircuitVerse auf dem neuesten Stand war – ein Prozess, der als „Upstream Sync“ bekannt ist. Theoretisch sollte das einfach sein: Man zieht die neuesten Änderungen aus dem offiziellen Repository.

Doch in der Praxis gestaltete es sich unerwartet kompliziert. Git, das Versionskontrollsystem, spielte mir einige böse Streiche, und ich verbrachte Stunden damit, Konflikte zu lösen und sicherzustellen, dass meine lokale Umgebung konsistent blieb. Ein scheinbar trivialer Schritt entpuppte sich als eine der größten Herausforderungen der Woche.

Fazit: Was diese Woche über Open-Source-Entwicklung lehrt

Die zweite Woche hat mir deutlich vor Augen geführt, dass Softwareentwicklung weit mehr umfasst als nur das Schreiben von Code. Es geht darum, Code so zu gestalten, dass er in bestehende Systeme integriert werden kann – und das erfordert Geduld, Sorgfalt und die Bereitschaft, aus Fehlern zu lernen.

Die Erfahrungen dieser Woche werden nicht nur mein aktuelles Projekt voranbringen, sondern mir auch für zukünftige Open-Source-Beiträge wertvolle Werkzeuge an die Hand geben. Denn eines ist klar: Die Kunst, Dinge nicht kaputt zu machen, ist genauso wichtig wie die Kunst, sie zu bauen.