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 TechCom 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 updated the task description. (Show Details)
Qgil raised the priority of this task from to Lowest.
Qgil added a project: Developer-Advocacy.
Qgil changed Security from none to None.
Qgil added subscribers: Qgil, marcoil.
Qgil renamed this task 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 updated the task description. (Show Details)
Qgil raised the priority of this task from Lowest to Low.
Qgil added a subscriber: TechCom.
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 renamed this task 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 updated 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-Advocacy board.
Qgil added a subscriber: Spage.
jayvdb added a subscriber: jayvdb.Mar 15 2016, 8:03 PM
Krinkle removed a subscriber: TechCom.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.

Krinkle moved this task from Inbox to Backlog on the Architecture board.Mar 29 2017, 8:51 PM
Krinkle raised the priority of this task from Low to Needs Triage.
Krinkle triaged this task as Low priority.
Krinkle moved this task from Inbox to Radar on the TechCom board.

@Jrbranaa is this related to what you're doing about ownership for Release-Engineering-Team ?

@Catrope, yes I think this is related.

The work on defining stewards for each item will help, but I think we'll need to evolve the developer/maintainers page some more to make it more consumable. Even with the changes that have been made to the page and the identification of stewards, I think it will still fall short of addressing the pain points that are identified.

Thanks for looping me in.