Der Weg eines nicht-technischen Release-Leads zum Mentor für die WordPress-Core-Entwicklung

Im Sommer 2019 wurde ich gebeten, bei einem WordPress-Release mitzuhelfen. Einige Monate zuvor haben sich die Vertreter des Kernteams an andere Teams gewandt, um die Diversität der Veröffentlichungsteams zu erhöhen, und ich habe begonnen, ernsthaft darüber nachzudenken.

Zu dieser Zeit war ich bereits stark in das WordPress-Ökosystem involviert und war in meinem zweiten Jahr als WordPress Community- und Partnerschaftsmanager bei SiteGround, aber ich hatte keinerlei Erfahrung damit, wie WordPress aus Core-Sicht gemacht wird. Als Josepha Haden, Executive Director von WordPress.org, mich jedoch anpingte, sagte ich ohne zu zögern zu. Und es erwies sich als eine der herausforderndsten und lohnendsten Erfahrungen meines Lebens. Hier ist, wie.

Ein versehentlicher Mitwirkender: Mein Weg in der Technik

Schon früh schien ich prädestiniert dafür, Entwickler zu werden. Meine Eltern sind Programmierer, sie haben in den sechziger Jahren angefangen, und ich habe 1982 meinen ersten Personal Computer bekommen, als die Leute in Italien noch nicht wirklich eine Vorstellung davon hatten, was das ist.

Ich folgte ihrem Arbeitsethos und fand ihren Job faszinierend, eine Maschine dazu zu bringen, das zu tun, was Sie wollen, aber ich fühlte mich zu anderen Karrieremöglichkeiten hingezogen. Eigentlich wusste ich nicht wirklich, was ich tun wollte, als ich aufwuchs, aber Computer und Websites waren nach wie vor ein großer Teil meines Privat- und Berufslebens.

Während mich Backend-Programmierung nie interessierte, nahm ich 1999 einen Kurs in Webdesign und schrieb mich 2004 für einen Abschluss in Kunst und Multimedia ein. 2008 fand ich schließlich WordPress und begann, meinen Lebensunterhalt damit zu verdienen es im Jahr 2010.

Bald erkannte ich, dass meine wahre Fähigkeit darin bestand, Kunden, die mit einer Anfrage für eine Website zu mir kamen, dabei zu helfen, sich besser auf ihr „Warum“ für die Website zu konzentrieren und über ihre Geschäfts- und Marketingstrategie nachzudenken, bevor sie mich anstellten. Ich habe Bücher über Unternehmensplanung, Produktivität und Websites geschrieben. Ich fing auch an, Vorträge auf WordCamps und anderen Veranstaltungen zu halten, um Freiberufler über diese Themen aufzuklären.

Im Jahr 2015 traf ich zufällig einige Leute, die in der WordPress-Community involviert waren, was mich dazu veranlasste, ebenfalls mitzuwirken. Ich hatte keine Entwicklungsfähigkeiten, also hätte ich nie gedacht, dass ich zu OSS beitragen könnte, aber es stellte sich heraus, dass das unnötig war. Ich traf Leute, die mich auf die vielen verschiedenen Teams aufmerksam machten, die WordPress machen, und begannen, zuerst in Polyglots und später in der Community aktiv zu werden.

Ich arbeitete weiter an meinem Geschäft, aber je mehr ich zu WordPress beitrug, desto mehr wollte ich einen Weg finden, Tausenden von Menschen gleichzeitig zu helfen. Meine Outreach-Bemühungen, Vorträge zu halten, Community-Organisatoren zu helfen und Inhalte zu schreiben, müssen skaliert werden.

Hier traf ich SiteGround. Im Sommer 2017 suchten sie einen Community Manager und obwohl ich von Beruf keiner bin, beschloss ich, mich zu bewerben und bekam den Job. Der Beitritt zum Unternehmen ermöglichte es mir, Zeit gesponsert zu haben, um zu WordPress beizutragen. Es ermöglichte mir auch, auf das kollektive Wissen meiner Kollegen zurückzugreifen, wenn ich anfange, neue Ideen für das Projekt zu entwickeln.

