Einführung von Upcoming Changes, einem System zur Verwaltung neuer Funktionen und Änderungen bestehender Funktionen in Ihrer Community

[lindsey (Lindsey Fogle)]

Da wir Discourse kontinuierlich verbessern, haben wir eine neue Konfigurationsseite „Geplante Änderungen“ erstellt, um Administratoren zu helfen, nachzuvollziehen, welche Änderungen in Discourse anstehen, und zu steuern, wie diese in ihrer Community eingeführt werden. Wir sind überzeugt, dass dieses System uns dabei hilft, Discourse auf sichere und transparente Weise weiterzuentwickeln.

In diesem Thema erklären wir, wie dieses neue System funktioniert und wie Sie es nutzen können, um neue Funktionen und andere Änderungen sicher in Ihrer Community einzuführen.

Übersicht zur Funktionsweise von „Geplante Änderungen“

Wenn wir an neuen Funktionen oder anderen Änderungen arbeiten, fügen wir diese der Konfigurationsseite „Geplante Änderungen“ unter /admin/config/upcoming-changes hinzu. Jede Änderung enthält eine Beschreibung, den Status, eine Angabe, welche Benutzer davon betroffen sind, und welche Benutzer (falls zutreffend) die Änderung in Ihrer Community bereits nutzen können.

Je nach Status der Änderung können Sie entscheiden, ob Sie diese für Ihre Community aktivieren oder deaktivieren möchten – zumindest vorübergehend, da einige Änderungen schließlich dauerhaft aktiviert werden.

Das vorübergehende Deaktivieren einer Änderung gibt Ihnen Zeit, um etwaige Anpassungen an Site-Konfigurationen, Prozessen usw. vorzunehmen, Ihre Community über die Änderung zu informieren oder bestimmte Benutzergruppen für Tests zu bestimmen.

Analyse einer geplanten Änderung

Schauen wir uns eine geplante Änderung genauer an und definieren die Informationen, die Sie in den einzelnen Bereichen sehen.

1 – Name und Beschreibung

Name und Beschreibung geben Ihnen eine kurze Erklärung der Änderung und verlinken auf ein verwandtes Meta-Thema für weitere Informationen und als Ort zur Sammlung von Feedback.

2 – Status

Der Status gibt Auskunft über die Position im Entwicklungszyklus. Der Status bestimmt direkt, ob die Änderung opt-in (d. h. standardmäßig deaktiviert, aber von Ihnen aktivierbar), opt-out (d. h. standardmäßig aktiviert, aber von Ihnen deaktivierbar) oder erzwungen aktiviert (d. h. aktiviert und nicht deaktivierbar) ist.

Wir verwenden in „Geplante Änderungen“ die folgenden Status:

• Experimental: Eine potenzielle Änderung, die sich in der frühen Entwicklungs-/Testphase befindet und sich voraussichtlich schnell weiterentwickeln wird oder möglicherweise vollständig entfernt wird, wenn wir das Experiment beenden (in diesem Fall wechselt sie zum Status Inaktiv; siehe unten). Sie können sich für Experimental-Änderungen anmelden, um sie zu testen.
• Alpha: Eine getestete Änderung, die sicher genutzt werden kann, wobei es möglicherweise noch kleinere Anpassungen am Design oder an der Funktionalität geben kann. Sie können sich für Alpha-Änderungen anmelden, um sie frühzeitig zu nutzen.
• Beta: Eine getestete Änderung, die sicher genutzt werden kann und sich vor dem Wechsel zum Status Stabil oder möglicherweise Permanent wahrscheinlich kaum noch ändern wird.
  • Für die meisten Sites in unserem Hosting und für selbst gehostete Sites werden Beta-Änderungen automatisch für alle Benutzer aktiviert (sofern Sie sie nicht zuvor bereits aktiviert haben), aber Sie können sich weiterhin abmelden.
