Wikipédia abstraite/Prérequis au lancement

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.