Also habe ich ohne Zögern ja gesagt, aber die Wahrheit ist, dass dieses Ja fast fünf Jahre gedauert hat. Außerdem hatte ich das Gefühl, dass Josepha und SiteGround mir vertrauten, dass ich gute Arbeit mache. Im Gegenzug vertraute ich der WordPress-Community, dass sie mir dabei helfen würde, all die Dinge herauszufinden, die ich lernen musste.

Wie WordPress fertig wird

Der andere erfreuliche Faktor war, dass seit WordPress 5.0 ein Release nicht mehr von einer Person gemacht wurde, wie es früher jahrelang der Fall war, oder von einer Person mit ein paar Stellvertretern. Jetzt war ein ganzes Team am Werk, das liebevoll „die Truppe“ genannt wird, also sind viele Hände an Deck.

Viel Kommunikation

Während eines Release-Zyklus findet viel Kommunikation statt. Es gibt Blogbeiträge von verschiedenen Make-Teams. In jeder Phase der Veröffentlichung gibt es Blog-Posts im News-Bereich von WordPress.org. Im öffentlichen Slack-Kanal wird ständig geredet, und es gibt einen privaten Kanal, der das Sicherheitsnetz für neue Leute darstellt, die sich anfangs möglicherweise eingeschüchtert fühlen, wenn sie in einem großen öffentlichen Kanal Fragen stellen.

Die verschiedenen Rollen im Release Squad

Was ich am meisten an diesem Modell für die Veröffentlichung liebe, ist die Vielfalt der Rollen, die es beinhaltet. Es gibt Entwickler, Designer, Marketingspezialisten, technische Redakteure und Projektmanager. WordPress besteht nicht nur aus Code, und es ist großartig zu sehen, wie all diese verschiedenen Fähigkeiten zusammenkommen, um zu seiner Veröffentlichung beizutragen.

Die Rolle des Release-Koordinators (die ich für WordPress 5.3 und 5.4 abgedeckt habe) und des Triage-PM (Rolle, die von dem hervorragenden David Baumwald für 5.3, 5.4 und 5.5 übernommen wurde) besteht darin, zu versuchen, ein Auge auf alle zu haben bewegliche Teile. Und ich sage versuchen, weil es fast unmöglich ist. Aus diesem Grund gibt es Fokus-Leads für die verschiedenen Teile, an denen gearbeitet wird.

Matt Mullenweg ist der Projektleiter und seit WordPress 5.0 der Release Lead. Er erstellt die High-Level-Roadmap und die Fokusprojekte. Darüber hinaus ist er jedoch nicht in das tägliche Leben der Core-Entwicklung involviert. In über einem Jahr, in dem er an Core-Releases beteiligt war, bat Matt nur einmal darum, eine Funktion hinzuzufügen.

Ich ärgere mich, wenn Leute denken, dass alles, was in WordPress passiert, passiert, weil Matt es so will. Es verringert die Rolle aller Menschen, die sich um das Projekt kümmern und es auf sich nehmen, die Dinge voranzubringen, sich um Probleme zu kümmern, sich für Tickets einzusetzen und sich im Allgemeinen dazu zu verpflichten, dazu beizutragen, WordPress für alle besser zu machen, ganz gleich, ob sie es tun es für ein Ticket oder arbeite Vollzeit daran.

Komponentenbetreuer und Core Committer

Eine Gruppe von Personen, die maßgeblich an der Gestaltung einer Veröffentlichung beteiligt sind, sind die Komponentenbetreuer. Sie sind dafür verantwortlich, sich um eine bestimmte Komponente zu kümmern, aus der Core besteht, und zu sehen, wie Tickets in diesem Bereich ablaufen. Sie sind diejenigen, die beurteilen können, ob ein Ticket zum Zusammenführen bereit ist.

