Architecture Summit 2014/RFC clusters

We have created the straw poll based on the clustering as of 04:56, January 1, 2014‎ -- Please do not change the clustering without consulting either Robla or Diederik

The idea with this grouping is that we want it to be granular enough to consider batches of RFCs on this type of 90 minute agenda:

  • 5 minutes – lightning talk 1
  • 5 minutes – short Q&A 1 (clarifications only)
  • 5 minutes – lightning talk 2
  • 5 minutes – short Q&A 2 (clarifications only)
  • 5 minutes – lightning talk 3
  • 5 minutes – short Q&A 3 (clarifications only)
  • 60 minutes – general discussion

The idea is that a cluster contains RFCs that belong to each other. This means if we discuss RFC A and therefore RFC B needs to be discussed as well then those two RFCs should be in the same cluster. Clusters should also be small, probably not more than 3 or 4 RFCs per cluster.

Backend internalsEdit

This category is for clusters that are completely about the server code.

ConfigurationEdit

Proposals that involve moving away from global variables as the standard way of configuring core and extensions

DebuggingEdit

Storage servicesEdit

LinkingEdit

Media backendEdit

Parsing architectureEdit

Proposals that involve big changes to how we think about parsing and wikitext

Parser changesEdit

Smaller changes to parsing

PerformanceEdit

RefactoringEdit

SQL abstractionEdit

APIs/Interfaces/ProtocolsEdit

This overall category is for concerns that cut across front-end and backend, and how they interact with each other. This area typically haves an Ops heavy component, because things in this area muck with things like caching infrastructure and load balancers.

CentralNoticeEdit

HTML templatingEdit

Proposals that involve adding an abstraction layer for server-side and/or client-side HTML skin/user interface generation

MetadataEdit

Interacts with: #Wikidata.

MobileEdit

Parsed output accessEdit

Service-oriented architectureEdit

Thumbnail handlingEdit

URLsEdit

WikidataEdit

Interacts with: #Metadata.

FrontendEdit

Multimedia frontendEdit

UI/UX: stylingEdit

Software managementEdit

This is for proposals that involve code for managing MediaWiki

Backend code modularity frameworksEdit

Proposals that involve organizing our backend code to be more modular

InstallationEdit

MediaWiki managementEdit

Release processEdit

Software for/from third partiesEdit

FunctionalityEdit

These have end-to-end implications, but are typically more about functionality than architecture.

CrosswikiEdit

Topic cluster, not really for implementation most likely.

General MediaWiki functionalityEdit

Page protection and deletionEdit

SecurityEdit

UI/UX: usability and discoverabilityEdit

User customization/filterabilityEdit

Wiki tasks managementEdit