12 Punkte von GN⁺ 2026-01-03 | Noch keine Kommentare. | Auf WhatsApp teilen
  • Im Ghostty-Repository können Benutzer nicht selbst Issues erstellen; stattdessen muss zunächst eine Diskussion in GitHub Discussions gestartet werden
  • Das Projekt nutzt den Issue-Tracker nicht für Bug- oder Feature-Request-Diskussionen; alle Diskussionen finden in Discussions statt
  • Wenn eine Diskussion ausreichend konkretisiert ist und als umsetzbarer Punkt aufbereitet werden kann, wandelt ein Maintainer sie in ein Issue um
  • Diese Vorgehensweise ist eine Struktur, die Maintainern und Mitwirkenden hilft, schnell tatsächlich bearbeitbare Issues zu finden
  • Da die meisten Meldungen Probleme der Benutzerumgebung, Missverständnisse oder Anfragen zu noch nicht implementierten Funktionen sind, ist dieses Verfahren wichtig für die Qualitätssicherung des Projekts

Richtlinie zur Einschränkung der Issue-Erstellung

  • Im Ghostty-Repository können Benutzer nicht selbst Issues erstellen
    • Stattdessen müssen sie Probleme oder Vorschläge zunächst in GitHub Discussions teilen
    • Wenn Maintainer die Diskussion prüfen und als klar reproduzierbares Problem bestätigen, wird sie in ein Issue umgewandelt
  • Diese Methode dient dazu, den Issue-Tracker so zu halten, dass er nur tatsächlich bearbeitbare Einträge enthält
    • Da alle Issues bereits konkretisiert sind, können Mitwirkende sofort mit der Arbeit beginnen

Grundsätze für den Betrieb des Issue-Trackers

  • Ghostty verwendet den Issue-Tracker nicht für Diskussionen oder Feature Requests
    • Feature Requests oder allgemeine Fragen werden in Discussions behandelt
    • Issues enthalten nur klar definierte Bugs oder umsetzbare Arbeitspunkte
  • Dieser Ansatz ist ein auf Erfahrungen in der Pflege von Open-Source-Projekten basierendes Betriebsprinzip
    • Frühere Erfahrungen zeigten, dass 80–90 % der Benutzermeldungen keine echten Bugs, sondern Missverständnisse oder Umgebungsprobleme waren
    • Der größte Teil des Rests bestand aus Anfragen zu noch nicht implementierten Funktionen, die oft zusätzliche Spezifikationen erforderten

Höhere Wartungseffizienz

  • Durch die Discussions-Phase können Maintainer nur validierte Probleme als Issues verwalten
    • Unnötige Duplikate oder fehlerhafte Bug-Reports werden reduziert
    • Die Issue-Liste wird auf sofort bearbeitbare Punkte fokussiert
  • Benutzer müssen auch dann keine zusätzliche Arbeit leisten, wenn sie ein gültiges Problem finden
    • Maintainer wandeln es selbst in ein Issue um und bearbeiten es

Referenzdokument

  • Detaillierte Abläufe und Beitragsrichtlinien sind in der Datei CONTRIBUTING.md zu finden
  • Dort sind die Beteiligung an Discussions und die Kriterien für die Umwandlung in Issues festgehalten

Noch keine Kommentare.

Noch keine Kommentare.