Wir nehmen einige Änderungen an der Kategorie Contribute > Feature vor.
- spec und rfc sind nun nur noch Tags (und ich habe
rfczu allen hinzugefügt, da ich hoffe,specganz abschaffen zu können) - Wir haben eine neue Kategorie namens #feature:announcements
Eine neue Konvention für Feature-Ankündigungen
Wenn ein neues Feature in den Beta-Zweig gemergt wurde (d. h. es ist bereits oder wird bald an alle unsere Kunden bereitgestellt), erstellen wir dafür in der Regel ein neues Thema in #feature:announcements.
Das bedeutet, dass wir unsere übliche Konvention ändern werden:
- Auf bestehende Feature-Diskussionen mit einer finalen Feature-Ankündigung antworten
- Das Thema schließen
Durch:
- Die Feature-Diskussion schließen.
- Mit einem neuen Thema antworten, das das Feature erklärt und offiziell ankündigt (in der Regel unter Übernahme von Texten aus der früheren Feature-Diskussion).
Wir verfolgen mit dieser neuen Kategorie mehrere Ziele:
-
Eine klare Trennung zwischen ausstehenden (Spezifizierung, Planung, Feedbackbedarf usw.) und abgeschlossenen Features.
-
Ein „Neue-Features-Feed“, den Site-Betreiber über Discourse, RSS oder die API verfolgen können.
-
Ein echter RSS-/API-freundlicher Feed von Features würde auch die Grundlage für einfache Integrationen an anderer Stelle schaffen, z. B. einen Feed mit „Neuen Features“ in unserem kommenden neuen Dashboard.
-
Es liefert uns sauber geschriebene Feature-Beschreibungen, die leichter geteilt werden können, ohne Neulinge durch das Einbetten in lange Feature-Diskussionen zu verwirren. Es besteht sogar die Möglichkeit, dies zu automatisieren.
Was ist der Unterschied zwischen Releases und Feature-Ankündigungen?
Während #releases exhaustive Änderungsprotokolle pro Release enthält, hält #feature:announcements dich über die neuesten Änderungen auf dem Laufenden, die gerade live gegangen sind. Dies spiegelt den für alle unsere Kunden und die meisten selbst gehosteten Nutzer geltenden Zeitplan für „inkrementelle Updates“ genauer wider.