Wikipedia:Technik/Phabricator

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Wikipedia:Bugs)
Zur Navigation springen Zur Suche springen

Phabricator


Phabricator ist ein seit 2014 schrittweise eingeführtes integriertes Verwaltungssystem für die Software-Entwicklung bei MediaWiki. Mit dem System sollen bisher von unterschiedlichen Softwareprodukten unterstützte Aufgaben zusammengeführt werden. Die Startseite ist phab: (phab: und Phabricator: sind Interwikis). Die Arbeitssprache ist Englisch.

Zu den Funktionalitäten gehört:

  • Ein Bugtracker.
    • Damit werden vermutete Fehler in der weltweiten Software gemeldet.
    • Bis 22. November 2014 wurde dafür Bugzilla verwendet.
  • Quellcodes der aktuellen MediaWiki-Software und alle früheren Zwischenversionen zeigen (früher einmal „SVN“).
  • Die Kontrolle über Veränderungen an der wirksamen Software (zurzeit „Gerrit“, in manchen Bereichen mittels „GitLab“).
  • Aufgabenmanagement allgemein (Bugfixing ist nur eine Aufgabe davon).
    • Vereinheitlichte Kommunikationsplattform für alle Aspekte der Software-Entwicklung.
    • Feature-Requests

Die Mutterversion der Phabricator-Software wird nicht mehr weiterentwickelt. Auf die stabil laufende Installation bei MediaWiki hat das jedoch keinen Einfluss.

Anlaufstellen für Wikipedia-Autoren

[Quelltext bearbeiten]

Wenn du meinst, ein Software-Problem identifiziert zu haben, kannst du dich auch an die Technik-Werkstatt wenden. Es muss geklärt werden, ob es nicht in der deutschsprachigen Wikipedia verursacht wurde; Phabricator kann nur für die weltweit eingesetzte Software genutzt werden. Auch könnte dein Benutzerskript, ein Helferlein oder dein Browser das Problem verursacht haben. Wenn gesichert ist, dass es sich um einen Bug auf weltweiter Ebene handelt, ist man dort in der Regel so kollegial und schreibt eine formvollendete Meldung.

Wenn du Anregungen für zukünftige Änderungen hast, kannst du die folgenden Seiten nutzen:

Aufgabenmanagement

[Quelltext bearbeiten]

Neben der Quellcode-Verwaltung ist dies der eigentliche Hauptzweck von Phabricator.

Zu den Aufgaben gehören:

  • Fehlermeldungen (Bugs) und die Fehlerbeseitigung
  • Wünsche nach neuen oder veränderten Funktionalitäten und ihre Realisierung
  • Konfiguration in einzelnen Wikis
  • Langfristige Ziele (Epics).

Eine Aufgabe wird „Task“ genannt, mit einem T und einer laufenden Nummer gekennzeichnet.

Die Phabricator-Komponente für das Aufgabenmanagement heißt „Maniphest“; das Symbol dafür ist ein Anker.

Fehlermeldung

[Quelltext bearbeiten]
  • Jeder bisherige „Bug“ ist jetzt eine „Task“ (Aufgabe).
  • Zum Umgang mit den bisherigen Fehlermeldungen siehe Bugzilla-Migration.

