Abstract Wikipedia/Launch requirements

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Other languages:

This is a list of features / capabilities / steps we need to get done before launch. It is probably not complete. An updated version is on Phabricator at phab:T301587.

Design checklist[edit]

  • Creating and editing functions
    • Creating function definitions
    • Editing function definitions
    • Ability to attach and remove implementations and testers
    • User testing
  • Function page/view function
    • Use function widget
      • This will need to be thoroughly testing with non-technical people, including the different focus language communities
        • Potential to do some user testing in India
    • User testing
  • Text widget with fallback
  • Strings display
  • References display
  • Object selector / search
  • Function call widget
  • Names and aliases widget
  • Default component to display, create, and edit objects
  • Default object page (create, edit, view)
  • Main page
    • MVP: tiny bit of intro-wording and example of a function call
    • Community will take over
    • Single language
  • Basic search (MVP)
    • Reusable search box
    • Standard UI
  • Mobile friendly (lightly user tested, Polished Design)
  • Default component to display objects (MVP)
  • Multilingual from the beginning
    • Needs user testing
    • Needs to work:
      • Right to Left
      • Non-Roman letter alphabets
      • “Long” languages
      • We don’t support vertical languages
    • Should be user-tested and polished before outreach to non-English speaking communities
  • UX for design and implementation of workflows that restrict certain edits
    • Documentation of "required" and "recommended" usergroup-level restrictions, for the community to discuss and iterate upon, and allocate to themselves
  • Switching from one language to the other

Product checklist[edit]

  • 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

Tech Checklist[edit]

Roadblocks[edit]

(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[edit]

Automated testing[edit]

  • 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[edit]

  • 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[edit]

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