Sobald ein Ticket als fertig gilt, betreten Core Committer die Szene. Sie führen eine abschließende Überprüfung des Tickets durch. Sie können einige Änderungen anfordern oder die Änderungen beim Festschreiben selbst vornehmen. Das hat mich wahrscheinlich am meisten überrascht. Ich hätte wirklich nicht gedacht, dass ein Commit Stunden dauern kann, aber das kann es definitiv. In den Releases, die ich koordiniert habe, habe ich definitiv nicht viel Engagement von Betreuern und Committern beobachtet, und das ist sehr demotivierend für Leute, die an Tickets arbeiten. Nicht alles kann in eine Veröffentlichung einfließen, selbst wenn der Patch fertig ist, weil es nicht genug Leute gibt, die es überprüfen, Feedback geben und schließlich einschreiben können. Mit wenigen Ressourcen müssen Sie Entscheidungen treffen, und diese werden nicht immer mit den Präferenzen jedes WordPress-Benutzers oder Mitwirkenden übereinstimmen.

Dies ist wahrscheinlich eine der größten Herausforderungen, die WordPress in Zukunft bewältigen muss: Wie können wir Menschen reaktivieren, die eine große Hilfe leisten können?

Die Release-Party

Trotz dieser Probleme werden die Dinge erledigt und wenn die Veröffentlichung fertig ist, feiern wir mit einer Party. Ich weiß nicht, wer angefangen hat, sie Release Parties zu nennen, oder wann sie angefangen haben. Was ich weiß, ist, dass ich für 5.3 und 5.4 ziemlich viele gehostet habe und sie alle eine Menge Spaß gemacht haben.

Am Tag eines der Veröffentlichungsschritte (es können Betas, Release Candidates oder General Release sein) wird der Core-Kanal sehr aktiv: Viele Leute kommen online, um zu sehen, wie die Version von WordPress veröffentlicht wird. Es gibt mehrere Schritte und verschiedene Personen, die an verschiedenen Aufgaben beteiligt sind. Die Veröffentlichungsschritte sind im Core-Handbuch dokumentiert und werden öffentlich verfolgt, sodass jeder sie alle sehen kann.

Die größte Party ist der allgemeine Veröffentlichungstag; Es gibt einen bestimmten Moment, der unglaublich kraftvoll ist. WordPress hat einen Download-Zähler, also macht das Team vor der Veröffentlichung der neuen Version einen Screenshot der vorherigen, wir verabschieden uns alle und begrüßen das neue Kind. Obwohl alles virtuell ist, ist dieser Moment fast greifbar und wird mich immer wieder bewegen. Wir haben wieder WordPress gemacht.

12 Monate als Core Contributor

Während ich diesen Artikel schrieb, fiel mir ein, dass ich seit einem Jahr Core-Contributor bin. Ich habe immer noch meine Vollzeitrolle bei SiteGround, die ich manchmal schwer zu jonglieren fand, also muss ich meinem Team für ihre Unterstützung Anerkennung zollen.

Ich kann immer noch kein PHP schreiben und verachte JavaScript zutiefst, aber wenn ich zurückblicke, bin ich unglaublich stolz auf die Veränderungen, die in den letzten 12 Monaten passiert sind. Ich kann nicht alle loben, aber ich bin froh, dass ich irgendwie ein Teil von ihnen sein konnte.

Release-Zeitplan

Eine Sache, nach der viele Mitwirkende gefragt haben, war ein mittelfristiger Zeitplan für Veröffentlichungen, um sie besser an ihre Arbeit und ihren persönlichen Kalender anzupassen. Ein Neuling zu sein, kann schwierig sein, weil man nicht die ganze Geschichte und den Hintergrund kennt, warum Dinge auf eine bestimmte Weise gemacht werden, aber das ist auch ein Vorteil. Es steht Ihnen frei, Gespräche neu zu starten. Nachdem ich es mit dem Kader und anderen Teams besprochen hatte, war mir klar, dass es nur darum ging, „wer wird das mit Matt ansprechen“. Und das tat ich. Ein paar Tage später wurde ein vorläufiger Veröffentlichungsplan bis WordPress 6.0 im Core-Blog veröffentlicht, und wir verwenden es seitdem.

