Fehlerbehebungen

Fehlerbehebungs-Sitzungen werden im gesamten WordPress-Projekt durchgeführt, um Trac-Tickets schnell zu überprüfen und die nächsten Schritte zu bestimmen. CoreCore Core ist die Software, die zum Ausführen von WordPress erforderlich ist. Das Core-Entwicklungsteam entwickelt WordPress.-Performance-Fehlerbehebungs-Sitzungen können jederzeit von jedem Teammitglied abgehalten werden. Das Core-Performance-Team hält jedoch alle 2 Wochen eine planmäßige Fehlerbehebungs-Sitzung ab, und zwar mittwochs . Die aktuelle Uhrzeit des Meetings ist immer im Meeting-Kalender angegeben.

Fehlerbehebungs-Sitzungen sind informelle Meetings und erfordern weder die Veröffentlichung einer Tagesordnung im Voraus noch einer Zusammenfassung im Anschluss.

Verantwortlichkeiten und Zugriffsrechte

Jeder kann eine Fehlerbehebungs-Sitzung veranstalten. Um die reguläre planmäßige Fehlerbehebungs-Sitzung zu veranstalten, trage deinen WordPress.orgWordPress.org Die Community-Website, auf der WordPress-Code von den Benutzern erstellt und geteilt wird. Hier kannst du den Quellcode für WordPress Core, Plugins und Themes herunterladen. Außerdem ist dies der zentrale Ort für Gespräche und die Organisation der Community. https://wordpress.org/-Benutzernamen in einem der freien Meeting-Zeitfenster in der Tabelle der Hosts für Fehlerbehebungs-Sitzungen ein. Die Repräsentanten des Core-Performance-Teams sind dafür verantwortlich, sicherzustellen, dass kommende Meetings einen zugewiesenen Host haben. Wenn für ein bevorstehendes Meeting noch kein Host eingetragen ist, sollten sie im Kanal #core-performance um Freiwillige bitten.

Für das Veranstalten einer Fehlerbehebungs-Sitzung gibt es außer einem WordPress.org-Konto und einem WordPress-SlackSlack Slack ist eine Plattform für kollaborative Gruppenchats https://slack.com/. Die WordPress-Community hat ihren eigenen Slack-Kanal unter https://make.wordpress.org/chat/-Konto keine technischen Voraussetzungen. Idealerweise hast du Zugriff auf den Befehl /here im Kanal #core-performance auf Slack, aber dies ist keine Voraussetzung.

Du kannst gerne nach eigenem Ermessen eine Fehlerbehebungs-Sitzung veranstalten. Die zweiwöchentlich stattfindenden Fehlerbehebungs-Sitzungen dienen ausschließlich dazu, einen regelmäßigen Rhythmus sicherzustellen. Weitere Fehlerbehebungs-Sitzungen sind jedoch jederzeit willkommen und werden geschätzt.

Durchführung der Fehlerbehebungs-Sitzung

Eine Fehlerbehebungs-Sitzung des Core-Performance-Teams ist kein Meeting im herkömmlichen Sinne. Das Format besteht darin, dass der Host der Fehlerbehebungs-Sitzung – bei jeder planmäßigen Sitzung eine andere Person – ein bestimmtes WordPress-Core-TracTrac Trac ist der Ort, an dem Mitwirkende Probleme zu Fehlern oder Funktionsanfragen erstellen, ähnlich wie bei GitHub.https://core.trac.wordpress.org/.-Ticket oder einen Performance-Lab-Issue-„Report“ bearbeitet. Es handelt sich um ein informelles Meeting mit flexibler Struktur.

Ein Report ist eine Liste bestimmter Trac-Tickets bzw. GitHubGitHub GitHub ist eine Website, die die Online-Implementierung von Git-Repositorys anbietet, die von anderen Entwicklern einfach geteilt, kopiert und verändert werden können. Öffentliche Repositorys können kostenlos gehostet werden, für private Repositorys ist ein kostenpflichtiges Abonnement erforderlich. GitHub führte das Konzept des „Pull Requests“ ein, bei dem von Mitwirkenden vorgenommene Codeänderungen in Branches vom Besitzer des Repositorys überprüft und diskutiert werden können, bevor sie zusammengeführt werden. https://github.com/-Issues, die über eine URLURL Eine bestimmte Webadresse einer Website oder Webseite im Internet, beispielsweise die URL einer Website: www.wordpress.org öffentlich mit anderen geteilt werden können. Einige Beispiele:

