We should still do this task. I'll pick it up when I'm back from {E1481} unless someone gets to it before then.

EQUITY/DEVICE: software that interacts with users MUST be designed to make key functionality available on devices with a variety of capability and restrictions, with tradeoffs explicitly considered for mobile form factors and connectivity.

✅

EQUITY/LANGUAGE: software that interacts with users MUST support internationalization. Internationalization mechanisms SHOULD be consistent across platforms.

✅

EQUITY/ACCESS: software that interacts with users MUST consider accessibility concerns and SHOULD follow accessibility guidelines.

⚠ T296820: Support adding alternative text in add image workflow exists as an open task. We have also not (to my knowledge) audited the add image plugin for accessibility issues.

EMPOWER/TWEAK: our software SHOULD provide APIs, libraries, and services that empower the community with ways to develop workflows using programming languages, and ensure safety and maintainability of custom programs.

✅ T306349: Public-facing API for querying image suggestion recommendations and submitting user feedback is a follow-up task.

EMPOWER/COMBINE: software that manages or interacts with user-editable content SHOULD support close integration of different media and data types from local and remote sources.

✅ although I am not sure if this exactly applies to this feature.

API/DOMAIN: for all interactions defined on the abstract domain model, stable public APIs MUST exist. APIs geared towards a specific user interface MUST be considered part of the component that implements that user interface, and MAY be considered private to that component.

To provide public APIs that allow efficient interaction with wiki content, as well as provide data that can be easily processed and reused in bulk,

API/DOMAIN: for all interactions defined on the abstract domain model, stable public APIs MUST exist. APIs geared towards a specific user interface MUST be considered part of the component that implements that user interface, and MAY be considered private to that component.
API/STRUCTURED: our software MUST be designed in a way that makes all content and public meta-data available as structured data or media with semantic markup (e.g. as JSON or as annotated HTML).
API/SCHEMA: data we offer for re-use MUST use clearly specified data schemas and SHOULD be based on widely used open standards.
API/GRANULAR: public APIs SHOULD allow access to content with high granularity.
API/FORMAT: APIs MUST be designed to enable clients to process content without the need to parse or manipulate wikitext.
API/SOURCE: data formats and APIs that provide access to user-generated content SHOULD be designed to ensure verifiability through the integration of provenance information.
API/LICENSE: data formats and APIs that provide access to user-generated content MUST be designed to provide easy access to all relevant information about authorship and licensing.

✅ though these don't exactly apply to us.

To provide an open-source software stack that can be easily used, modified, and extended by others,

OPEN/FLOSS: software we write MUST be published under a free license for the ability of third parties to audit our code and to create forks of the codebase.
OPEN/REUSE: software components that implement broadly applicable functionality SHOULD be designed for reusability and be published for re-use.
OPEN/RELEASE: software that exposes public interfaces (as libraries, frameworks, hooks, or APIs do) SHOULD be subject to release management with clear and consistent versioning. Any breaking changes to such interfaces then MUST be announced in a timely and predictable manner over relevant channels.
OPEN/STABLE: any elements scheduled for removal from a stable public interface MUST be documented to be deprecated beforehand, and SHOULD be kept for backward compatibility for a reasonable time.
OPEN/MODULAR: our software architecture SHOULD be modular, with components exposing narrow interfaces, to allow components to be replaced and refactored while maintaining a stable interface towards other components as well as third-party extensions.
OPEN/GIANTS: our software SHOULD be built on top of reliable, documented, well-maintained open-source components.

✅

To maintain a code base that can be modified with confidence and readily understood,

SOLID/MODEL: our software architecture SHOULD follow explicitly specified domain models that define relevant entities and actions (nouns and verbs), to facilitate clear communication between software components as well as among people.
SOLID/TEST: all code SHOULD be designed for testability.
SOLID/COVER: the software we develop MUST provide a test suite, which SHOULD be sufficiently detailed, comprehensive, and noticeable to provide confidence for developers to see that their changes did not break anything.

✅

SOLID/DOCS: comprehensive documentation MUST be maintained along with the code.

✅ we have class/method level documentation and https://www.mediawiki.org/wiki/Extension:GrowthExperiments/Technical_documentation

RUN/EVERYWHERE: the basic MediaWiki stack MUST be easy to deploy on standard hosting platforms.
RUN/CHEAP: small MediaWiki instances MUST function in low-budget hosting environments.
RUN/MORE: for every component and feature, the intended target audience and supported target platform MUST be clearly defined.
RUN/EASY: it SHOULD be possible to install and upgrade MediaWiki without much technical knowledge.
RUN/UPDATE: it MUST be possible to upgrade MediaWiki without the risk of losing content or disrupting operation.

Not applicable.

FAST/SCALE: horizontal scalability SHOULD be a design goal on all levels of the architecture, especially for storage and query mechanisms.
FAST/MEASURE: observability and analytic instrumentation SHOULD be explicitly considered in the design of new components and services.
FAST/LOAD: our software and infrastructure SHOULD be designed to be resilient against spikes in demand and failure of backend systems.
FAST/ROUTE: services and APIs SHOULD be designed to allow the identification of read-only and read-write HTTP requests to optimize routing and caching.
FAST/GEO: storage and caching systems SHOULD be designed with a distributed multi-datacenter architecture in mind.
FAST/CHANGE: system design and technology choice SHOULD aim to reduce operational overhead and the cost of change management.

✅

SECURE/AUSTERE: our software systems MUST be designed to only collect data needed for a specific purpose, and retain it only as long as necessary.
SECURE/PRIVATE: our software and infrastructure MUST be designed in such a way to prevent unauthorized access to sensitive information.
SECURE/ISOLATED: our system architecture SHOULD isolate components to reduce attack surface, and to minimize the impact of individual components being compromised.
SECURE/INTEGRITY: resilience against data corruption MUST be a design goal for our system architecture, and be built into the software we write.
SECURE/ACT: tools and processes SHOULD be designed to allow us to be responsive as well as proactive in ensuring security.
SECURE/PATCH: our deployment infrastructure and dependency management SHOULD make it easy to keep system components up to date.
SECURE/CONFIG: our deployment infrastructure SHOULD make it easy to change configuration settings without disruption.

✅

cc @KStoller-WMF @DMburugu @Etonkovidova. The only one I am not sure about is whether we have audited the AddImage UX for accessibility issues. Should we make a task for that?

I know some level of accessibility testing is part of the QA workflow, so I'll let @Etonkovidova answer if she thinks an a task is needed.

From my perspective if a task is needed, I think it can wait until we are ready to refocus on Add an Image - T293711 .