Abstrakte Wikipedia/Launch-Anforderungen

This page is a translated version of the page Abstract Wikipedia/Launch requirements and the translation is 100% complete.

Dies ist eine Liste der Funktionen / Fähigkeiten / Schritte, die wir vor dem Launch erledigen müssen. Sie ist wahrscheinlich nicht vollständig. Eine aktualisierte Version findet sich im Phabricator unter phab:T301587.

Design-Checkliste

  • Erstellen und Bearbeiten von Funktionen
    • Erstellen von Funktionsdefinitionen
    • Bearbeiten von Funktionsdefinitionen
    • Möglichkeit, Implementierungen und Tests hinzuzufügen und zu entfernen
    • Benutzer-Tests
  • Funktionsseite / Funktion ansehen
    • Nutzen des Funktions-Widgets
      • Dies muss gründlich mit technisch nicht versierten Personen getestet werden, einschließlich der verschiedenen Gemeinschaften der Fokussprachen
        • Möglichkeit, Benutzer-Tests in Indien durchzuführen
    • Benutzer-Tests
  • Text-Widget mit Rückfalloption
  • Anzeige von Zeichenketten
  • Anzeige von Referenzen
  • Objektauswahl / Suche
  • Funktionsaufruf-Widget
  • Widget für Namen und Aliasse
  • Standardkomponenten zum Anzeigen, Erstellen und Bearbeiten von Objekten
  • Standard-Objektseite (erstellen, bearbeiten, ansehen)
  • Hauptseite
    • MVP: kleiner Einleitungstext und Beispiel für einen Funktionsaufruf
    • Die Gemeinschaft wird übernehmen
    • Einzelne Sprache
  • Grundlegende Suche (MVP)
    • Wiederverwendbares Suchfeld
    • Standard-UI
  • Mobilfreundlich (leicht von Benutzern getestet, aufpoliertes Design)
  • Standardkomponente zur Anzeige von Objekten (MVP)
  • Von Beginn an multilingual
    • Benutzer-Tests erforderlich
    • Benötigt Arbeit:
      • Rechts nach Links
      • Nicht-romanische Buchstaben
      • “Lange” Sprachen
      • Wir unterstützen keine vertikalen Sprachen
    • Sollte von Benutzern getestet und aufpoliert werden, bevor nicht-englischsprachige Gemeinschaften kontaktiert werden
  • UX für Design und Implementierung von Arbeitsabläufen, die bestimmte Bearbeitungen einschränken
    • Dokumentation von "erforderlichen" und "empfohlenen" Einschränkungen für Benutzergruppen, damit die Gemeinschaft über sie diskutieren und sie selbst zuweisen kann
  • Wechsel von einer Sprache zu einer anderen

Produkt-Checkliste

  • Erstellen, Ansehen, Bearbeiten von Typen
  • Erstellen, Ansehen, Bearbeiten von Instanzen aller integrierten Typen (über die Standard/Rückfall-UX)
  • Erstellen, Ansehen, Bearbeiten von Instanzen aller benutzergenerierten Typen (über die Standard/Rückfall-UX)
  • Erstellen, Ansehen, Bearbeiten, Nutzen von Funktionen (mit einer maßgeschneiderten UX)
  • Erstellen, Ansehen, Bearbeiten und Nutzen von generischen Typen / Funktionen, die einen Typ erstellen (über die Standard/Rückfall-UX)
  • Erstellen, Ansehen, Bearbeiten von Instanzen generischer Typen
  • Erstellen, Ansehen, Bearbeiten, Nutzen von generischen Funktionen
  • Ansehen und Bearbeiten der Dokumentation jedes Objekts
  • Zugänglichkeit und Auffindbarkeit aller Inhalte in allen Sprachen
  • Sammeln und Anzeigen von Metadaten für Funktionsausführungen
  • Auswahl von Implementierungen basierend auf den gesammelten Metadaten
  • Design und Implementierung von Arbeitsabläufen, die bestimmte Bearbeitungen einschränken
  • Entscheiden, welche Kennzahlen erfasst werden

Technik-Checkliste

Hindernisse

(Diese werden größtenteils durch die Checkliste Vorbereitung auf die Einführung abgedeckt)

  • Sicherheitsüberprüfung – Wir müssen vor dem livegehen eine Überprüfung durchführen und bestehen (akzeptiert werden). Zusammenarbeit mit dem Sicherheitsteam erforderlich.
  • Leistungsüberprüfung – Wir müssen vor dem livegehen eine Überprüfung durchführen und bestehen.
  • SRE Service Ops
  • Kennzahlen vorhanden

Interne Qualitätsprüfungen

Automatisierte Tests

  • Der gesamte Code sollte, soweit sinnvoll, mit Tests getestet werden, die die Zusammenführung verhindern.
  • Einheitentests – Der gesamte Code sollte über umfassende Einheitentests verfügen. Für einige Bereiche des Codes sollte dies durch Mindestanforderungen an die Codeabdeckung erzwungen werden
    • Schwellenwerte und Bereiche festzulegen.
  • Integrationstests – Alle Systemschnittstellen sollten Integrationstests unterzogen werden
  • Browsertests – Wichtige Arbeitsabläufe für die Benutzererfahrung sollten über Browsertests verfügen
    • Erstellen einer Funktion
    • Ansehen einer vorhandenen Funktion
    • Bearbeiten einer vorhandenen Funktion
    • Bearbeiten der Dokumentation einer Funktion
    • Suche nach einer Funktion
    • Nutzen einer implementierten Funktion
    • Letzte Änderungen funktionieren
    • Versionsgeschichte eines Objekts funktioniert
    • Versionsunterschiede funktionieren
  • Ende-zu-Ende-Tests – Repräsentative, komplexe und besorgniserregende Bereiche sollten durch vollständige Ende-zu-Ende-Tests getestet werden.
    • Bereiche festzulegen.

Code-Qualität

  • Code-Standards – Der gesamte Code sollte den aktuellen Code-Standards entsprechen und bei jeder Ausnahme sollte dokumentiert werden, warum wir dagegen verstoßen.
  • Dokumentation – Code ist dokumentiert
  • Inline-Kommentare – Alle Inline-Code-TODOs/FIXMEs etc. sollten zur Priorisierung durch das Team als technische Phabricator-Aufgaben geschrieben werden, was im Kommentar erwähnt werden sollte.

"Gut genug" nicht funktionale Anforderungen

  • Leistung – festzulegen.
  • Sicherheit – festzulegen.
  • Zuverlässigkeit – festzulegen.
  • Skalierbarkeit – festzulegen.
  • Integrität – festzulegen.