Architecture Repository/Artifacts/Abstract Wikipedia Architecture
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. Please refer to current documentation from 2025: Abstract_Wikipedia_team/Architecture |
Abstract Wikipedia Architecture
A library of code functions to support the Wikimedia projects and beyond, for everyone to call and re-use in the world's natural and programming languages
Last updated: 2025-03-06 by Jdforrester (WMF)
Status: v1 published April 2021 to describe the architecture modeling and discussion for Abstract Wikipedia
Mission statement
Enable everyone to collaboratively create and maintain a library of code functions to support the Wikimedia projects and beyond, for everyone to call and re-use in the world's natural and programming languages
Narratives (User stories)
- User stories (TODO)
Capabilities
This is a list of systems capabilities for the Abstract Wikipedia system. This list is still under consideration and is evolving as we continue to model and flesh out the system behavior. Click to see the artifact (LucidChart).
Contribute functionality
Capabilities that involve contribution like creating new objects and editing existing objects.
- Contribute function definition
- Translate function definition
- Contribute function implementation
- Accept valid implementation
Discuss functionality
Capabilities that involve community collaboration on policy and functionality.
- Establish policy and norms
- Standardize functionality
- Finding missing required functionality
- International global standardization
Test functionality
Capabilities that involve testing functions and quality assurance of the deliverable objects.
- Contribute test cases
- Test the correctness of a function
Serve functionality
Capabilities that involve serving the functions and objects in the system to an external consumer.
- Invoke a function call
- Update the result of a function call
- Fetch external parameter data
- Find a function
- Embed function in a wiki page
Document functionality
We are still fleshing this capability out and what it means for the behavior of the system.
Architecture models
This section includes the architectural models that are part of the discovery and model stages to define the architecture. This follows the Architecture practice, and involves collaborative modeling techniques like event sourcing. The goal of the process is to describe the domains of the system and model the architectural process. This work is ongoing.
Event models
These models aim to understand how the system works, mark the pain points, and discover where to dive deeper.
Event storming - first version
We began here to understand the events that happen in the system. And to tease out pain points / dense areas where we want to dive deeper.
Prioritized modeling how “validation” works next.
Event storming - cleaner version
Layered the events, as we identified them, and agreed this was accurate (with many remaining questions.)
Adding functions event sourcing
A model attempting to describe the actions and events that happen when a function is added to the system.
Ideal function dashboard model ("Happy puppy model")
This model was created from the view of an "ideal" workflow, to flush out behavior and interaction with the system.
Contexts and events in high-level model
A model fleshing out the user actions, system capabilities, and events in the system.
Capabilities and Flow models
These are models showing the capabilities and/or flow of data through the system.
Flow/Capabilities model - first draft
This was the first attempt to create a representation of the actions, flow, and events of the system.
Mission, Capabilities and Flow - second draft
A second iteration on the flow and capabilities model, connecting them to the team's missions statement.
Structure models
These are models describing a behavior of some system or several systems and their parts.
Top-level architectural model
This represents the top-level architecture of the system and its top-level services.
