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.

Backend code modularity frameworks
Proposals that involve organizing our backend code to be more modular

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

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

Crosswiki
Topic cluster, not really for implementation most likely.

Installation

 * Requests for comment/Extension management with Composer
 * Requests for comment/Extension management with Composer
 * Requests for comment/Extension management with Composer
 * Requests for comment/Extension management with Composer

Metadata
Interacts with:.

Parsing architecture
Proposals that involve big changes to how we think about parsing and wikitext
 * Parsoid/Roadmap

Parser changes
Smaller changes to parsing

Wikidata
Interacts with:.