Warum Benutzer nicht selbst Issues erstellen können

 (github.com/ghostty-org)
12 Punkte von GN⁺ 2026-01-03 | 3 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

Verwandte Beiträge

3 Kommentare

 
GN⁺ 2026-01-03
Hacker-News-Kommentare

  • Stimme zu 100 % zu. Wenn es das Projekt von jemand anderem ist, liegt die Entscheidungsbefugnis über Issues vollständig bei dieser Person
    Je größer ein Projekt ist, desto häufiger gibt es Leute, die Nachrichten nicht lesen, seltsame Anforderungen stellen oder sogar mit AI CVEs aufbauschen

    • Ich verstehe wirklich nicht, warum manche Leute Fehlermeldungen nicht lesen
      Auch wenn Nutzer die Bedeutung eines Fehlers nicht kennen, sollten sie wenigstens mitteilen, welcher Fehler genau angezeigt wurde
      Ich erinnere mich, dass ich früher beim Testen ausdrücklich einen „broken pipe error“ angegeben hatte, der Engineer den Bericht aber mit „nicht reproduzierbar“ schloss und dabei denselben Fehler als Grund nannte, warum es nicht reproduzierbar sei
    • GitHub Issues hat als Bug-Tracker Grenzen
      Die meisten Tracker können Zustände wie „unconfirmed“ zuordnen, aber GitHub ist nur ein einfaches Diskussionssystem, was die Verwaltung erschwert
    • Kurz nach dem Start von ChatGPT habe ich einmal einen CVE-Report erhalten
      Ich habe vier Stunden lang mit Code und Belegen dagegen argumentiert, und die Antwort war nur „shrugs AI“
    • Viele Nutzer wollen nur Ergebnisse, ohne Zeit zu haben, die genaue Nutzung eines Werkzeugs zu lernen
      Durch die „Facebookization“ entstand die Erwartung, dass alles mit ein paar Klicks erledigt ist, und durch die „LLMization“ wird das wohl noch schlimmer
      Für professionelle Software passt dieser Ansatz nicht, aber die Erwartungshaltung hat sich bereits so gebildet
    • Ein guter Issue-Tracker sollte Funktionen haben, die solches Rauschen herausfiltern
      Dass Ghostty Anfragen über Diskussionen klassifiziert, ist ein ungewöhnlicher, aber wirksamer Ansatz

  • Die Untersuchung des Memory Leaks ist über mehrere Plattformen verstreut
    X-Link 1, X-Link 2, Diskussion 1, Diskussion 2
    Es wurde noch nicht zu einem offiziellen Issue hochgestuft

    • Wegen des Memory Leaks habe ich aufgehört, Ghostty zu benutzen
      Selbst auf einem 8-GB-System trat schon nach ein paar Starts des Terminals Speichermangel auf
      Foot hatte zwar weniger Funktionen, war aber deutlich stabiler
    • Laut dem ersten Link sagt der Autor, dass dieses Problem nur zweimal gemeldet wurde
      Der zweite Link wirkt wie ein bloßer Versuch, eine Debatte anzustoßen
    • Ich habe dieses Problem ebenfalls in einer Diskussion gemeldet, aber keine Reaktion erhalten
      Ich habe mit Claude Code und Log-Analyse provisorisch einen Fix eingebaut, und jetzt lässt es sich nur noch in 1 von 10 Fällen reproduzieren
      Hoffentlich hilft das jemandem bei weiteren Untersuchungen
    • Auch die GPU-Kompatibilität ist heikel
      Selbst mit integrierten GPUs gibt es Probleme, die aber immer GTK oder Nvidia zugeschoben werden
    • Die Mitwirkenden scheinen entschieden zu haben, es noch nicht als Issue hochzustufen, weil klare Reproduktionsbedingungen fehlen

  • Ich halte die Trennung zwischen „Issues“ und „Discussions“ für ineffizient
    Man muss doppelt nach Duplikaten suchen, und Tickets lassen sich nicht verschieben
    Wenn man per E-Mail nachfasst, reißen die Benachrichtigungen ab
    Deshalb habe ich in meinem Projekt Discussions deaktiviert

    • Discussions sind nützlich als Ort für einfache Fragen oder Installationsprobleme
      Wenn es ein echter Bug ist, kann man es dann in ein Issue umwandeln
    • So ein Prozess lässt sich auch mit einem Label-System umsetzen
      Es reicht, wenn ein Admin das Label „bug“ setzt
    • Eine Duplikatprüfung ist nicht nötig
      Wenn die Diskussion geklärt ist, kann man dann ein Issue erstellen
    • Tatsächlich lassen sich Issues und Diskussionen ineinander umwandeln
      Die Benachrichtigungen bleiben ebenfalls erhalten
    • Wie bei Ghostty, wo jeder Discussions eröffnen kann und Issues von Admins verwaltet werden, wirkt das wie eine sinnvolle Trennung

  • Einige große Projekte in der Python-Community arbeiten ebenfalls so
    Aber aus Sicht von Power-Usern ist der Bug-Report-Prozess umständlich
    Eine Haltung nach dem Motto „Unser Projekt ist perfekt“ wirkt arrogant

    • Diese Unzufriedenheit ist schwer nachzuvollziehen
      Die meisten Drive-by-Bug-Reports sind nutzlos und eher Rauschen
      Wenn man wirklich beitragen will, ist es besser, bereits definierte Bugs zu beheben
    • Arrogant? Im Gegenteil, das sind Leute, die ihre Zeit und Mühe kostenlos investieren
      Es ist völlig normal, Einschränkungen für die Art von Reports zu setzen
    • Wenn du so oft Bugs findest, wäre es vielleicht sinnvoll, direkt am Projekt mitzuarbeiten
    • Umgekehrt kann auch die eigene Überzeugung „Das ist ganz klar ein Bug“ eine Form von Arroganz sein
    • Ist es wirklich umständlicher, eine Diskussion zu eröffnen als ein Issue? Ich bin mir nicht sicher

  • Zur Behauptung „Alle Issues sollten bereits arbeitsreif sein“ kam die Frage auf,
    „Warum versieht man sie dann nicht einfach mit einem Tag wie ‚ready-to-be-worked-on‘?“

    • Aber GitHub erlaubt es nicht, die Standardansicht auf „triage“ zu setzen, und in großen Projekten ist Issue-Management ineffizient
      Dieses System war viel erfolgreicher
    • Der Tag-Ansatz erfordert mehrere Feedback-Runden, wodurch Details über die Kommentare verstreut werden
    • Wenn jeder kommentieren kann, entsteht unnötiges Rauschen
      Deshalb wurden ein Raum nur für Entwickler und ein Raum für Nutzer getrennt
    • Falsch eingestufte Issues können auch nach dem Schließen wieder geöffnet werden, sodass die Issue-Liste am Ende unbeherrschbar wird
    • Es gibt keinen Grund, anderen ihren Workflow mit „Meine Methode ist besser“ aufzudrängen

  • Issues sind ab einer gewissen Größe nicht mehr beherrschbar
    Discussions als Filter zu verwenden ist effizient

    • Am Ende müssen Maintainer aber trotzdem alle Beiträge lesen und einsortieren, daher ist der Arbeitsaufwand ähnlich
      Die beiden GitHub-Funktionen haben fast dieselbe UI
      Allerdings gibt es in Discussions eine Upvote-Funktion
    • Es gab auch die zynische Reaktion: „Wäre es nicht effizienter, einfach alle Issues nach zwei Wochen automatisch zu schließen?“
    • Selbst große Projekte wie Curl haben nur 5 offene Issues
      curl/curl/issues

  • Manche meinen, diese Methode sollte die Standardeinstellung sein
    Eine Struktur, in der die Community Diskussionen führt und Mitwirkende die Issues betreuen, wäre ideal

    • Aber das ist letztlich nur eine Umverteilung des Prozesses, das Wesen bleibt gleich
      Auch mit dem Label-System von GitHub lässt sich das völlig ausreichend abbilden
      GitHub-Dokumentation zur Label-Verwaltung
    • Statt einen „Default“ festzulegen, ist es besser, wenn jedes Projekt natürlich experimentiert und die passende Methode findet
      Sozusagen wie ein Natural experiment

  • Ich stimme der Richtlinie für Einsendungen von Nutzern zu
    Wenn man geschlossene Diskussionen ansieht, wirken sie zwar ähnlich wie geschlossene Issues, aber zumindest nimmt das Rauschen im Issue-Tab ab
    Liste geschlossener Ghostty-Diskussionen

    • Alle Meldungen von Nutzern beginnen als Diskussion, und wenn sie sich als echte Bugs bestätigen, werden sie in Issues verschoben
      Viele Diskussionen erreichen dieses Stadium nicht, aber die Probleme der Nutzer werden trotzdem gelöst
      Diese Trennstruktur ist meiner Meinung nach ein ziemlich cleveres Design

  • Tatsächlich bedeutet „Man kann keine Issues eröffnen“ nicht, dass das eine GitHub-Funktion wäre,
    sondern nur, dass es einen Template-Hinweis gibt mit „Bitte keine neuen Issues eröffnen, sondern Discussions verwenden“

  • Ich habe dieses Vorgehen auch in anderen Projekten gesehen,
    und eine Struktur mit Diskussionen als Ausgangspunkt wirkt ziemlich vernünftig
    Allerdings haben viele Projekte GitHub Discussions noch nicht aktiviert
 
iolothebard 2026-01-03

Worin unterscheidet sich diese Diskussion eigentlich von einem Issue? Ein Issue ist kein „Bug“. Ob Bug, Funktionsvorschlag oder PR … sobald es etwas zu diskutieren gibt, ist es ein Issue.
Wenn es nicht diskussionswürdig ist, kann man es schließen.
 
nemorize 2026-01-09

Es liegt wohl nicht daran, dass Discussions und Issues grundsätzlich unterschiedlich wären, sondern einfach daran, dass die Aufteilung in separate Tabs eher dem persönlichen Geschmack entsprach.

Ob man im Issue-Tab sowohl eine Art To-do-Liste als auch Discussions veröffentlicht und das dann per Tags verwaltet
vs
ob man den Issue-Tab nur als To-do-Liste und Discussions ausschließlich als Discussions nutzt