Größeres Release Squad und Mentoring

Auch der Release-Kader wird mit jedem Release größer. Viele Teams sind daran beteiligt und davon betroffen. Es ist wichtig, dass alle diese Teams in dem Prozess vertreten sind. In WordPress 5.5 gibt es mehrere neue Rollen, und in 5.6 werden es noch mehr sein: Test, Dokumentation, Support sind alles wichtige Komponenten dessen, was WordPress großartig macht, daher ist es wichtig, ihr Feedback zu haben, während sich die Software in der aktiven Entwicklung befindet.

Und es ist wichtig, Mentoren zu haben. Dies ist eine wesentliche Verbesserung, die Josepha in WordPress 5.3 eingeführt hat. Das Release-Team besteht nicht nur aus Fokus-Leads, sondern es gibt eine wachsende Gruppe von Mentoren, die neuen Mitwirkenden helfen können, sich einzuarbeiten. Die Idee ist, dass diese Leute schließlich Mentoren werden und neue Leute unterrichten. Dies ist eine weitere großartige Möglichkeit, mehr und mehr Menschen mit unterschiedlichen Fähigkeiten und Hintergründen in Core einzubeziehen.

Und das bringt mich zur größten Veränderung (und Herausforderung) von allen. WordPress 5.6, das sich zu einer massiven Veröffentlichung entwickelt, wird einen Kader haben, der ausschließlich aus Frauen und Menschen besteht, die sich als weiblich identifizieren. Wie viele Dinge in WordPress begann alles mit einem „lauten Denken“-Moment und ist jetzt Realität. Die Arbeit an dieser Version wird sehr bald beginnen, und ich freue mich darauf, als Mentor dabei zu sein.

WordPress braucht Ihre Hilfe

Ich wünschte, ich könnte sagen, es sind alles Einhörner und Regenbögen, aber das ist es nicht. Die Zahl der Menschen, die aktiv an der Verwirklichung dieses Projekts beteiligt sind, ist im Vergleich zu seiner Reichweite noch sehr gering.

Ich bin ein Macher, also wünsche ich mir, dass sich die Leute die Zeit und Energie nehmen, die sie aufwenden, um WordPress zu kritisieren, und sie in aktive Beitragszeit umwandeln. Ja, manchmal muss man bei einem Ticket sehr hartnäckig sein und es unerbittlich weiterverfolgen, aber ich denke trotzdem, dass es sich lohnt.

Aktive Teilnahme bedeutet auch, konstruktives Feedback in Tickets zu hinterlassen oder anzubieten, sich während des Entwickler-Chats Notizen zu machen. Das ist der Fluch und die Schönheit eines gewaltigen Projekts. Es gibt immer was zu tun!

In den letzten Jahren habe ich auch einen Anstieg des Beitrags von verschiedenen Arten von Unternehmen gesehen. Bei SiteGround zum Beispiel haben wir jahrelang hauptsächlich zu Veranstaltungen und der Community beigetragen. Wir haben gesponsert und uns ehrenamtlich gemeldet, wir waren Organisatoren und Redner. Wir haben viel in der spanischen WordPress-Community gearbeitet, um sie bei ihrer Entwicklung und ihrem Wachstum zu unterstützen, und jetzt ist sie eine der größten in der globalen Community. Im letzten Jahr haben wir die Stunden erhöht, die wir eher technischen Teams widmen. Ich bin immer noch in Core als Mentor und als Teamvertreter aktiv. Einer unserer WordPress-Ingenieure, Stanimir Stoyanov, ist Teil des Sicherheitsteams, und einer unserer JavaScript-Ingenieure, Kiril Zhelyazkov, widmet Gutenberg jetzt ein paar Tage pro Woche.