• Performance-Tickets für WordPress 7.0, sortiert nach der am längsten zurückliegenden Änderung
• Performance-Tickets mit einem Patch, die für eine zukünftige Version vorgesehen sind, sortiert nach der zuletzt erfolgten Änderung
• Performance-Tickets, die auf eine Überprüfung warten, sortiert nach dem neuesten Erstellungsdatum
• Performance-Tickets, die auf eine Überprüfung warten, sortiert nach der am längsten zurückliegenden Änderung
• Performance-Tickets mit der Kennzeichnung „guter erster Fehler“, sortiert nach dem neuesten Erstellungsdatum
• Performance-Lab-Issues mit Meilensteinen für eine der nächsten Versionen, sortiert nach dem neuesten Erstellungsdatum
• Performance-Lab-Issues mit der Kennzeichnung „guter erster Issue“
• Performance-Lab-Issues, sortiert nach der am längsten zurückliegenden Aktualisierung

Der Host der Fehlerbehebungs-Sitzung sollte einen Report auswählen, den er bearbeitet (entweder aus der obigen Liste oder einen anderen relevanten Performance-Report), und die entsprechende URL auf Slack teilen. Anschließend sollte der Host alle Anwesenden dazu ermutigen, die relevanten Tickets später asynchron zu überprüfen und bei Bedarf einen weiteren Kommentar zu hinterlassen, wenn es Fragen oder Bedenken zu einer vom Host getroffenen Entscheidung gibt.

Als Hauptbestandteil der Fehlerbehebungs-Sitzung sollte der Host anschließend die Tickets bzw. Issues im Report selbstständig bearbeiten und für jedes bearbeitete Ticket eine Aktualisierung bereitstellen. Dies kann beispielsweise das Ändern des Meilensteins, der Priorität, der Zuständigkeiten oder der Schlagwörter sowie das Anfordern einer Aktualisierung vom Melder oder Autor des Pull Requests umfassen.

Der Host der Fehlerbehebungs-Sitzung kann auch alles, was er für wertvoll hält, im Slack-Kanal teilen. Da es sich bei der Fehlerbehebungs-Sitzung jedoch nicht um ein herkömmliches Meeting handelt, besteht keine Notwendigkeit, auf Beiträge anderer möglicherweise anwesender Personen zu warten.

Idealerweise sollte jede Fehlerbehebungs-Sitzung mindestens etwa eine Stunde dauern, wobei der Host selbstverständlich gerne weitermachen kann. Sobald er keine Tickets mehr überprüft, sollte er diese Aktualisierung auf Slack teilen und damit seine Fehlerbehebungs-Sitzung offiziell beenden.

Beispielnachrichten

Du kannst diese Nachrichten gerne kopieren und einfügen oder sie ignorieren und eigene Nachrichten verfassen. Diese Beispiele dienen nur als Referenz und sind keinesfalls als Richtlinie gedacht oder zwingend zu verwenden.

Beginn der Fehlerbehebungs-Sitzung

• /here Hallo zusammen! Ich beginne gleich mit einer auf Performance ausgerichteten <bug-scrub>.
• Heute werde ich die Tickets im folgenden Report bearbeiten: <report-url>
• Ich werde beim Durchgehen der Liste jedes Ticket aktualisieren oder kommentieren.
• Wenn du gerade Zeit hast, kannst du diese Tickets gerne ebenfalls überprüfen und deine Gedanken teilen. Du kannst dies entweder als Antwort auf meine Ticket-Aktualisierung tun oder – falls es sich um ein Ticket handelt, das ich noch nicht erreicht habe – bereits einen Ticket-Kommentar hinterlassen oder direkt hier im Kanal eine Chatnachricht senden.

Ende der Fehlerbehebungs-Sitzung

• Das war’s für die heutige Fehlerbehebungs-Sitzung. Bitte denke daran, dass jeder jederzeit eine solche Fehlerbehebungs-Sitzung durchführen kann. Melde dich gerne, wenn du Fragen hast.
• Vielen Dank an alle, die dabei waren, und bis in 2 Wochen!
• </bug-scrub>