Der Joomla GitHub Prozess wurde angepasst. Früher folgte Joomla der Devise «schreibe den Code, poste ihn auf GitHub und dann entscheiden wir, ob wir diesen im Core verwenden wollen oder nicht». Heute hat Joomla einen professionellen Prozess, der die Strategie «erst denken, dann implementieren» verfolgt.
Der Frust der Programmierer war sehr gross, wenn man die ganze Arbeit für das Schreiben eines Patches oder neuen Funktion hatte und dann die Implementation in den Core abgelehnt oder sogar komplett ignoriert wurde. Auf der anderen Seite wurde Code eines Mitglieds, der in der Community hoch angesehen war, angenommen, obwohl die Architektur und Art der Umsetzung viel schlechter war.
Diese Entwicklung führte dazu, dass immer weniger Personen bereit waren, etwas für den Core beizusteuern. Da muss sich ändern! Deshalb erschuf man einen komplett neuen «Request for Comments» Prozess, der in klare Arbeitsschritte eingeteilt ist.
Grundsätzlich darf jeder neue Funktionen vorschlagen. Es werden lediglich zwei Dinge benötigt:
- ein Beschrieb der Funktion (Zusammenfassung)
- Grund warum es diese Funktion braucht (warum die Mühe?)
Der Vorschlag durchläuft dann folgende Arbeitsschritte:
Der Joomla GitHub Prozess im Detail
1. Schritt: Vorentwurfsphase
Das Ziel der Entwurfsphase ist es, festzustellen, ob eine Mehrheit von Joomla überhaupt an einem bestimmten Feature interessiert ist.
Wer an der Funktion interessiert ist, kann sich an der Diskussion beteiligen. Es spielt keine Rolle, wo die Diskussion stattfindet, solange der Zugang für die Interessierten offen ist. Dazu gehört auch eine informelle Diskussion auf den offiziellen Joomla-Diskussionsmedien darüber, ob die Idee Sinn macht und im Rahmen der Ziele von Joomla liegt oder nicht.
Sobald die Teilnehmer beschlossen haben, weiterzumachen, werden sie eine Arbeitsgruppe bilden. Eine Arbeitsgruppe besteht aus mindestens einem Redakteur, einem Teamleiter aus der Produktionsabteilung, der als Begleiter fungiert und mindestens einer weiteren Person. Das können sowohl Teamleiter oder Teammitglieder als auch Mitglieder der allgemeinen Community sein.
Es ist nicht notwendig, dass der Vorschlag in diesem Stadium vollständig entwickelt ist, obwohl dies zulässig ist. Zumindest muss er eine Erläuterung des zu lösenden Problems, die Begründung und grundlegende Informationen über den allgemeinen Ansatz enthalten. Eine weitere Überarbeitung und Erweiterung wird erst in der Entwurfsphase erwartet. Damit soll verhindert werden, dass zu viel Energie in Anforderungen gesteckt wird, deren Chance, angenommen zu werden, gegen Null geht.
Die Community oder die Teamleiter der Produktionsabteilung (je nachdem, wie spezifisch ein Vorschlag ist) entscheiden, ob der Vorschlag weiterverfolgt werden soll oder nicht.
Wenn das Votum positiv ausfällt, geht der Vorschlag offiziell in die Entwurfsphase über. Der Vorschlag erhält eine eigene RfC-Nummer.
Die Arbeitsgruppe kann natürlich auch während der Abstimmungsphase weiter an dem Vorschlag arbeiten.
2. Schritt: Entwurfsphase
Ziel dieser Phase ist es, einen Feature-Vorschlag so weit zu diskutieren und zu verfeinern, dass er von den Teamleitern der Produktionsabteilung zur Prüfung in Betracht gezogen werden kann.
Während der Entwurfsphase können die Mitglieder der Arbeitsgruppe alle Änderungen, die sie für angebracht halten, über Pull-Requests, Kommentare auf GitHub, der Mailingliste, IRC und ähnliche Werkzeuge vornehmen.
Änderungen sind hier nicht durch strenge Regeln begrenzt und grundlegende Anpassungen sind möglich, wenn sie vom Autor des Vorschlags unterstützt werden. Alternative Ansätze können jederzeit vorgeschlagen und diskutiert werden. Wenn der Editor und der begleitende Teamleiter überzeugt sind, dass ein alternativer Vorschlag dem ursprünglichen Vorschlag überlegen ist, kann die Alternative den ursprünglichen Vorschlag ersetzen. Von den Mitgliedern der Arbeitsgruppe wird erwartet, dass sie während der gesamten Entwurfsphase engagiert bleiben.
Die Diskussionen sind öffentlich und jeder, unabhängig von seiner Joomla-Zugehörigkeit, ist willkommen, konstruktive Beiträge zu leisten. Während dieser Phase hat der Autor des Vorschlags die letzte Autorität über Änderungen an der vorgeschlagenen Spezifikation.
Der Koordinator der Produktionsabteilung wird sicherstellen, dass der Arbeitsgruppe die notwendigen Ressourcen zur Verfügung gestellt werden, um an der Spezifikation zu arbeiten, wie z.B. ein spezielles GitHub-Repository, eine Mailingliste, ein Forenbereich und ähnliche Werkzeuge.
Alle in der Entwurfsphase gewonnenen Erkenntnisse, wie z. B. mögliche alternative Ansätze, deren Auswirkungen, Vor- und Nachteile usw., sowie die Gründe für die Wahl des vorgeschlagenen Ansatzes müssen in einem übergeordneten Dokument zusammengefasst werden. Diese Regel soll verhindern, dass sich die Diskussionen im Kreis drehen oder alternative Vorschläge wieder auftauchen, nachdem eine Entscheidung getroffen worden ist.
Wenn der Autor und die Begleitperson sich einig sind, dass der Vorschlag fertig ist und das übergeordnete Dokument objektiv und vollständig ist, kann der Autor eine «Umsetzungs»Abstimmung innerhalb der Arbeitsgruppe durchführen, um festzustellen, ob die Spezifikation im Wesentlichen vollständig und bereit für die nächste Phase ist.
Wenn die Abstimmung positiv ausfällt, tritt der Vorschlag formell in die Reviewphase ein. Wenn nicht, verbleibt er in der Entwurfsphase.
3. Schritt: Review-Phase
Diese Phase ist eine Gelegenheit für die Community, mit einem vernünftig definierten Ziel zu experimentieren, um die Machbarkeit des Vorschlags zu beurteilen. In dieser Phase ist die Begleitperson die letzte Instanz für Änderungen an der Spezifikation und für jede Entscheidung, den Vorschlag vorwärts oder rückwärts zu bewegen; der Autor kann jedoch ein Veto gegen vorgeschlagene Änderungen einlegen, von denen er glaubt, dass sie dem Design der Spezifikation schaden würden.
Nur Fehlerbehebungen und redaktionelle Änderungen (Wortlaut, Tippfehler, Klarstellungen, etc.) an der Spezifikation sind jetzt erlaubt. Grössere Änderungen sind in diesem Stadium nicht erlaubt. Wenn sich herausstellt, dass grössere Änderungen notwendig sind, muss die Spezifikation zurück in die Entwurfsphase verschoben werden. Jede inkompatible Änderung, die einen erheblichen Anpassungsaufwand für die Implementierungen erfordern würde, gilt als wesentliche Änderung. Kleine bis moderate inkompatible Änderungen erfordern nicht unbedingt eine Rückkehr in die Entwurfsphase.
Wenn ein Vorschlag nicht in die Entwurfsphase zurückgeht, muss er mindestens vier Wochen lang in der Überarbeitungsphase bleiben, bis
- die Benutzerschnittstelle definiert ist und die Handbuchseite (Hilfe) für die im Feature RfC vorgeschlagene Funktionalität geschrieben wurde.
- Für Schnittstellendefinitionen können zwei unabhängige praktische Testimplementierungen nachgewiesen werden, idealerweise als Beispiele im RfC-Repository. Die Verantwortung, solche Testimplementierungen zu finden und sie den Teamleitern der Produktionsabteilung vorzustellen, liegt bei der Arbeitsgruppe und insbesondere beim Autor und der Begleitperson. Da nicht alle Spezifikationen PHP-Schnittstellen sind, bei denen die Definition von „Implementierung“ selbstverständlich ist, sollte die Begleitperson nach bestem Wissen und Gewissen entscheiden, wann dies der Fall ist. Jedes Mitglied, der Teamleiter der Produktionsabteilung kann eine bestimmte Testimplementierung aus triftigen Gründen als irrelevant oder unzureichend ablehnen.
Wenn vier Wochen verstrichen sind und die Benutzeroberfläche und die Hilfeseite sowie – falls zutreffend – zwei brauchbare Probeimplementierungen vorgeführt werden können, kann die Begleitperson/Teamleiter aus dem Produktionsteam eine Akzeptanzabstimmung verlangen. Wenn die Abstimmung scheitert, verbleibt die Spezifikation in der Review-Phase.
Schritt 4: Abnahme
Wenn die Akzeptanz-Abstimmung positiv ausfällt, wird der Vorschlag offiziell zu einem akzeptierten Feature. Zu diesem Zeitpunkt wird die Arbeitsgruppe automatisch formell aufgelöst, aber der Beitrag des Herausgebers (oder einer nominierten Person, die dem Koordinator der Produktionsabteilung mitgeteilt wird) kann in Zukunft bei Tippfehlern, Änderungen oder Fehlern in der Spezifikation herangezogen werden.
Bei Feature-RfCs wird innerhalb der Produktionsabteilung ein Entwicklungsteam gebildet, dem in der Regel die Mitglieder der aufgelösten Arbeitsgruppe angehören.
Schritt 5: Implementierung
Ein implementiertes Feature ist ein Feature, das entwickelt, getestet und für die nächste verfügbare Haupt- oder Zwischenversion zusammengeführt wurde.
Projekt-Referendum
Der Bearbeiter eines Features in der Entwurfs- oder Revisionsphase kann jederzeit eine unverbindliche Abstimmung der Teamleiter der Produktionsabteilung über den aktuellen Status eines Features verlangen. Ein solches Referendum kann im Laufe der weiteren Entwicklung des Features mehrmals einberufen werden. Die Teamleiter der Produktionsabteilung können ein solches Referendum auch als Bedingung für eine Abnahmeabstimmung verlangen. Die Ergebnisse des Referendums sind nicht bindend, aber es wird erwartet, dass die Arbeitsgruppe und die Teamleiter der Produktion die Ergebnisse angemessen berücksichtigen.
Soweit die Pläne für den neuen Joomla GitHub Prozess. Er zeigt, wie man künftig an die Implementierung neuer Funktionen herangehen möchte. Was ist deine Meinung dazu? Ist das der richtige Ansatz, um wieder mehr Beteiligung im Core hinzubekommen? Oder ist das eher ein Bürokratiemonster, das die Umsetzung weiter verkompliziert und der Entwicklungsprozess zusätzlich verzögert? Bombardiere mich unten in den Kommentaren mit deinen Gedanken.
Quelle: magazine.joomla.org
