Ich habe mir etwas Zeit genommen, um viele PRs im Gladys-GitHub-Repo zu schlieĂźen
Ein großer Teil dieser PRs war seit mehr als 6 Monaten völlig inaktiv, mit « WIP » im Titel, und meistens waren die Tests kaputt.
Für mich wurde es immer schwieriger, mich auf GitHub zurechtzufinden, ich finde nie die PRs, in denen ich erwähnt werde, und das kostet allen eine Menge Zeit.
Außerdem denke ich, dass das neue Entwickler abschrecken könnte, die zum Projekt stoßen und sehen, dass es hunderte nicht gemergte PRs gibt, von denen die meisten völlig kaputt sind. Das gibt den Eindruck, dass das Projekt im Stich gelassen wurde, was überhaupt nicht der Fall ist
Falls ich versehentlich eine PR geschlossen habe, die nicht geschlossen werden sollte, zögert nicht, sie wieder zu öffnen!
Nur zur Info, von meiner Seite aus habe ich die älteren Pull Requests, an denen ich noch nicht fertig war, einfach auf meinem persönlichen Fork neu erstellt, um sie nicht zu verlieren.
Ich habe den Bot in den beiden Repos hinzugefĂĽgt: Gladys und v4-website
Mal sehen, wie es sich in der Praxis bewährt. Wir können die Konfiguration anpassen, falls sie uns zu aggressiv oder nicht aggressiv genug erscheint.
In jedem Fall wird uns das sehr helfen, die inaktiven Issues/PRs zu schlieĂźen, die:
Potenziellen Mitwirkenden den Eindruck vermitteln, dass das Projekt aufgegeben wurde, obwohl das nicht der Fall ist (die meisten PRs sind einfach nur unbeantwortet/veraltet…)
Den Maintainern ermöglichen, die wirklich aktiven PRs besser einzuschätzen und sich nicht in einer endlosen Liste von PRs/Issues zu verlieren, wie es derzeit der Fall ist.
Andererseits wollen wir nicht:
Bugfixes verlieren, die gemeldet wurden und die wir nicht innerhalb von 2 Monaten beheben konnten (2 Monate sind sehr, sehr kurz, um ein Issue zu beheben, und ich habe persönlich selten die Zeit, mich innerhalb von 2 Monaten einem Issue zu widmen, es sei denn, es ist kritisch oder eine sehr kleine Entwicklung, die Priorität hat).
Entwicklungen verlieren, die einfach nur in Wartestellung waren.
Zögert nicht, mir Feedback zu geben, falls wichtige PRs/Issues geschlossen werden, die Konfiguration kann bei Bedarf angepasst werden.
Bei den Issues bin ich derselben Meinung wie @VonOx.
Wenn jemand eine Issue erstellt und niemand antwortet, wird sie geschlossen.
Dadurch wird das Problem nie behandelt.
Genau, wenn es innerhalb von 2 Monaten keine Antworten mehr gibt, macht es für mich Sinn, vom Bot eine Warnung zu erhalten, dass es vielleicht geschlossen wird (was eine Benachrichtigung für die Betroffenen auslöst):
Wenn es nicht geschlossen werden soll, kann man entweder antworten oder einen speziellen Tag hinzufĂĽgen, um anzugeben, dass der Bug immer noch vorhanden ist und dass man ihn behandeln wird.
Wenn es geschlossen werden soll, lässt man es einfach und der Bot schließt das Issue.
In jedem Fall ist das Ziel hier nicht, Bug-Rückmeldungen zu verlieren (wir wollen das eindeutig vermeiden), sondern eine kleine Erinnerung des Bots zu haben, die sagt: „Achtung Leute, hier antwortet seit 2 Monaten niemand, ist das noch aktuell?“.
Denn es gibt tatsächlich viele Zombie-Issues im Projekt, und ich denke, wir brauchen eine automatische Reinigungsroutine
Da es auf Seiten von Github eine Rate-Limitierung gibt, beantwortet es maximal 30 Issues pro Durchgang. Daher wird es einige Durchgänge dauern, bis es den gesamten Repo durchgegangen ist.
Ich werde jeden Issue bei diesem ersten Check ĂĽberprĂĽfen, um sicherzustellen, dass keine Fehler aufgetreten sind
