Abstrakte Wikipedia/Launch-Anforderungen

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.