Diese Themen stimmen mit unseren Werten überein, daher war es für uns eine natürliche Weiterentwicklung, uns stärker zu engagieren.

Schließlich hoffe ich, dass sich Leute an einem Vorschlag beteiligen, den ich vor ein paar Tagen im Core-Blog über End-to-End-Tests veröffentlicht habe. Im Moment gibt es einen, und ich bin sicher, wir können es besser machen. Auch hier sind Entwickler nicht die einzigen, die benötigt werden. Benutzer sind die seltensten Mitwirkenden und wahrscheinlich diejenigen, die das Projekt am meisten braucht, um endlich einige Benutzertests durchzuführen. Ich bin kein Entwickler und freue mich, dass Nicht-Entwickler etwas bewirken können.

Meine persönlichen Bedenken und Hoffnungen für die Zukunft des Projekts

Als ich anfing, einen Beitrag zu Core zu leisten, habe ich auf meinem Computer eine Notiz mit einigen Beobachtungen erstellt. Keine 17 Jahre Erfahrung im Projekt zu haben, hilft mir, die Dinge unvoreingenommen zu sehen, und kein Entwickler zu sein, hilft mir, das Projekt eher als einen lebendigen, atmenden Körper zu sehen, anstatt als Komponenten oder Tickets. Erlauben Sie mir, meine Sorgen, Hoffnungen und Träume für die Zukunft mitzuteilen.

Komponentenbetreuer und Core Committer: Sie werden mehr denn je gebraucht

Zum Zeitpunkt des Schreibens dieses Artikels hat das Projekt etwa 60 Committer und 60 Komponentenbetreuer, wobei viele Leute doppelte, dreifache und manchmal sechsfache Aufgaben übernehmen. Aber die Realität ist, dass in WordPress 5.4 und 5.5 Hunderte von Commits von Sergey Biryukov vorgenommen wurden. Ich bin unglaublich dankbar für Sergeys Arbeit. Gleichzeitig habe ich das Gefühl, dass wir versehentlich einen Busfaktor in Core einbauen. Die Mehrheit der Personen mit Core Commit-Zugriff hat kein einziges Ticket festgeschrieben. In ähnlicher Weise habe ich mich an alle Komponentenbetreuer gewandt, um von ihren Plänen für die kommenden Versionen zu erfahren, und nur etwa 50 % der Komponenten haben geantwortet.

Wie stellen wir sicher, dass die Menschen, die die Befugnis und damit die Verantwortung haben, beim Festschreiben und Verwalten von Tickets zu helfen, einbezogen werden? Aber auch, wie ermutigen wir Leute, zurückzutreten und sich für inaktiv zu erklären, damit neue Leute aufsteigen können?

Meine Karriere erstreckt sich über mehr als 25 Jahre in verschiedenen Branchen, und eines bleibt gleich: Wenn die Leute sehen, dass jemand anderes eine Rolle ausfüllt, sind sie weniger motiviert und manchmal sogar eingeschüchtert, sich zu engagieren. Knappheit fördert nicht nur Käufe, sondern auch neue Interaktionen.

Das Community Team beispielsweise pflegt eine Liste der Stellvertreter und ihrer unterschiedlichen Status. Ich habe mich gefragt, ob Core etwas Ähnliches tun könnte, damit neue Leute, die aufsteigen wollen, auf den ersten Blick sehen können, bei welchen Komponenten Betreuer fehlen. Leute, die sich über „The Core Developers“ beschweren, werden sie nicht als Blob sehen, sondern als Individuen, die zu irgendeinem Zeitpunkt für eine gewisse Zeit inaktiv sein können. Wenn Sie sehen, dass es tatsächlich nur wenige Leute gibt, die aktiv prüfen und sich verpflichten, verstehen Sie vielleicht eher, warum nicht jedes Ticket es bis zur Ziellinie schafft.

