2 Punkte von GN⁺ 2024-10-03 | 1 Kommentare | Auf WhatsApp teilen
  • Öffentliche Vorstellung verschiedener Verbesserungen wie Sub-Issues, Issue Types und Issue-Suche

Issues mit Sub-Issues detaillierter aufteilen und verwalten

  • Mit Sub-Issues lassen sich Issues in einer Eltern-Kind-Hierarchie weiter unterteilen und organisieren
  • Sub-Issues können in allen Issues erstellt werden; mit verschachtelten Strukturen lassen sich Fortschritt und verbleibende Arbeit nachverfolgen
  • Der Fortschritt von Sub-Issues lässt sich innerhalb von Projekten leicht verfolgen

Arbeit mit Issue-Typen organisieren

  • Mit Issue-Typen lassen sich Issues mit einer gemeinsamen Sprache kategorisieren und verwalten, die über alle Repositories einer Organisation hinweg geteilt wird
  • So kann man den Fortschritt im Bug-Backlog schnell erfassen, alle übergeordneten Initiativen finden, an denen das Team arbeitet, und die Einordnung der Projektarbeit besser verstehen

Mit erweiterter Suche genau das finden, was man sucht

  • Auf der Repository-Issue-Seite kann eine erweiterte Suche mit den Schlüsselwörtern AND und OR sowie Klammern für verschachtelte Suchen aufgebaut werden
  • Damit lassen sich komplexere Filter erstellen, um exakt die gewünschte Menge an Issues zu finden

Updates an der Issue-UI

  • Auf der Issue-Indexseite wurde eine neue Filterleiste mit Autovervollständigung und Syntaxhervorhebung hinzugefügt
  • Mit der Option „Create More“, über die man schnell zum Erstellungsbildschirm zurückkehren kann, lassen sich mehrere Issues schneller anlegen
  • Mit Issue-Formularen und Templates, die nach Dateinamen alphabetisch angezeigt werden, lässt sich die gewünschte Reihenfolge einfach festlegen
  • Mit dem neuen Button „Copy Link“ lässt sich die URL eines Issues einfach teilen
  • Bei langen Issues werden bei Auswahl von „Load More“ jetzt 150 statt 50 Events geladen

Mehr Elemente in GitHub Projects

  • Zuvor wurde eine private Beta für ein erhöhtes Projekt-Item-Limit angekündigt, bei der die Kapazität pro Projekt von 1.200 auf 50.000 erweitert wird
  • Heute wird der Kreis der Projekte erweitert, für die dieses erhöhte Limit verfügbar ist
  • Seit der privaten Beta wurden Unterstützung für Slices, Swimlanes und die GraphQL API hinzugefügt sowie wichtige Bugs behoben und die Performance verbessert
  • Wenn man Projektadministrator ist, sich dem Item-Limit nähert und im Projekt keine Insights nutzt (derzeit die einzige nicht unterstützte Funktion), erscheint oben im Projekt ein Banner
  • Dieses Update erfolgt pro Projekt, nicht pro Organisation. Berechtigte Projekte können über den Button „Join Waitlist“ teilnehmen

Meinung von GN⁺

  • Dieses Update entwickelt bestehende Issue-Tracking-Tools einen Schritt weiter und dürfte die Zusammenarbeit in Softwareentwicklungsteams deutlich verbessern
  • Der Vorteil von Sub-Issues besteht darin, Arbeit feiner aufzuteilen und trotzdem den Gesamtfortschritt leichter zu erfassen; wird die Hierarchie jedoch zu tief, kann die Lesbarkeit darunter leiden
  • Eindrucksvoll ist, dass sich mit der Konfiguration von Issue-Typen Issues organisationsweit in einer einheitlichen Sprache verwalten lassen. Das dürfte Kommunikation und Verständnis zwischen Teams verbessern
  • Die erweiterte Suche wird nützlich sein, um in großen Mengen von Issues schnell die gewünschten Informationen zu finden. Allerdings sollte dafür vorab eine Schulung für Nutzer erfolgen, damit sie komplexe Abfragen formulieren können
  • Dass das Limit für Projekt-Items erhöht wurde, dürfte bei der Verwaltung großer Projekte sehr hilfreich sein. Dennoch ist es nicht unbedingt wünschenswert, zu viele Items in ein einzelnes Projekt zu packen

1 Kommentare

 
GN⁺ 2024-10-03
Hacker-News-Kommentare
  • Die größte Schwäche von GitHub Issues ist, dass beim Besuch einer Issue-Seite der ursprüngliche Bericht als Hauptinhalt angezeigt wird

    • Es ist gut möglich, dass nur Symptome beschrieben werden, ohne das eigentliche Problem zu verstehen
    • Es ist möglich, dass die ursprüngliche meldende Person keinen guten Bug-Report schreiben konnte
    • Eine Issue kann offen bleiben, obwohl das Hauptproblem gelöst ist, weil ein kleiner Teil noch nicht behoben wurde
    • Es wäre gut, wenn es oben auf der Seite einen Bereich gäbe, der das aktuelle Verständnis des Problems und seinen Status beschreibt
  • Ich wollte GitHub Issues nutzen, bin aber enttäuscht, weil es komplizierter geworden ist

    • Es besteht die Sorge, dass es so komplex wird wie ADO, Jira oder Asana
  • Wenn Issues auf Repository-Maintainer beschränkt wären, würde das Beiträge zu FLOSS-Projekten erleichtern

    • Der Fokus wird derzeit durch Support-Anfragen, Vorschläge und Gespräche verwässert
    • An einer Jirafizierung von Issues habe ich kein Interesse
  • Ich habe das letzte große Update von GitHub Issues vor 10 Jahren entwickelt und hatte mehr erwartet

    • Es fühlt sich wie checkbox-basierte Entwicklung an
    • React ist enthalten
  • Es braucht zusätzliche Status wie "closed - duplicate", "closed - won’t fix", "our bot closed this because no one commented on it for 6 weeks"

    • Wenn man ein Problem findet, ist es oft schon geschlossen, was frustrierend ist
  • Ich kann die negativen Reaktionen nicht verstehen

    • Für Unternehmensnutzer ist es ein großartiges Upgrade
    • Im Vergleich zu GitLab Issues oder Linear ist das ein Aufholen
  • Es gibt doch schon Labels, daher verstehe ich nicht, was der Sinn von Issue-Typen ist

  • Wenn man mehreren Probleme in Issue-Kommentare aufnimmt, wird die Nachverfolgung schwierig

    • Es gibt zwar eine Möglichkeit, [ ]-Checkboxen hinzuzufügen, aber es ist nicht klar, wer etwas erledigt hat
    • Man kann auch Review-Kommentare zu einem Pull Request im Code hinzufügen, aber dabei lässt sich keine zuständige Person anzeigen
  • Das größte Problem von GitHub Issues ist, dass große Open-Source-Projekte Prioritäts-Issues nicht einfach kenntlich machen können

    • Aggressive Moderation ist möglich, erzeugt bei den Issue-Erstellern aber Unbehagen
    • Es braucht eine Möglichkeit, zwischen Backlog und To-do zu unterscheiden
  • Ich mochte die frühere Überarbeitung der Aufgabenliste

    • Der organische Ansatz für Projektmanagement gefiel mir
    • Ich war enttäuscht, dass es auf explizite Unteraufgaben umgestellt wurde