MediaWiki

Leser/Strukturierter Inhalt

< Readers
This page is a translated version of the page Readers/Structured Content and the translation is 100% complete.
Languages:

Das Team Strukturierter Inhalt in der Abteilung Wikimedia Produkt der Wikimedia Foundation konzentriert sich auf die Verbesserung der Medienqualität auf Wikimedia Commons, wozu die Verbesserung des Hochladeprozesses (wie Verbesserungen des Hochladeassistenten), das Erkennen potenziell problematischer Uploads und die Verbesserung der Medien-Metadaten gehören.

Team Strukturierter Inhalt
Das Team Strukturierter Inhalt in der Abteilung Wikimedia Produkt der Wikimedia Foundation konzentriert sich auf die Verbesserung der Medienqualität auf Wikimedia Commons.
Start: 2021-02-01
Team-Mitglieder: Mark Holmquist, Alexandra Ugolnikova, Marco Fossati, Matthias Mullie, Cormac Parle, Elena Tonkovidova, Sneha Patel, Luca Martinelli
Aufgabenliste: #Structured-Data-Backlog

Der bisherige Schwerpunkt lag auf der Entwicklung von Funktionen, die die Erstellung strukturierter Daten im Zusammenhang mit MediaWiki-Seiten ermöglichen und diese nutzen.

Projekte

Um dir die letzten wichtigen Änderungen und Veröffentlichungen dieses Teams anzusehen, besuche die Veröffentlichungszeitleiste.

Das Team konzentriert sich derzeit darauf, das aktuelle Benutzererlebnis mit dem Hochladeassistenten zu verbessern und ein Werkzeug zur automatischen Erkennung von Logos beim Hochladen auf Commons zu entwickeln.

Das Team konzentrierte sich zuvor (von August 2017 bis Dezember 2019) auf Strukturierte Daten auf Commons und dann (von Februar 2021 bis Juni 2023) auf das durch eine Förderung finanzierte Programm Strukturierte Daten in Wikimedia (SDAW).

Zu den Projekten im SDAW-Programm gehören:

Wir arbeiten hauptsächlich an den folgenden Erweiterungen:

Inaktive und semiaktive Projekte

Einige Mitglieder des Teams waren an der Entwicklung dieser Projekte beteiligt (als wir noch Multimedia-Team hießen). Sie sind derzeit nicht aktiv beteiligt, können aber möglicherweise helfen, wenn du eine Frage hast:

Team-Dokumentation

Teamprozesse / Arbeitsvereinbarungen

  • Wir liefern Funktionen schrittweise.
  • Wenn sich die Akzeptanzkriterien eines Phab-Tickets ändern (beispielsweise aufgrund einer Diskussion in den Kommentaren des Tickets), wird erwartet, dass die Ticketbeschreibung aktualisiert wird, um die Änderung widerzuspiegeln.

Phabricator-Boards

  • Das Structured Data Backlog Board ist unser primäres Backlog. Es wird vom Produktmanager und vom Programmmanager verwaltet.
  • Das Current Work Board dient der laufenden Entwicklung. Es wird vom gesamten Team verwaltet.
    • Jede Spalte des Current Work Board sollte nach Priorität sortiert sein, von der wichtigsten oben bis zur unwichtigsten unten. Tickets sollten automatisch am Ende einer Spalte hinzugefügt werden, es sei denn, sie sind dringend oder haben eine hohe Priorität. In diesem Fall können sie am Anfang hinzugefügt werden.
    • Zu den Spalten des Current Work Board gehören:
      • Incoming: Zu dem Board hinzugefügt Tickets werden hier automatisch hinzugefügt.
      • Epics: Spiegelt die großen Projekte wider, an denen das Team derzeit arbeitet.
      • Needs Design: Tickets, die Beiträge vom Designer erfordern.
      • Needs CL Input: Tickets, die Beiträge von der Verbindungsperson zur Community erfordern.
      • Ready for Estimation: Tickets, die eine Schätzung benötigen. Tickets werden in die Spalte Ready for Estimation verschoben, wenn ihr Entwurf und ihre Akzeptanzkriterien abgeschlossen sind und sie zur Bearbeitung bereit sind.
      • Ready for Development: Tickets, die zur Bearbeitung bereit sind.
      • Blocked: Tickets, die blockiert sind, von außerhalb des Teams oder bis andere Arbeiten abgeschlossen sind.
      • Doing: Tickets, die derzeit in Bearbeitung sind.
      • Design QA: Tickets, die die Genehmigung des Designers erfordern.
      • Code Review: Tickets, die eine Code-Prüfung erfordern.
      • Needs QA: Tickets, die eine QA in Beta erfordern.
      • Verify on Production: Tickets, die eine QA in der Produktion erfordern.
      • Deployment/Config: Tickets, die eine Einführung außerhalb des regulären Zeitplans erfordern.