Dokumentation ist die höchste Form der Großzügigkeit

Ich sage dies jedes Mal, wenn ich über einen Beitrag zu OSS spreche: Dokumentation fehlt häufig. Was da ist, ist oft veraltet.

Wie stellen wir sicher, dass die Dokumentation kein nachträglicher Einfall ist, sondern in den Entwicklungsprozess integriert wird?

Es wird viel Arbeit in das Schreiben von Entwicklungsnotizen für die Änderungen gesteckt, die sich auf die Entwicklung auswirken, aber das ist nicht die einzige Dokumentation, die benötigt wird. Einige der in den Core-Handbüchern beschriebenen Prozesse sind veraltet, andere fehlen, weil sie in den Köpfen erfahrener Mitwirkender leben.

Als großer Fan von Gutenberg und reichhaltigem, ansprechendem Text wünsche ich mir, dass unsere Handbücher die Leistungsfähigkeit des Blockeditors voll ausschöpfen und einladender wären. Im Moment sind sie eine Wand aus Text und immer wenn wir den Leuten sagen, sie sollen sich die Handbücher ansehen, fühle ich, wie mein Herz zusammenschrumpft.

Mögliche Lösungen, von denen ich nicht sicher bin, ob sie technisch machbar sind, aber ein Mädchen kann träumen: Synchronisieren Sie mit GitHub, um zumindest das Versionskontrollproblem zu lösen. Dann rekrutieren, rekrutieren, rekrutieren und arbeiten Sie mit Dokumentation, Meta und Design, um nützliche, ansprechende, lesbare und leicht zu scannende Handbücher bereitzustellen.

Behalten Sie den Überblick über die beweglichen Teile und arbeiten Sie als Einheit

Die andere Sache, die mir oft auffällt, ist, wie Teams, Schwerpunkte und Komponenten in Silos arbeiten.

Das ist absolut kein Torwächter, sondern jedes Team hat sich über die Jahre selbst organisiert.

Wir müssen einen Weg finden, aus der Vogelperspektive zu sehen, was in die nächste Version kommt und was all die beweglichen Teile sind.

Trac ist sehr granular und Sie haben eine Reihe von vorgefertigten Berichten, Sie können nach Meilensteinen filtern und sehen, wie viele Tickets sich in jeder Komponente befinden, aber das ist nur ein Teil der Geschichte.

Ja, ich spreche davon, einen Weg zu finden, das Projekt als Ganzes und nicht als Kleinigkeiten zu verwalten.

Geben Sie GitHub ein. Irgendwann.

Dies wird nicht so schnell passieren, aber ich hoffe, dass es irgendwann passieren wird. Verlagern Sie die Entwicklung und das Projektmanagement von WordPress auf GitHub, wie es Gutenberg getan hat.

Ich weiß, dass es für viele ein Anreiz sein wird, auf eine vertrautere Weise zu WordPress beizutragen. Es wird die Messlatte zum Eingang senken, was immer willkommen ist. Mit einigen praktischen Tutorials wird es technisch nicht versierten Personen ermöglicht, zur Dokumentation, zum Testen und zum Projektmanagement beizutragen.

Die Zukunft ist strahlend

Trotz all der Probleme, oder vielleicht gerade wegen ihnen, sieht die Zukunft von WordPress rosig aus.

Ich habe mich in diesen Jahren in mehreren Teams umgesehen, und in letzter Zeit bemerke ich, dass mehr Leute an Bord kommen, mehr Leute an jeder Veröffentlichung beteiligt sind, mehr Leute in Führungsrollen in verschiedenen Teams aufsteigen. Ich bemerke auch eine Zunahme der Vielfalt, was immer eine willkommene Abwechslung ist.

Fazit: WordPress braucht uns alle, um es zu verwirklichen. Ich hoffe, Sie an Bord zu sehen!