• Stabil: Eine abgeschlossene Änderung^[1], die jedoch weiterhin opt-out ist (d. h. Administratoren können sie deaktivieren). Administratoren erhalten auf ihrem Dashboard eine Warnung, wenn sie eine Stabile Änderung deaktiviert haben.
• Permanent: Eine Änderung, die den Test abgeschlossen hat und erzwungen aktiviert ist (d. h. Administratoren können sie nicht deaktivieren). Permanente Änderungen erscheinen nicht mehr in der Liste der geplanten Änderungen, sondern werden auf der Seite /admin/whats-new angezeigt.
• Inaktiv: Ein aufgegebenes Experiment. Sie können sich nicht anmelden.

Manchmal durchlaufen Änderungen diese Status linear (d. h. beginnen mit Experimental und enden mit Permanent), aber nicht immer. Einige Änderungen werden möglicherweise mit dem Status Alpha oder Beta eingeführt und andere enden im Status Stabil. Änderungen vom Typ „Standardeinstellung der Site“ werden nicht in den Status Permanent überführt, da sie nur den Standardwert einer bestehenden Einstellung ändern.

Es gibt keine feste Zeitvorgabe, wie lange der Übergang einer bestimmten Änderung von einem Status zum anderen dauert, aber Administratoren werden benachrichtigt, wenn:

• Eine neue Änderung zum Ausprobieren verfügbar ist
  • Diese werden zur Vermeidung von Benachrichtigungsüberflutung höchstens einmal pro Woche gesendet. Wenn Sie diese Benachrichtigungen nicht erhalten möchten, können Sie sie unter /my/preferences/notifications deaktivieren.
• Eine Änderung automatisch aktiviert wurde
• Wenn Sie eine Änderung deaktiviert haben, die bald erzwungen aktiviert wird
  • Dies wird als Warnung im Administratordashboard angezeigt

3 – Betroffene Benutzer

Das Tag „Betroffene Benutzer“ beschreibt, welche Benutzer in Ihrer Community die Änderung in irgendeiner Weise sehen oder damit interagieren können. Einfach ausgedrückt: Wer könnte diese Änderung bemerken? Es gibt verschiedene Arten betroffener Benutzer:

• Admins: Die Änderung ist nur für Administratoren sichtbar.
• Staff: Die Änderung ist nur für Administratoren und Moderatoren sichtbar.
• All members: Die Änderung ist für alle Mitglieder Ihrer Site sichtbar.
• Developers: In seltenen Fällen ist eine Änderung nur für Personen bemerkbar, die mit Code im Kernsystem, in Themes oder Plugins interagieren.

Art der Auswirkung

Eine Teilmenge der betroffenen Benutzer, die nicht in der Liste angezeigt wird, ist die Art der Auswirkung. Die Art der Auswirkung beschreibt, wie sich die Änderung im Allgemeinen auf Ihre Community auswirkt:

• Feature: Die Änderung führt eine neue Funktion oder Funktionalität in Ihrer Community ein oder modifiziert bestehende Funktionen.
• Site setting default: Die Änderung modifiziert den Standardwert einer bestehenden Site-Einstellung. Administratoren, die die Einstellung bereits von ihrem alten Standardwert abgeändert haben, werden nicht betroffen sein. Für diese Änderung wird nach Erreichen des Status Stabil keine Warnung im Administratordashboard angezeigt.
• Other: Alle anderen Änderungen, die nicht in die oben genannten Kategorien passen.

4 – Aktiviert für…

In diesem Dropdown-Menü können Sie als Site-Administrator steuern, ob und wie Sie diese Änderung in Ihrer Community einführen, indem Sie sie aktivieren für:

• No one: Deaktiviert die Änderung für alle Benutzer der Site.
• Everyone: Aktiviert die Änderung für alle Benutzer der Site, einschließlich anonymen Benutzer. Wenn die Änderung automatisch aktiviert wird (typischerweise im Status Beta), erfolgt dies für Everyone.
• Staff only: Aktiviert die Änderung für das Site-Team (d. h. Administratoren und Moderatoren).
• Specific groups: Aktiviert die Änderung für die ausgewählte(n) Gruppe(n).

Bei einigen geplanten Änderungen können die Optionen für „Aktivieren für“ eingeschränkt sein. Die verfügbaren Optionen im Dropdown-Menü „Aktiviert für“ werden durch die Konfiguration der Änderung bestimmt. Beispielsweise erlauben bestimmte Änderungen möglicherweise nur die Optionen Everyone und No one, da ein begrenztes Gruppentestverfahren für diese Änderung nicht praktikabel wäre.