Tägliche Arbeit

  • Gehe jeden Tag in den für dich relevanten Spalten und für die Tickets, für deren Bearbeitung du dich qualifiziert fühlst, wie folgt vor:
    • Arbeite die Spalten von rechts nach links ab:
      • soweit relevant, validiere die Dinge unter “Needs QA”;
      • überprüfe dann die Tickets unter “Code review”;
      • mache dann mit dem weiter, was du bereits unter “Doing” hast;
      • überprüfe dann, ob die Tickets unter “blocked” tatsächlich noch blockiert sind;
      • Nehme dann neue Arbeiten von oben unter “Ready for Development” auf.
  • Arbeite dich in jeder Spalte von oben nach unten vor und wähle das erste Ticket (mit der höchsten Priorität) aus, für dessen Bearbeitung du dich qualifiziert fühlst.
  • Aktualisiere alle Tickets, sobald du etwas tust, das den Status dieser Arbeit ändert, z. B.:
    • Sobald du die Arbeit aufnimmst, ordne dich zu und verschiebe in die entsprechende Spalte
    • Beim Zusammenführen eines Patches verschiebe das entsprechende Ticket aus “Code review”
    • Wenn du etwas tust, was nicht 100 % selbsterklärend ist (und das ist bei Aktionen selten der Fall), sollte jede durchgeführte Aktion von einem Kommentar zum Ticket begleitet werden.
  • Wenn Patches groß oder riskant sind, sollten die Ingenieure QA benachrichtigen und sie sowohl vor als auch direkt nach der Zusammenführung eine Überprüfung durchführen lassen.
    • Wenn QA nicht antwortet oder zu beschäftigt ist, um die Überprüfung durchzuführen, führe keine Zusammenführung durch. Wenn es dringend ist, benachrichtige das Programmmanagement oder das technische Management, um bei der Suche nach einer Lösung zu helfen.
  • Stelle sicher, dass den Ingenieuren eine klare Testskriptmethodik zur Verfügung steht, die sie vor allen Phasen durchgehen können: Codeüberprüfung, Einführung, QA.
    • Füge vor der Freigabe eines Patches zur Überprüfung einen QA-Abschnitt mit Akzeptanzkriterien und Tests hinzu, die ausgeführt werden sollen.
  • Priorisiere die Codeüberprüfung vor neuer Arbeit.

