Define the architecture areas for MediaWiki core and platform extensions
Open, LowPublic


We really miss a high level architecture overview of MediaWiki core and platform extensions (the ones that provide APIs and enable user features). Reasons to have one:

  • MediaWiki and relatives form a very complex family. lists 210 components only for core, and there is no subdivision to be seen. Without a shared high level map it is a lot more complex to have shared high level discussions and plans.
  • New potential contributors need an overview to understand the basics of MediaWiki and find the area where they want to work on. Such diagram would be really helpful to identify an area as a starting point. After many conversations with many newcomers with different skill levels, we know that most of them get simply lost / overwhelmed in their first contact.
  • Defining areas is a premise required to discuss whether we want to have architects / owners / maintainers for a specific area that would work with the ArchCom or be part of it.

How a v0.1 could look like:

MediaWiki Core

  • Configuration
  • Database
  • i18n/L10n
  • Parser
  • Skins
  • Media
  • API
  • ...

Platform extensions

  • Parsoid
  • ...
Qgil created this task.Nov 15 2014, 6:14 PM
Qgil added a project: Developer-Relations.
Qgil changed Security from none to None.
Qgil added subscribers: Qgil, marcoil.
Qgil changed the title from "Create a high level overview of the Wikipedia technical architecture" to "Create a high level overview of the MediaWiki architecture".Jan 23 2015, 3:01 PM
Qgil edited the task description. (Show Details)
Qgil raised the priority of this task from "Lowest" to "Low".
Qgil added a subscriber: ArchCom.
Qgil added a comment.EditedJan 23 2015, 3:14 PM

The 0.1 version can be as simple as this:

MediaWiki Core

  • Area 1
  • Area 2
  • ...

Key extensions

  • Extension 1
  • Extension 2
  • ...

The list of extensions should be really short, probably focusing in those providing an API and/or defining the basic "Wikipedia experience".

scfc added a subscriber: scfc.Jan 23 2015, 9:01 PM
brion added a subscriber: brion.Jan 23 2015, 10:45 PM

The bug summary is unclear: there is , so it would be a WORKSFORME. From what I understand, you're looking for a grouping of components. The currently available grouping for extensions is

Elitre added a subscriber: Elitre.Jan 24 2015, 1:06 AM
Qgil changed the title from "Create a high level overview of the MediaWiki architecture" to "Define the architecture areas for MediaWiki core and platform extensions".Jan 24 2015, 3:15 AM
Qgil edited the task description. (Show Details)
Nemo_bis removed a subscriber: Nemo_bis.Feb 1 2015, 5:26 PM
Tgr added a subscriber: Tgr.Jun 11 2015, 8:27 PM

Classes can be grouped via @ingroup/@defgroup in the doc comment; the result is this list.

marcoil removed a subscriber: marcoil.Jun 11 2015, 8:34 PM
In T1287#1358252, @Tgr wrote:

VERY interesting, thank you. That list contains 30 modules, which is better than the 42 rows of

A list based on modules is good because it is objective and discreet. Some of those 30 probably don't need to be listed in a high level picture? For instance, "PHP known bugs tests".

I'm marking this task tentatively for ECT-July-2015. Ones someone puts enough focus on this task, it shouldn't be that difficult to come up with a first satisfactory version.

Qgil assigned this task to Spage.Jul 7 2015, 6:01 PM
In T1287#1358252, @Tgr wrote:

Classes can be grouped via @ingroup/@defgroup in the doc comment; the result is this list.

Conversely, these doc comments are missing some important groupings, e.g ResourceLoader.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 13 2015, 5:37 AM

@Aklapper and I discussed this and T115852 briefly. It seems the best short- to mid-term fix is update to add Architectural area and WMF team columns and make it sortable. To provide the overview without scrolling through the table, there could be table rows for each architectural area that show up in the TOC, or perhaps there's a way to have collapsible subsections of a sortable table.

Qgil removed Spage as the assignee of this task.Jan 12 2016, 7:24 AM
Qgil moved this task from October - December 2015 to Team radar on the Developer-Relations board.
Qgil added a subscriber: Spage.
jayvdb added a subscriber: jayvdb.Mar 15 2016, 8:03 PM
Krinkle removed a subscriber: ArchCom.Mar 24 2016, 1:17 AM
greg added a subscriber: greg.Jul 22 2016, 10:28 PM
greg added a subscriber: Legoktm.Aug 10 2016, 6:17 PM

cc'ing @Legoktm here as he offered to take on the parent task of this (T128370) and there are good ideas here about how/what groupings.

This project is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.