---

Für jetzt haben wir die meisten Experimental-Änderungen von /admin/config/experimental in „Geplante Änderungen“ verschoben, und Sie werden bald neue Updates hier sehen. Wir freuen uns darauf, von den Auswirkungen in Ihrer Community zu hören und heißen alle Fragen oder Feedback willkommen!

---

1. Soweit Software überhaupt als abgeschlossen gelten kann! ↩︎

[NateDhaliwal]

Ich bin neugierig – wie steuert es die Einführung der Änderung? Kann es geändert werden, nachdem die Funktion eingeführt wurde? Danke.

[merefield (Robert)]

Native Feature Flags! Sehr gut

Wäre toll, eine API für Plugins zu haben.

[Canapin (Coin-coin le Canapin)]

Das ist eine lang erwartete Funktion! Danke!

[darkpixlz (Pyx)]

Das ist großartig, die Möglichkeit zu haben, Flags wie diese zu ändern, ist erstaunlich für Leute an der vordersten Front wie mich, besonders beim Entwickeln eines Themas.

Ist „bevorstehende Änderungen“ wirklich der beste Name dafür? HomeAssistant verwendet zum Beispiel „Labs“ und viele andere Leute verwenden einfach Dinge wie „Experimente“, was sich besser anfühlt als bevorstehende Änderungen.

[lindsey (Lindsey Fogle)]

@NateDhaliwal

Ich bin neugierig – wie wird die Einführung der Änderung gesteuert?

Sie werden über neue Funktionen benachrichtigt, während diese sich noch in einem Zustand befinden, in dem Sie sie frühzeitig ausprobieren (Opt-in) und vorübergehend deaktivieren können, um Probleme zu beheben, die durch die Änderung verursacht wurden (Opt-out). Wenn eine Änderung „permanent“ wird (was bedeutet, dass Sie nicht deaktivieren können) und Sie sie derzeit deaktiviert haben, werden wir Sie informieren.

In diesem Abschnitt wird dies etwas detaillierter beschrieben:

@lindsey

Manchmal durchlaufen Änderungen linear diese Status (d. h. beginnen in Experimentell und enden in Permanent), aber nicht immer. Einige Änderungen können im Status Alpha oder Beta eingeführt werden, und einige enden im Status Stabil (wenn sie nicht erzwungen werden).

Es gibt keine festgelegte Zeit, wie lange es dauern wird, bis eine bestimmte Änderung von einem Status zum nächsten übergeht, aber Administratoren werden benachrichtigt, wenn:

• Eine neue Änderung zum Ausprobieren verfügbar ist
• Eine Änderung automatisch aktiviert wurde
• Wenn Sie eine Änderung deaktiviert haben, die bald erzwungen wird

@darkpixlz

Ist „bevorstehende Änderungen“ wirklich der beste Name dafür?

Im Moment sehen Sie nur experimentelle Änderungen, da wir diese aus dem Einstellungsbereich in Bevorstehende Änderungen migriert haben. Zukünftig werden hier aber auch nicht-experimentelle Updates angezeigt. Daher fühlt sich „Labs“ für die Art und Weise, wie wir dieses System verwenden, nicht zutreffend an.

[martin (Martin Brennan)]

@merefield

Es wäre großartig, eine API für Plugins zu haben.

Plugins können dieses System bereits nutzen. Der Ersteller des Themas geht nicht auf die technischen Details ein, aber es ist nicht viel nötig, um eine bevorstehende Änderung hinzuzufügen.

Die Kurzzusammenfassung lautet:

• Eine Site-Einstellung hinzufügen, die hidden: true und client: true hat

• Eine Beschreibung für die Einstellung in server.en.yml hinzufügen

• Optional einen Screenshot zu public/images/upcoming_changes/SETTING_NAME.png hinzufügen

• Metadaten upcoming_change zur Einstellung hinzufügen, die wie folgt aussehen:

