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 internals

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

Configuration

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

• Configuration database (talk)
• Configuration database 2 (talk)
• Json Config pages in wiki (talk)

Debugging

• Structured logging (talk)

Storage services

• Storage service (talk)
• DataStore (talk)
• API roadmap (talk)

Linking

• New sites system (talk)
• Linker refactor (talk)

Media backend

• Refactor on File-FileRepo-MediaHandler (talk)

Parsing architecture

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

• Parsoid/Roadmap

Parser changes

Smaller changes to parsing

• New hook: ParserBeforePreprocess (talk)

Performance

• Performance standards for new features (talk) etherpad

Refactoring

• UserMailer refactor (talk)
• TitleValue (talk)

SQL abstraction

• SQL framework (talk)
• Abstract table definitions (talk)

APIs/Interfaces/Protocols

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.

CentralNotice

• CentralNotice Caching Overhaul - Frontend Proxy (talk)

HTML templating

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

• MVC framework (talk)
• OutputPage refactor (talk)
• HTML templating library (talk)
• Template engine (talk)
• Parsoid roadmap: DOM templating

Metadata

Interacts with: #Wikidata.

• Book management (talk)
• Image information (talk))
• Page metadata (talk)

Mobile

• Zero architecture (talk)

Parsed output access

• Content API (talk)
• Partial page caching (talk)
• Text extraction (talk)

Service-oriented architecture

• Services and narrow interfaces (talk)
• PHP Virtual REST Service (talk)

Thumbnail handling

• Simplify thumbnail cache (talk)
• Standardized thumbnails sizes (talk)

URLs

• URL shortener service for Wikimedia (talk)
• URL shortener (talk)
• Clean up URLs (talk)
• Drop actions in favour of page views and special pages (talk)

Wikidata

Interacts with: #Metadata.

• Wikidata API (talk)

Frontend

Multimedia frontend

• More general frontend uploading tools (talk)

UI/UX: styling

• Grid system (talk)
• Vertical writing support (talk)
• Scoping site CSS (talk)
• Allow styling in templates (talk)

Software management

This is for proposals that involve code for managing MediaWiki

Backend code modularity frameworks

Proposals that involve organizing our backend code to be more modular

• MediaWiki libraries (talk)
• Third-party components (talk)
• Extension release management (talk)
• Distribution and deployment (talk)

Installation

• Opt-in site registration during installation (talk)
• Extension manager (talk)
• Extension management with Composer (talk)
• Extension release management (talk)

MediaWiki management

• Overthrow Bugzilla (talk)
• MediaWiki Foundation (talk)
• Bugzilla taxonomy (talk)
• MediaWiki.org Main Page tweaks (talk)

Release process

• Release notes automation (talk)
• Distribution and deployment (talk)

Software for/from third parties

• Third-party components (talk)
• Isolate custom jQuery libraries (talk)
• MediaWiki libraries (talk)

Functionality

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

Crosswiki

Topic cluster, not really for implementation most likely.

• Regex-based blacklist (talk)
• Global scripts (talk)
• Structured data push notification support for recent changes (talk)
• Publishing the RecentChanges feed (talk)

General MediaWiki functionality

• Removing hit counters from MediaWiki core (talk)
• Update our code to use RDFa 1.1 instead of RDFa 1.0 (talk)
• Retained account data self-discovery (talk)
• Nonlinear versioning (talk)
• Localisation format (talk)
• Disable raw HTML on wikimediafoundation.org (talk)
• Scoped language converter (talk) (possible ideas beyond the Parsoid plans in bug 41716)

Page protection and deletion

• Itemise protection (talk)
• Page protection as a component (talk)
• Page deletion (talk)

Security

• Login security (talk)
• AuthStack (talk)
• Passwords (talk)

UI/UX: usability and discoverability

• Core user preferences (talk)
• Clickable section anchors (talk)

User customization/filterability

• Dismissable notices (talk)
• Support for user-specific page lists in core (talk)

Wiki tasks management

• Tickets (talk)
• Workflow (talk)