Abstract Wikipedia team/Definition of Done

A Definition of Done (DoD) is a unified understanding of what should be accomplished before a user story, a task or a product release is considered finished.

A Definition of Done can be applied to different development levels, and those depend on the work cycles of every team. This guide is specifically adapted to the workflow and terminology of the Abstract Wikipedia team. We define three main levels of completion: Phase, milestone or epic, and task.

Phase DoD
A development Phase is a collection of user stories (see the Abstract Wikipedia Phase definitions).


 * Functionality
 * ☑️ Every user story should be covered by a milestone/epic
 * ☑️ Every phase milestone/epic should pass their DoD checklist
 * ☑️ Tests for every project should pass
 * ☑️ Build process for every project should pass
 * ☑️ Coverage for every project should have improved or stayed the same
 * ☑️ All  annotations should be resolved
 * ☑️ All  annotations should have an associated Phabricator task ID
 * Design
 * ☑️ Every user story reflected on a user-facing functionality must follow the design system
 * ☑️ Every user story must be reviewed and approved by the design/UX team
 * Documentation
 * ☑️ Every user story must be have related and updated documentation
 * Internal technical changes: internal repository documentation must be updated (README.md, JSDoc, PHPDoc)
 * Infrastructure technical changes: technical changes that reflect on environment, infrastructure, endpoints or any other area of interest for technical contributors should be reflected on MediaWiki extension pages.
 * Product or model changes: should have related documentation updated in meta
 * User-facing features: should have an initial user guide draft that will be moved to wikifunctions.org
 * ☑️ Phase completion newsletter must be sent
 * Versioning
 * ☑️ All projects must have unified submodule versions
 * ❓ Release version?

Milestone/Epic DoD
A milestone is described by one user story and can involve one or more projects.


 * Functionality
 * ☑️ Every project involved in the user story should have its associated tasks in Phabricator
 * ☑️ Every related task should pass its DoD checklist
 * ☑️ Tests for every involved project should pass
 * ☑️ Build process for every involved project should pass
 * ☑️ Coverage for every involved project should have improved or stayed the same
 * Design
 * ☑️ Must be reviewed and approved by the design/UX team
 * Documentation
 * ☑️ Must be have related and updated documentation
 * Internal technical changes: internal repository documentation must be updated (README.md, JSDoc, PHPDoc)
 * Infrastructure technical changes: technical changes that reflect on environment, infrastructure, endpoints or any other area of interest for technical contributors should be reflected on MediaWiki extension pages.
 * Product or model changes: should have related documentation updated in meta
 * Versioning
 * ☑️ If changes in submodule packages are involved, every project that uses this submodule should pass tests and build

Task DoD
A task is described by a Phabricator ticket and involves one project only, which should be appropriately tagged in the ticket. Every Phabricator task should follow the AW Phabricator style guide.


 * Functionality
 * ☑️ The issue detailed in the Phabricator ticket description is solved
 * ☑️ All the child tasks are closed
 * ☑️ There are existing and passing unit/integration tests effectively testing its success and its failure
 * ☑️ The issue has been peer reviewed
 * ☑️ The issue has been merged
 * Design
 * ☑️ If the task is UX/Design related: it must be reviewed and approved by the UX/Design team
 * Documentation
 * ☑️ All new functions/methods are annotated (JSDoc or PHPDoc)
 * ☑️ Related documentation in MediaWiki extension pages or Abstract Wikipedia pages in meta should be updated with the related changes
 * E.g. New API being created should be reflected in WikiLambda API help page
 * E.g. New error types being added should be reflected in the Representation of errors help page
 * E.g. New keys being added to built-in types should be reflected in the Function model help page
 * Versioning
 * ☑️ If changes in submodule packages are involved, every project that uses this submodule should pass tests and build
 * ❓ Is this necessary for task DoD or should this be an item of Epic/Milestone DoD?