# upcoming_change       - Zusätzliche Metadaten mit den folgenden Optionen, die auf der Seite /admin/config/upcoming-changes angezeigt werden sollen:
#                          - status: experimental | alpha | beta | stable
#                          - impact: zwei durch Komma getrennte Teile - feature|other , staff|admins|moderators|all_members|developers
#                          - learn_more_url: eine URL für weitere Informationen

Der Haken dabei ist jedoch, dass wir dieses System bisher nicht wirklich für Drittanbieter-Plugin-Entwickler vorgesehen haben, sondern es hauptsächlich für unsere eigenen Zwecke gedacht war. Vielleicht können wir im Laufe der Zeit mehr über diesen Anwendungsfall nachdenken.

[noahl (Noah Lovell)]

Liebe das! Danke

Wäre es möglich, einen Link/eine Verknüpfung zu der relevanten Einstellung zu haben, falls zutreffend? Z. B. hat der benutzerdefinierte Startbildschirm zusätzliche Einstellungen, die für seine Funktion konfiguriert werden müssen (Hochladen der SVG) – aber man muss aktiv danach suchen. Es wäre hilfreich, sie dort zu haben, wo sie aktiviert wird.

[martin (Martin Brennan)]

Ja, das stimmt! Ich arbeite gerade an dieser Änderung, sie sollte in ein oder zwei Tagen verfügbar sein. Ich werde mir notieren, Ihre gehostete Seite bereitzustellen, damit Sie das Update erhalten

Edit: Erledigt!

[sniper756]

Ich möchte fragen, wie die „Bevorstehenden Änderungen“ in der Admin-Oberfläche angezeigt werden, wenn man Discourse selbst hostet.

@lindsey

[martin (Martin Brennan)]

Wir haben dies immer noch hinter einer globalen Site-Einstellung namens enable_upcoming_changes versteckt, die verborgen ist. Sie können diese daher in der Rails-Konsole Ihrer Website mit rails c aktivieren. Schließlich werden wir diese entfernen, und Sie müssen dies nicht mehr tun.

[sniper756]

Okay, danke, dann warte ich lieber ab~ ~ ~ ~ ~ ~ ~ ~

[ToddZ]

Ich bin mir nicht sicher, ob das klar war: Der Menüpunkt für Bevorstehende Änderungen ist noch nicht live, aber …

Umformulierung:
Wenn Sie den Menüpunkt noch nicht haben, können Sie den Abschnitt „Bevorstehende Änderungen“ trotzdem sehen, indem Sie zu [Ihr_Forum]/admin/config/upcoming-changes gehen.

[martin (Martin Brennan)]

Sollte es, sehen Sie es hier nicht?

Hosten Sie selbst? Wenn ja, müssen Sie auch enable_upcoming_changes (eine versteckte Einstellung) auf true setzen. Wir planen, dies in naher Zukunft zu entfernen, sobald wir uns völlig sicher sind, dass das System stabil ist.

[Moin]

Gibt es einen Grund, warum die meisten Website-Einstellungen für bevorstehende Änderungen ausgeblendet sind, enable_auto_grid_images jedoch nicht?

[martin (Martin Brennan)]

@Moin

enable_auto_grid_images

Nein, nur ein Versehen, hier behoben:

FIX: Hide enable_auto_grid_images site setting (#38046)

[ToddZ]

Ja, ich hoste selbst, wie sniper756.
„ist noch nicht live“ war vielleicht nicht die beste Formulierung; ich werde es bearbeiten.

[Moin]

Heute habe ich darüber nachgedacht, wie praktisch es wäre, die Änderungen nach Status zu sortieren – zuerst Beta, dann Alpha und schließlich Experimental. Ich weiß, dass ich danach filtern kann, aber ich möchte die gesamte Liste sehen; ich finde Änderungen je nach Status mehr oder weniger interessant.

[martin (Martin Brennan)]

Ja, das ergibt Sinn. Ich habe auch darüber nachgedacht, eine Sortieroption basierend darauf hinzuzufügen, wann die Änderung auf deiner Seite erschienen ist… werde beides hinzufügen

[khenmu (John Sweeney)]

Fantastische Ergänzung!

Vielen Dank dafür.