Sehr gute Frage, und sie kommt genau zum richtigen Zeitpunkt, bevor der Katalog zu groß wird 
Was es heute schon gibt
Eine Integration wird nirgendwo « registriert »: Der Indexer durchsucht alle Stunden die öffentlichen Repositories, die das GitHub-Topic gladys-assistant-integration tragen, liest das Manifest, überprüft das Docker-Image und veröffentlicht den Katalog. Direkte Konsequenzen:
- Das Entfernen des Topics (oder das Archivieren des Repositories) entfernt die Integration aus der Liste im nächsten Zyklus, ohne etwas bei denen zu beschädigen, die sie bereits installiert haben: Der Container läuft weiter, das Image bleibt auf ghcr.io. Genau das beschreibt @guim31, und es funktioniert bereits.
- Eine wiederaufgenommene, verlassene Integration bedeutet: Repository forken,
docker_image zu seinem eigenen Registry ändern, Topic hinzufügen, veröffentlichen. Keine Erlaubnis von irgendjemandem nötig.
Zum resultierenden Duplikat
Ja, wir haben zwei Einträge, und nein, ich habe nicht vor, Duplikate zu entfernen. Ein Store ohne Review, der Duplikate ablehnt, ist ein Store mit einem Schiedsrichter, und der Schiedsrichter wird wieder zu einem Engpass. Der echte Hebel ist das Signal, nicht der Filter.
Ich hatte zuerst an ein Badge « nicht gewartet seit X Monaten » gedacht, aber bei genauerer Betrachtung ist das eine falsche gute Idee. Viele Integrationen sind einfach fertig: Eine Integration für Tempo oder Free Mobile kann ein Jahr lang nicht aktualisiert werden, weil sie einfach funktioniert. Umgekehrt kann eine Cloud-Integration morgen kaputtgehen, weil der Anbieter seine API geändert hat, ohne dass ein Commit erfolgt. Das Datum der letzten Veröffentlichung misst weder das eine noch das andere, und die einzige Möglichkeit, das Badge zu entfernen, wäre die Veröffentlichung kosmetischer Versionen. Schlechte Anreize und unfair gegenüber denen, die die Arbeit gut gemacht haben.
Was « verlassen » wirklich von « fertig » unterscheidet, ist die Reaktionsfähigkeit: Ein Repository ohne Commits seit einem Jahr und ohne offene Issues ist in Ordnung, ein Repository mit unbeantworteten Issues seit Monaten viel weniger.
Daher würde ich eher Folgendes vorschlagen:
- Repository auf GitHub archiviert, also automatisch aus der Liste entfernt. Klare Signalisierung, vom Autor erklärt.
- Später ein echter Gesundheitsindikator auf der Instanzenseite (wie viele nutzen sie, wie viele sehen Abstürze), der die einzige ehrliche Messung von « funktioniert es noch » ist.
1 und 2 beantworten das Szenario von @prohand recht sauber, ohne dass eine Kommission nötig ist.
Ich denke, 2) kann später implementiert werden, denn im Moment ist das Projekt noch zu klein, als dass ein solcher Wert für einen Nutzer, der z. B. von HA kommt, wirklich ein Signal wäre.
Zur « Analysekommission »
Ich glaube nicht, dass das die richtige Antwort ist. Sobald man die Qualität der Integrationen anderer bewertet, schafft man das Modell, das man gerade verlassen hat, mit dem zusätzlichen Problem endloser Debatten. Der Docker-Sandbox ist da, damit es dem Nutzer nichts kostet, es auszuprobieren, und eine schlecht gemachte Integration kann seine Instanz nicht destabilisieren. Einzige Ausnahme aus meiner Sicht: ein wirklich bösartiges Image. Ja, da könnte man eine Blacklist einrichten, wenn es soweit kommt.
Dass ich die Rechte eines Maintainers bekomme
Danke für das Vertrauen, aber nein
Der ganze Sinn der externen Integrationen war es ja, mich aus dem kritischen Pfad herauszuhalten. Maintainer von 40 Repositories zu sein, die ich nicht kenne, wäre nur eine neue Form desselben Engpasses, und ein Maintainer, der nichts merget, schützt niemanden.
Im Gegenteil, der echte Schutz ist vorgelagert.
Fügt von Anfang an einen zweiten vertrauenswürdigen Maintainer hinzu, bevor ihr ihn braucht 