Eintragen eines neuen Fehlers

  • Voraussetzungen:
    • Für die Phabricator-Benutzung sind grundlegende Kenntnisse der englischen Sprache notwendig.
    • Nur angemeldete Benutzer können Beiträge liefern.
    • Nicht angemeldete Benutzer können jedoch per E-Mail von einem Problem berichten und damit eine neue Aufgabe eröffnen; auch einen Wunsch nach Software-Eigenschaften äußern.
  • Grundregeln:
    • „Jeder nur ein Kreuz“ – jede Fehlermeldung nur ein Problem (#Einzelaufgabe).
    • Wähle einen schlüssigen Titel als Überschrift.
    • Folge den gängigen Empfehlungen für eine verständliche Problembeschreibung.
    • Wenn dir die Zuordnung klar ist, kannst du aus den Tags bereits ein geeignetes und zuständiges Projekt auswählen; sonst frei lassen bzw. #MediaWiki-General-or-Unknown.
    • Die Prioritätensetzung übernimmt das Phabricator-Management; aus der Problembeschreibung sollte sich jedoch die Dringlichkeit ergeben, auch schon in der Überschrift widerspiegeln.
      • Die Prioritätenzuweisung nennt sich Triaging.
      • In dieses Umfeld gehört auch die Zuweisung an (Beauftragung von) Entwicklern.
  • Aktion
    • Angemeldete Benutzer können mit + eine neue Task erschaffen.
    • Falls es eine hiesige Projektseite gibt, auf der von dem Fehler berichtet wurde, sollte dort mit {{Tracked}} die Nummer vermerkt werden.
  • Sicherheitsrelevante Probleme sollten nicht öffentlich gemeldet werden.
    • Hierfür gibt es eine besondere Variante, mit der die Aufgabe zunächst nicht-öffentlich angelegt werden kann.
    • Wird in einer bestehenden öffentlichen Aufgabe eine Sicherheitslücke offenbart, die ausgenutzt werden könnte, kann die Aufgabe von allen angemeldeten Benutzern versteckt werden.
    • Nach Beseitigung aller Sicherheitsprobleme wird die Aufgabe wieder für alle sichtbar gemacht.
  • E-Mail
    • Benutzer ohne Anmeldung könnten eine Mail an Task@ – at-Zeichen für E-Mailphabricator.wikimedia.org senden. Hier muss das Feld für den Betreff die beabsichtigte Überschrift enthalten; der (unformatierte ASCII-)Inhalt ist die Problembeschreibung.
    • Eine Signatur sollte nicht enthalten sein, da sie ebenfalls veröffentlicht wird und womöglich die Anonymität des Benutzers aufhebt.

Einzelaufgabe

[Quelltext bearbeiten]
  • Jede Aufgabe sollte „lösbar“ sein; also eine Aktivität erfordern, durch die sie beendet wird.
  • Allgemeine Beschwerden und Proklamationen sind keine Aufgabe.
  • Verschiedene Aktivitäten aus verschiedenen Bereichen sollen nicht in einer Aufgabe vermengt werden; allerdings können abgegrenzte Unteraufgaben von einer übergeordneten Aufgabe kontrolliert werden. Die Unteraufgaben „blockieren“ die übergeordnete Aufgabe, bis alle Unteraufgaben gelöst sind.
  • Idealerweise kann eine Aufgabe von einem einzelnen Bearbeiter in begrenzter Zeit gelöst werden.

Neben den Einzelaufgaben gibt es auch ewige Daueraufträge, die niemals gelöst werden und nur zur Verwaltung der aktuell zu lösenden Unteraufgaben dienen.

Tags: Projekte und Projektarten

[Quelltext bearbeiten]
  • Ein Standardprojekt hat die Aufgabe, eine bestimmte Softwarekomponente oder Funktionalität zum Funktionieren zu bringen und anschließend funktionierend zu halten und zu pflegen.
  • Daneben gibt es weitere Projektarten, die für unsere Sichtweise weniger relevant sind und der inneren Organisation von mediawiki.org dienen.
  • Jeder Task können mehrere Projekte zugeordnet werden.
  • Verallgemeinert spricht man von „Tags“; also Etiketten, mit denen etwas versehen wird.
  • Ein Tag wird durch vorangestelltes # gekennzeichnet; darauf folgt ein mehr oder weniger verständlicher Klarname.
  • Auf /Tags ist eine Auswahl derjenigen Projekte aufgelistet, die für uns interessant sein könnten.

Feature-Requests

[Quelltext bearbeiten]

Es gelten sinngemäß die gleichen Regeln wie für #Fehlermeldungen.

Auf der hiesigen Projektseite sollte mit {{Tracked}} vermerkt werden, unter welcher Nummer der Wunsch eingetragen wurde.

Screenshot „Workboard“

Zu jedem Standardprojekt gibt es ein „Workboard“; also eine Art Anschlagbrett.

Auf diesem ergibt sich eine ToDo-Liste, auch bereits erledigte oder momentan bearbeitete Aufgaben.

Die Art der Spalten eines Workboard kann frei konfiguriert werden.

Somit lassen sich (in etwa vergleichbar unseren Kategorien) Aufgaben gruppieren. Wie auch eine Seite in mehrere Kategorien eingeordnet sein kann, kann eine Aufgabe beliebig viele Tags erhalten. Der Seitenauflistung in der Kategorie entspricht das Workboard, wobei dieses aber je nach Bearbeitungsstand in mehrere einzelne Listen gegliedert ist.

Prioritäten

[Quelltext bearbeiten]
  • Dunkelviolett = Needs Triage
  • Pink = Unbreak Now! – Sofort lösen!
  • Rot = High
  • Orange = Normal
  • Gelb = Low
  • Hellblau = Lowest (Feature request)

Quellcode-Verwaltung

[Quelltext bearbeiten]

Die Quellcodes der verschiedensten Softwareprodukte sind (wie in allen Systemen zur Versionsverwaltung üblich) in „Repositories“ organisiert.

  • Jedes Repository entspricht einer bestimmten, abgrenzbaren Softwarekomponente. Gelegentlich spricht man auch von „Projekten“; in Phabricator wird dieser Begriff jedoch anders verwendet.
  • Es gibt reichlich über 1000 Repositories.
  • Das größte und wichtigste ist MediaWiki-core – die unvermeidlichen Kernfunktionen eines Wikis.
  • Jedes Repository ist ähnlich organisiert wie die Dateiordner auf dem eigenen Rechner; oder die Unterseiten im Wiki.
  • Genau wie im Wiki gibt es auch Versionsgeschichten, Diffpages, Bearbeiter, Bearbeitungskommentare und eine Blame-Funktion.
    • Das ist kein Wunder, denn das Konzept des Ur-Wikis zur Verwaltung der Wikitexte war ein Versionsverwaltungssystem, mit dem sonst Quellcodes organisiert werden.
    • Ein Repository wäre mit einem Namensraum vergleichbar, in dem es Seiten und Unterseiten gibt.
  • Jedes Repository hat einen relativ verständlichen Klarnamen.
    • Dieser könnte sich im Prinzip auch ändern, was aber nicht vorgesehen ist.
  • Außerdem gibt es zu jedem Repository ein Callsign. Das ist ein aus zwei bis vier Großbuchstaben bestehender Bezeichner, eine Art Shortcut.
    • Callsigns sind unveränderlich.
  • Für den Zugriff auf ein Repository ist die Kenntnis des Callsigns erforderlich.
  • Ein Repository wird dadurch gekennzeichnet, das dem Callsign ein r vorangestellt wird.
  • Die Vorlage:Phab ermöglicht eine Systemwechsel überdauernde Verlinkung mit Repositories und einzelnen Dateien.

Die Phabricator-Komponente für die Quellcode-Verwaltung heißt „Diffusion“; das Symbol dafür ist </>.

Zwischen Repositories und dem Aufgabenmanagement besteht kein direkter Zusammenhang. Es können aber Projekte gebildet werden, deren Aufgabe es ist, genau die Softwarekomponente zu betreuen, die in einem Repository abgelegt ist. Das geht bei den kleineren Komponenten; Mediawiki-core hingegen ist ein komplexes Repository und wird über zahlreiche Einzelprojekte betreut.

Quellcodes durchsuchen

[Quelltext bearbeiten]

Mit dem Werkzeug codesearch können die Quellcodes gefiltert durchsucht werden. Diffusion bietet ebenfalls eine Quellcode-Suchfunktion an, jedoch mit weniger Möglichkeiten.

Phabricator-Diffusion legte sich in den ersten Jahren über das zunächst weiter bestehende GIT-System; hatte dieses dann 2016/17 vollständig abgelöst.

  • Auf die bisherigen Quellcodes, ihre Unterschiede und Versionsgeschichten konnte zugegriffen werden; Anfragen wurden gewissermaßen durchgereicht.
  • In der Oberfläche von Diffusion konnte aber bereits der Quellcode mit den übrigen Managementaufgaben von Phabricator vernetzt werden.
  • Zurzeit scheint der Original-Code auf Diffusion hinterlegt zu sein und wird auf GIT gespiegelt.

In rSVN „Subversion“ werden die bis 2012 verwendeten Versionsnummern abgebildet: rSVN115794. Dieses war das Verwaltungssystem des ersten Jahrzehnts gewesen.

Quellcode-Review

[Quelltext bearbeiten]

Die Kontrolle über Veränderungen an der wirksamen Software (zurzeit noch mittels „Gerrit“) soll in Zukunft weiter integriert werden.

Die Phabricator-Komponente für die Quellcode-Verwaltung heißt „Differential“.

Sowohl das allgemeine Wikimedia-Benutzerkonto (SUL) als auch ein bestehendes Wikitech/Labs-Konto lassen sich zum Einloggen benutzen und können dort auch verknüpft/zusammengeführt werden.

Zwischen Benutzerkonten und anderen Objekten bestehen Verbindungsmöglichkeiten (außerdem noch zwischen Objekten untereinander).

Für eine Aufgabe (task) gibt es:

  • zugeordnet (assigned)Aktiv
  • abonniert (subscribed)Passiv

Von einem assignee wird erwartet, dass er die Arbeit macht; die subscriber gucken ihm dabei zu.

Man kann Mitglied (member) eines Projektes oder Teams (tag) sein; dann erfährt man von allen Aktivitäten aller Aufgaben, denen dies zugeordnet ist, insbesondere wenn man sich auch als Beobachter (watcher) des Projekts einträgt. Je nachdem, in welcher Rubrik einer Aufgabe diese mit dem Projekt verbunden wurde, können sich hier kleinere Unterschiede im Auditorium ergeben.

Anmeldung (SUL)

[Quelltext bearbeiten]

Registrierung als normaler Wiki-Benutzer:

  1. Zunächst mediawiki.org besuchen bzw. sich dort anmelden, sodass man dort mit seinem normalen Wiki-Account angemeldet ist.
  2. Phabricator besuchen und oben rechts auf das Symbol für das Einloggen klicken (ein Pfeil nach rechts, der in ein Viereck führt).
  3. Login or Register MediaWiki (mit gelber Sonnenblume) anklicken.
    • Es erscheint eine OAuth-Rückfrage für phabricator-production.
    • Diese ist dann wohl zu bestätigen, um sich bei Phabricator mit Hilfe seines SUL-Accounts anmelden zu können.
    • Auf mw:Special:Preferences unter Connected apps kann die OAuth-Zustimmung auch jederzeit widerrufen werden.
  4. Es erscheint das Registrierungsformular des Phabricator.
    • Eine E-Mail-Adresse ist zwingend anzugeben.
    • Ein Alternativname kann angegeben werden, etwa aus Bugzilla-Zeiten.
  5. Nach der Registrierung wird eine Kontroll-Mail geschickt.
  6. Nach Bestätigung der E-Mail-Adresse im Browser ist der Phabricator-Account angelegt.
  7. Es könnte sinnvoll sein, auf mediawiki.org mittels Keep me logged in dauerhaft angemeldet zu bleiben.

Wer bisher schon angemeldeter Bugzilla-Nutzer oder Entwickler war, kann seine alten importierten Bugzilla-Aktionen und Kommentare für sich beanspruchen, indem die ehemals in Bugzilla genutzte E-Mail-Adresse zu seinem Phabricatorkonto hinzufügt wird.

Über „LDAP“ ist die Anmeldung mit dem Labs-Benutzerkonto möglich.

Benutzerprofil

[Quelltext bearbeiten]
  • Benutzernamen und Verlinkungen damit werden durch vorangestelltes @ gekennzeichnet.
  • Nur andere angemeldete Nutzer können die Benutzerprofile einsehen.
  • Die Vorlage:Phab ermöglicht eine Verlinkung.
  • Oben rechts neben dem Suchfeld erscheint bei angemeldeten Benutzern:
    • ein (zunächst nur schemenhaftes) persönliches Logo,
    • ein Pluszeichen („Neues schaffen“)
    • und ein Werkzeug (Benutzerprofil bearbeiten),
    • außerdem ein Link zum Ausloggen (Pfeil nach rechts, der aus einem Viereck führt).
    • Oben links befindet sich eine Echo-Glocke für neue Nachrichten; ggf. in blauer Farbe mit dem gewohnten Zähler.
      • Zu den Benachrichtigungen gehört, wenn sich zu den abonnierten Aufgaben ein weiterer Abonnent einträgt.
      • Standardmäßig erhält man bei jeder Aktivität auf abonnierten Aufgaben eine E-Mail, aus der die Aktion und zumindest der Beginn von hinterlassenen Texten hervorgehen. Ähnlich Echo ist dies detailliert konfigurierbar.
  • Das Benutzerprofil kann bearbeitet werden, und ein persönliches Bild kann gewählt werden (als lokales jpg, png, gif vom eigenen Rechner hochgeladen werden).
  • Man kann nun Aufgaben abonnieren (subscribe, etwa: „beobachten“) und kommentieren; auch Vorschläge für Quellcode hochladen.
  • Ein Babel ist ebenfalls vorhanden.

Es gibt eine Spielwiese.

Kommunikation

[Quelltext bearbeiten]

Nicht angemeldete Benutzer

[Quelltext bearbeiten]

  • Auch jeder unregistrierte Internetnutzer kann per E-Mail einen neuen Fehler melden:
    • Mail an: task@ – at-Zeichen für E-Mailphabricator.wikimedia.org
    • Der Betreff wird als Beschreibung einer neuen Aufgabe verwendet.
    • Der Inhalt wird einschließlich aller Signaturen direkt als Aufgabenbeschreibung angezeigt; persönliche Hinweise sollten also vorher entfernt werden.
    • Um bereits auf ein Projekt hinzuweisen, kann dessen Code wie etwa #mediawiki-core irgendwo im Text vorkommen.
  • Kommentare zu bestehenden Aufgaben können nicht abgegeben werden.
  • Alle öffentlichen Beschreibungen können in der Regel eingesehen werden.
    • Zuweilen gibt es Bereiche (Aufgaben), die nur für registrierte Benutzer sichtbar sind.
    • Sicherheitsrelevante Angelegenheiten werden ohnehin nur einer kleinen Gruppe von Entwicklern angezeigt.

Angemeldete Benutzer

[Quelltext bearbeiten]
  • Die Aufgaben (Tasks) und ggf. weitere Bereiche können angelegt, verändert und um Kommentare ergänzt werden.
  • Über Veränderungen an Aufgaben, die man abonniert hat, und viele andere öffentliche Vorgänge informiert eine Glocke links oben, neben dem Phabricator-Symbol.
  • Einem anderen angemeldeten Benutzer kann eine persönliche, für Dritte nicht einsehbare Nachricht übermittelt werden (chat).
    • Neue Nachrichten werden dem Empfänger als blaue Sprechblasen (rechts neben der Glocke) angezeigt.
    • Die Phabricator-Komponente dafür heißt „Conpherence“ (Chat-Funktion).
  • Aufgaben und andere Kommentarfelder können mit einem kleinen WYSIWYG-Editor geschrieben werden; es kann aber auch offline ein Text in vereinfachtem Markup (ähnlich Wikisyntax) vorbereitet werden:
Innerhalb der Zeile
//Kursiv// Kursiv
**Fettschrift** Fettschrift
##code## code
~~gelöscht~~ gelöscht
__unterstrichen__ unterstrichen
SymbolNummer Phabricator-Objekt verlinken (Task usw.)
http://example.org/ URL verlinken
[[http://xyz/ | name]] Betiteltes Weblink; Leerzeichen um Pipe
{F123456789} Bild einbinden
@Benutzername Benutzer erwähnen; dieser wird angepingt und verlinkt
#project Projekt erwähnen; dieses wird verlinkt, eine Task informiert
Am Zeilenanfang
* Listenpunkt
** Unterpunkt
# Nummeriert
## Unternummerierung

- würde auch als unnummerierte Liste verstanden werden.

Analog wikitext
200) Fine

404) Not found

200. Fine

404. Not found

= Große Überschrift =

== Zwischenüberschrift ==

Analog wikitext
Zwei Leerzeichen Code-Zeile
>> Im Zitat zitiert
> Zitat
Antwort
      Im Zitat zitiert

  Zitat
Antwort

NOTE:Bemerkung

WARNING:Warnung
IMPORTANT:Wichtig
(NOTE) Bemerkung
(WARNING) Warnung
(IMPORTANT) Wichtig

Farbige Kästen (gelb, blau, rot)
|Zelle| Tabellensyntax
  • Zu weiteren Möglichkeiten, auch nicht über den Editor mit Direkteinfügung ausgestatteten, siehe phabricator.com (englisch).

Dateien hochladen

[Quelltext bearbeiten]
  • Mittels Drag&Drop kann aus der Benutzeroberfläche des Rechners eine bestimmte Datei (also das Dateisymbol) in das Bearbeitungsfeld des Text-Editors gezogen werden.
    • Der Hochladevorgang beginnt bereits im Moment des „Drop“.
  • Die direkte Abbildung (Miniaturbild) würde dort als {F123456789} sichtbar. Eine Verlinkung ist später mittels F123456789 möglich.
  • Der Dateiname auf dem eigenen System bleibt dauerhaft als Dingens.png sichtbar und wäre zuvor ggf. auf dem PC neutral umzubenennen.
  • Die hochgeladenen Dateien werden auf phab.wmfusercontent.org abgelegt.

Die Phabricator-Komponente „Conpherence“ ermöglicht private oder öffentliche Chatrooms.

  • Das Lesen kann dem gesamten Internet erlaubt oder auf angemeldete Phabricator-Nutzern oder nur eingeladene Mitglieder beschränkt werden.
  • Das Schreiben kann auf eingeladene Mitglieder beschränkt oder allen Phabricator-Nutzern erlaubt werden.
  • Mitglieder werden von Änderungen benachrichtigt; ggf. auch per E-Mail.
  • Wer den Chatroom eröffnet, kann und muss ihn initial konfigurieren und sollte ihn auch sinnvoll benennen.
  • Vorgabe ist „privat“, also nur eingeladene Mitglieder können ihn sehen und darin schreiben.

Die nachstehenden Zeichen werden insbesondere für Kurzverlinkungen wie phab:P135 zurzeit benutzt:

Symbol Bedeutung Bezeichner
# Tag (Projekt) Projektname
@ Benutzer Benutzername
B Buildable build Laufende Nummer
D (commit) (Laufende Nummer)
E Event – Kalendereintrag Laufende Nummer
F File (Mediendatei, Rohdaten) Laufende Nummer
J Blog-Eintrag Laufende Nummer
M Mockup Laufende Nummer
P Paste – nummerierte Testzeilen plus Erörterung Laufende Nummer
r Repository Callsign (zwei bis vier Großbuchstaben)
Commit Callsign sowie längerer Hexadezimalcode (eigentlich 40 Zeichen; bei SVN auch dezimale Nummer)
S (Space) (Laufende Nummer)
T Task Laufende Nummer
D Patchset (Review) Laufende Nummer
W Panel (dashboard) Laufende Nummer
Z Chatroom (Conpherence) Laufende Nummer

Bugzilla-Migration

[Quelltext bearbeiten]

Am Wochenende 22./23. November 2014 wurde das System umgestellt.

Bugzilla-Nummern

[Quelltext bearbeiten]
  • Die alten Bugzilla-Nummern können weiterhin mit [[Bugzilla:123456]] genutzt werden.
    • Alle Verlinkungen (auch per URL in verschiedener Parameterstruktur) bleiben erhalten.
    • Die Direktverlinkung einzelner Abschnitte (Kommentare) wird zurzeit nicht unterstützt.
    • https://old-bugzilla.wikimedia.org/ ist mittelfristiges Archiv.
    • Das eingefrorene Archiv per 22. November 2014 könnte in statische HTML-Seiten umgewandelt werden.
  • Auf die bisherige Bugzilla-Diskussion wird hingewiesen.
    • Im Kopf der Phabricator-Task wird auf eine frühere Bugzilla-Nummer verwiesen durch vorangestelltes „bz“:
      Reference bz123456
    • Die entsprechenden Kommentare vor dem 22. November 2014 sind in die Task importiert.
    • Status- und andere Zustandsänderungen sind nur im Bugzilla-Archiv zu finden.
  • Sie wurden den Phabricator-Benutzern zugeordnet, sofern die Bugzilla-E-Mail-Addresse bis zum Zeitpunkt der Migration hinterlegt war. Die verbleibenden Einträge sind dem Benutzer „bzimport“ zugeordnet.
  • Die Phabricator-Task-Nummern entsprechen nicht den Bugzilla-Nummern.
    • Die ersten 1200 Task-Nummern waren bereits im Vorfeld vergeben worden.
    • Falls die Nummer eines Bugzilla-Tickets bekannt ist (z. B. bug 58000), so erhält man die entsprechende Task in Phabricator, indem man 2000 hinzuzählt (z. B. T60000). Die letzte Bugzilla-Nummer war 73681 gewesen.
  • Die Vorlage:Phab stellt beide Verlinkungen synchron dar: {{Phab|Bugzilla=}}Beispiel: phab:T60000 (Bugzilla:58000).

Ein „Voting“ zur Priorisierung von Bugs bestand schon seit längerer Zeit nur noch bei einzelnen Bugzillaprojekten. Eine direkte Entsprechung in Phabricator gibt es nicht, jedoch können Benutzer sogenannte „Tokens“ – etwas wie ein Emoticon mit Bild (eine Art „Like“) – an Tasks vergeben. Die Votings wurden nicht migriert, sind jedoch noch in Bugzilla abrufbar und sollten von dort manuell übertragen werden (indem man z. B. nun alternativ den Phab-Task beobachtet).

Weitere Informationen

[Quelltext bearbeiten]
MediaWiki: Phabricator/Help – Hilfeseite (englisch)
Commons: Phabricator – Sammlung von Bildern, Videos und Audiodateien

Extern (alle englisch)