Architecture Summit 2014/RFC clusters

=Background= 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:
 * Lightning talk 1 - 5 min
 * Short Q&A 1 (clarifications only) 5 min
 * Lightning talk 2 - 5 min
 * Short Q&A 2 (clarifications only) 5 min
 * Lightning talk 3 - 5 min
 * Short Q&A 3 (clarifications only) 5 min
 * General discussion (60 minutes)

=Clusters= The idea is that a cluster contains RFC's 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 RFC's should be in the same cluster. Clusters should also be small, probably not more than 3 or 4 RFC's per cluster.

This is a very first stab and will change, this is not definitive.

General Mediawiki Functionality (needs additional categorization)

 * Removing hit counters from MediaWiki core
 * Update our code to use RDFa 1.1 instead of RDFa 1.0
 * Retained account data self-discovery
 * Nonlinear versioning
 * Localisation format
 * Disable raw HTML on wikimediafoundation.org

Backend code modularity frameworks
Proposals that involve organizing our backend code to be more modular
 * MediaWiki libraries
 * Third-party components
 * Extension release management
 * Distribution and deployment
 * UserMailer Refactor
 * TitleValue

Backend templating
Proposals that involve adding an abstraction layer for server-side HTML generation
 * MVC Framework
 * OutputPage Refactor
 * HTML templating library
 * Template Engine

Configuration
Proposals that involve moving away from global variables as the standard way of configuring core and extensions
 * Configuration database
 * Configuration database 2
 * Json Config pages in wiki

Crosswiki
Topic cluster, not really for implementation most likely.
 * Regex-based blacklist
 * Global scripts
 * Structured data push notification support for recent changes

Installation

 * Opt-in site registration during installation
 * New sites system
 * Extension manager
 * Requests for comment/Extension management with Composer
 * Extension release management

Release process

 * Release notes automation
 * Distribution and deployment

Key-value stores

 * Storage service
 * DataStore

Metadata
Interacts with:.
 * Book management
 * Page metadata (required? by )

MediaWiki management

 * Overthrow Bugzilla
 * MediaWiki Foundation
 * Bugzilla taxonomy
 * MediaWiki.org Main Page tweaks

Mobile

 * Zero Architecture

Multimedia

 * More general frontend uploading tools
 * Image information (requires )
 * Refactor on File-FileRepo-MediaHandler

Page protection and deletion

 * Itemise protection
 * Page protection as a component
 * Page deletion

Parsing architecture
Proposals that involve big changes to how we think about parsing and wikitext
 * Parsoid/Roadmap
 * Scoped language converter
 * Text extraction

Parser changes
Smaller changes to parsing
 * New hook: ParserBeforePreprocess

Performance

 * Partial page caching
 * Performance standards for new features
 * Simplify thumbnail cache
 * CentralNotice Caching Overhaul - Frontend Proxy

Security

 * Password strength
 * Login security
 * AuthStack
 * Password requirements

SOA

 * Content API
 * Services and narrow interfaces
 * API roadmap
 * PHP web service interface

Software for/from third parties

 * Third-party components
 * Isolate custom jQuery libraries
 * MediaWiki libraries

SQL abstraction

 * SQL Framework
 * Abstract table definitions

UI/UX: styling

 * Grid system
 * Vertical writing support
 * Scoping site CSS
 * Allow styling in templates
 * Standardized thumbnails sizes

UI/UX: usability and discoverability

 * Core user preferences
 * Clickable section anchors

URLs

 * URL shortener service for Wikimedia
 * URL shortener
 * Clean up URLs
 * Drop actions in favour of page views and special pages

User customization/filterability

 * Structured logging
 * Dismissable notices
 * Support for user-specific page lists in core

Wikidata
Interacts with:.
 * Wikidata API

Wiki tasks management

 * Tickets
 * Workflow