Reguläre Kommunikation

  • Führe Unterhaltungen, wenn möglich, in einem sichtbaren Slack-Kanal (z. B. #sd-eng oder #structured-data), damit andere sie bei Interesse mitverfolgen können.
  • Alle Ergebnisse oder Entscheidungen aus Gesprächen, die das Team betreffen, sei es öffentlich auf Slack oder an kleineren Orten, sollten öffentlich mit dem Team geteilt und im entsprechenden Phabricator-Ticket dokumentiert werden.
  • Standup (täglich außer Freitag):
    • Jedes Teammitglied veröffentlicht Standup-Notizen im Slack-Kanal #sd-standup. Standups sollten Neuigkeiten zu deiner Arbeit enthalten, die für andere Teammitglieder relevant sind, müssen aber nicht alles enthalten, was du an diesem Tag getan hast.
    • Zusätzlich zur Angabe, woran du arbeitest:
      • Gib alle relevanten Informationen weiter, die du erfahren hast und die in einem kurzen Update ohne zu viel Kontext übermittelt werden können. Z. B.:
        • “Team X hat Y gemacht, was uns bei Z helfen sollte”
        • “Die Einführung ist nicht erfolgt, daher ist unsere Funktion noch nicht live”
        • “Ich nahm am Treffen X teil und das Ergebnis war Y.”
    • Veröffentliche größere Unterbrechungen, sobald du diese kommunizieren kannst und noch einmal, wenn sie tatsächlich eintreten (z. B. Urlaub, längere Beschäftigung mit einem anderen Projekt, Elternzeit).

Slack-Kanäle
  • Kanalname: #sc-eng
    • Datenschutz: Privat
    • Zweck: Ein Ort, an dem SD-Ingenieure die technische Implementierung strukturierter Daten durch das Team besprechen können.
    • Publikum: Hauptsächlich SD-Ingenieure und QA. Andere können relevante Diskussionen verfolgen, sollten sich aber hauptsächlich im Hauptkanal #structured-data mit Ingenieuren austauschen.
  • Kanalname: #sc-search
    • Datenschutz: Privat
    • Zweck: Ein Kanal zur Diskussion des Projekts Suchverbesserung sowie aller Arbeiten und Themen, die zwischen den Teams für Strukturierte Daten und für die Suche ausgetauscht werden.
    • Publikum: SD- und Such-Ingenieure, QA, PM, PgM, Designer, Datenanalysten und Community Relations Specialists sowie Leiter in diesen Bereichen, die aktiv in die Teams eingebunden sind.
  • Kanalname: #sc-standup
    • Datenschutz: Privat
    • Zweck: Ein Ort, an dem alle Mitglieder des SD-Teams tägliche Neuigkeiten über ihre Arbeit veröffentlichen können, die für andere Teammitglieder relevant sind.
    • Publikum: Ingenieure des SD-Teams, QA, PM, PgM, Designer, Datenanalysten und CRS.
  • Kanalname: #structured-content
    • Datenschutz: Privat
    • Zweck: Allgemeine Gespräche über das Team für Strukturierte Daten und seine Arbeit.
    • Publikum: SD- und Such-Ingenieure, QA, PM, PgM, Designer, Datenanalysten und CRS; sowie Leiter in diesen Bereichen, die aktiv in die Teams eingebunden sind.
  • Kanalname: #image-suggestions-and-sections
    • Datenschutz: Offen für die WMF intern
    • Zweck: Ein teamübergreifender Kanal zur Diskussion der Projekte Bildvorschläge und Abschnittsthemen.
    • Publikum: Jeder bei der WMF, der interessiert ist, kann beitreten, aber es sollten hauptsächlich Leute aus den Teams sein, die an Abschnittsthemen und Bildvorschlägen arbeiten: SD, Suche, Wachstum, Android und PET.

Neue Tickets erstellen

  • Alle Mitglieder des Teams können jederzeit neue Tickets erstellen. Im Menü des Backlogs finden sich dazu Vorlagen.
  • Neue Tickets sollten mit der Markierung #structured-data-backlog gekennzeichnet werden. Dadurch werden sie in die Spalte “needs triage” des Backlogs eingefügt, damit sie bei der Backlog-Bereinigung berücksichtigt werden können.
  • Neue Tickets sollten eine Benutzergeschichte, möglichst viele Beschreibungen und Akzeptanzkriterien enthalten. Alles, was du zu diesem Zeitpunkt noch nicht weißt, kann später hinzugefügt werden, sollte aber vor der Schätzung hinzugefügt werden.
  • Wenn ein Ticket dringend ist, kann es direkt zum aktuellen Work Board in die entsprechende Spalte hinzugefügt werden, das Team sollte jedoch über Slack benachrichtigt werden.
  • Spin-off-Tickets, die im Wesentlichen Teil eines anderen Tickets sind (das bereits bearbeitet wurde), aber aus technischen Gründen separat verfolgt werden (z. B. wenn Änderungen über mehrere Erweiterungen hinweg erforderlich sind), können auch direkt zum aktuellen Work Board in der entsprechenden Spalte hinzugefügt werden. Wenn es sich jedoch um neue Arbeit handelt, sollten sie zum Backlog hinzugefügt werden und den Prozess durchlaufen. Spin-off-Tickets sollten keine Schätzung erfordern, da die Arbeit theoretisch Teil eines anderen Tickets ist, für das bereits eine Schätzung vorliegt.

Treffen

  • Backlog-Bereinigung (jeden Montag):
    • Anwesend sind der technische Leiter, Designer, QA (optional), PgM und PM.
    • Überprüfen jeder Spalte auf dem Current Work Board von rechts nach links, um zu sehen, ob aufgrund von Umständen oder Prioritäten etwas geändert werden muss. Wenn ja, Verschieben des Tickets und Informieren des Teams.
    • Überprüfen der Spalte “needs triage” im Backlog.
      • Sicherstellen, dass jedes Ticket die erforderlichen Details und vollständigen Akzeptanzkriterien enthält.
      • Besprechen der Priorität jedes Tickets und Verschieben jedes Ticket in der Reihenfolge seiner Priorität in die entsprechende Spalte im Backlog oder in “Needs Estimation” auf dem Current Work Board.
    • Diskussionen, die sich nicht auf die Tasks der Backlog-Bereinigung beziehen, sollten in diesem Treffen nicht geführt werden, da dies die Sichtbarkeit für das Team verringert.
  • Projekttreffen (jeden anderen Dienstag):
    • An diesem Treffen nimmt das gesamte Team teil.
    • Dieses Treffen dient dem Aufbau eines gemeinsamen Verständnisses und soll uns alle darüber informieren, wo wir gerade stehen und wie wir die nahe Zukunft erwarten. Dies ist eine großartige Gelegenheit, Fragen oder Probleme anzusprechen, bevor sie zu Hindernissen werden.
      • Weitere Themen dieses Treffens können der Austausch von Designs, die Diskussion einzelner Entscheidungen oder Ideen oder die Ausarbeitung von Akzeptanzkriterien für Tickets sein, die einer Diskussion bedürfen.
      • Jeder kann zum Tagesordnungsdokument, das in der Kalendereinladung verlinkt ist, Themen hinzufügen, die bei diesem Treffen besprochen werden sollen.
  • Retrospektive (jeden anderen Dienstag):
    • An diesem Treffen nimmt das gesamte Team teil.
    • Dieses Treffen dient dazu, Lob und Fakten oder Gefühle zu offenbaren, die das Team beeinflussen, und alle vorgeschlagenen Verbesserungen oder Lösungen zu besprechen. Die Retrospektive sollte sich auf umsetzbare Änderungen konzentrieren, was bedeutet, dass manchmal im Anschluss tiefergehende Gespräche stattfinden sollten.
  • Schätzungstreffen (jeden anderen Mittwoch):
    • Dieses Treffen wird genutzt, um Tickets in der Spalte “Ready for Estimation” zu schätzen.
    • Das Team schätzt die Tickets in der Spalte "Ready for Estimation" anhand der T-Shirt-Größe.
    • Nach der Schätzung werden Tickets in die Spalte Ready for Development verschoben. Standardmäßig werden Tickets an das Ende der Spalte Ready for Development verschoben, es sei denn, sie sind dringend oder haben eine hohe Priorität. In diesem Fall werden sie an den Anfang verschoben.
    • Wenn etwas dringender als alle zwei Wochen geschätzt werden muss, können wir eine asynchrone Schätzung auf Slack im Kanal #structureddata durchführen.
  • Sprechstunden (jeden anderen Mittwoch):
    • An diesem Treffen nehmen die Teamingenieure teil. Auch andere sind herzlich willkommen, wenn sie technische Themen diskutieren oder sich darüber informieren möchten.
    • Der Zweck dieses Treffens besteht darin, eine Plattform zur Diskussion technischer Themen zu haben.

Code-Review

Als allgemeine Richtlinie sollten Entwickler den Tag mit bis zu einer Stunde Code-Review beginnen.

Wenn etwas zur Überprüfung bereit ist, füge andere Entwickler als Reviewer hinzu. Wenn etwas nicht zur Überprüfung bereit ist, solltest du dies mit der Markierung [WIP] oder einem -1 kennzeichnen.

Aufgaben

Einrichten der Vagrant-Entwicklungsumgebung

Derzeit verwendet das Team für strukturierte Daten mediawiki-vagrant für den Großteil seiner Arbeit.

M1

git clone git@github.com:matthiasmullie/mediawiki-vagrant.git mw-vagrant
cd mw-vagrant
./setup.sh
vagrant config vagrant_ram 8192
vagrant up


# eventgate (unten als Abhängigkeit für eine andere Rolle installiert) erfordert eine andere Node-Version als die, mit der mw-vagrant ausgeliefert wird
vagrant hiera npm::node_version 10 && vagrant provision


# dies führt letztendlich dazu, dass eventgate einbezogen wird, das einige Abhängigkeiten aufweist, deren Kompilierung (möglicherweise) fehlschlägt; es funktioniert alles, aber der Fehler könnte sich auf andere Rollen auswirken, wenn sie gleichzeitig bereitgestellt werden
vagrant roles enable cirrussearch --provision


# uploadwizard (eigentlich titleblacklist, einer seiner Vertreter) kann nicht nach wikibase installiert werden, also machen wir das zuerst
vagrant roles enable uploadwizard --provision


# centralauth kann das Schema nicht installieren, was wir manuell tun werden, bevor andere Rollen fehlschlagen... vagrant-Rollen aktivieren centralauth --provision
# Hinweis: Es sieht so aus, als ob dieser Fehler nicht mehr zutrifft und folgendes nicht mehr benötigt wird
# vagrant ssh
# cat /vagrant/mediawiki/extensions/CentralAuth/schema/mysql/tables-generated.sql | sql centralauth
# exit # vagrant


# Zuerst werden wikidata und mediainfo installiert
vagrant roles enable commons mediainfo wikibase_repo wikidata --provision


# installiere wb_items_per_site für alle Wikis
vagrant ssh
sed -i -i 's/, ips_site_page/, ips_site_page(200)/'
/vagrant/mediawiki/extensions/Wikibase/repo/sql/mysql/wb_items_per_site.sql
/usr/local/bin/foreachwiki maintenance/patchSql.php
/vagrant/mediawiki/extensions/Wikibase/repo/sql/mysql/wb_items_per_site.sql
sed -i -i 's/, ips_site_page(200)/, ips_site_page/'
/vagrant/mediawiki/extensions/Wikibase/repo/sql/mysql/wb_items_per_site.sql
exit # vagrant


# erstelle Konto auf commonswiki; mit diesem Konto auf wikidatawiki anmelden; dann Administrator-Berechtigungen über Wartungsskript vergeben
vagrant ssh
mwscript createAndPromote.php --wiki=commonswiki --sysop --force USERNAME password
mwscript createAndPromote.php --wiki=wikidatawiki --sysop --force USERNAME password
exit # vagrant


# Die restlichen Rollen installieren
vagrant roles enable commonsmetadata echo eventlogging kartographer mediasearch mobilefrontend multimediaviewer uls wikibasecirrussearch wikimediaevents --provision

Intel Mac

Retrieved from "https://www.mediawiki.org/w/index.php?title=Readers/Structured_Content/de&oldid=6907768"