Wikipédia abstraite/Prérequis au lancement

From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Abstract Wikipedia/Launch requirements and the translation is 48% complete.

Voici une liste de fonctionnalités / capacités / étapes dont nous avons besoin avant le lancement. Ceci n’est probablement pas complet. Une version à jour est sur Phabricator à phab:T301587.

Liste de vérifications de la conception

  • Pouvoir créer et éditer des fonctions.
    • Création de définitions de fonction.
    • Modification de définitions de fonction.
    • Capacité à attacher et enlever des mises en œuvre et des testeurs.
    • Tests par l’utilisateur.
  • Page de fonction / visualisation de fonction
    • Utilisation d’un widget de fonction
      • Cela demandera d’être consciencieusement testé avec des personnes non techniciennes, y compris dans les différentes communautés des langues prioritaires.
        • Potentiel à effectuer des tests par des utilisateurs en Inde
    • Tests par l’utilisateur.
  • Widget textuel avec repli.
  • Affichage de chaînes.
  • Affichage de références.
  • Sélecteur / recherche d’objet.
  • Widget d’appel de fonction.
  • Widget des noms et alias.
  • Composant par défaut pour afficher, créer et modifier des objets.
  • Page d’objet par défaut (créer, modifier, visualiser).
  • Page principale
    • Partenaires (MVP) : quelques mots d’introductions et un exemple d’appel de fonction.
    • La communauté prendra la main.
    • Langue unique.
  • Recherche de base (MVP)
    • Boîte de recherche réutilisable.
    • Interface utilisateur standard.
  • Accessible sur mobiles (sommairement testé par les utilisateurs, conception épurée).
  • Composant par défaut pour afficher des objets (MVP).
  • Multilingue dès le début.
    • Demande des tests par les utilisateurs.
    • Besoins de travailler sur :
      • Écriture de droite à gauche
      • Alphabets à lettres non latines.
      • Langues « verbeuses ».
      • Nous ne prenons pas en charge les langues à écriture verticale.
    • Devrait être testé par les utilisateurs et épuré avant de solliciter des communautés ne parlant pas l’anglais.
  • Composants d’expérience utilisateur pour la conception et la mise en œuvre de flux de travail qui restreignent certaines modifications.
    • Documentation des restrictions « requises » et « recommandées »  des niveaux de groupes d’utilisateurs, à discuter de façon itérative par la communauté et à allouer pour eux-mêmes.
  • Basculement d’une langue à l’autre.

Liste de vérifications du produit

  • Creation, view, editing of types
  • Creation, view, editing of instances of any built-in types (via the default/fallback UX)
  • Creation, view, editing of instances of user-generated types (via the default/fallback UX)
  • Creation, view, editing, usage of functions (with a bespoke UX)
  • Creation, view, editing, and usage of generic types / functions creating a type  (via the default/fallback UX)
  • Creation, view, editing of instances of generic types
  • Creation, view, editing, usage of generic functions
  • Viewing and editing of documentation on each object
  • Accessibility and discoverability of all content in all languages
  • Collect and display metadata for function runs
  • Select implementations based on the collected metadata
  • Design and implement workflows that restrict certain edits
  • Decide which metrics to capture

Liste de vérifications techniques

Roadblocks

(These are mostly covered by the Preparing for deployment checklist)

  • Security review – We need to undertake and pass (accept) a review before go-live. Needs working with the Security team
  • Performance review – We need to undertake and pass a review before go-live.
  • SRE Service Ops
  • Metrics in place

Internal quality checks

Automated testing

  • All code should wherever reasonable be tested with tests that block merge.
  • Unit tests – All code should have comprehensive unit tests. For some areas of the code, this should be enforced with minimum code coverage requirements
    • Thresholds and areas TBD.
  • Integration tests – All system interfaces should be integration tested
  • Browser tests – Key user experience work-flows should have browser tests
    • Creating a function
    • Viewing an existing function
    • Editing an existing function
    • Editing the documentation of a function
    • Searching for a function
    • Using an implemented function
    • Recent changes works
    • History of an object works
    • Diff on history works
  • End-to-end tests – Representative, complex, and worrisome areas should be tested via full end-to-end tests.
    • Areas TBD.

Code quality

  • Coding standards – All code should follow current coding standards with each exception documented inline as to why we're violating it.
  • Documentation – code is documented
  • In-line comments – All inline code TODOs/FIXMEs etc. should be written up as technical debt Phabricator tasks for team prioritisation, which should be mentioned in the comment.

"Good enough" non-functional requirements

  • Performance – TBD.
  • Security – TBD.
  • Reliability – TBD.
  • Scalability – TBD.
  • Integrity – TBD.