Architecture Summit 2014/Architectural value, guidelines, and process

Subpage for the discussion of the architecture guidelines and our RFC process at the summit.

Overview
Problems in our RFC process:
 * Unclear expectations. What does an RFC have to contain to get considered? How long will it take? Whose opinion counts? How do I know whether my group's work can just happen without an RFC?
 * It's hard to write an RFC. We aren't all good at writing. How do I get writing/editing help?
 * We don't agree on what good code and good architecture looks like. We waste time arguing and reinventing the wheel. How do I start my idea in the right direction?
 * RFCs get lost. Owners don't reply to questions, and non-viable proposals clutter up the list. How do we keep momentum on the viable RFCs and dispense with the non-viable ones faster?

Big Questions

 * Is our RFC process good enough as it is?
 * Logistics:
 * Should we add time limits to any part of the process?
 * Is ownership working?
 * Should we require that RFCs get co-sponsors in order to be considered?
 * Could we please number RFCs?
 * Should we version RFCs?
 * Can we finish the Architecture guidelines?
 * What needs RFCing?
 * Should we just have one RFC process, or a few different processes (e.g. fast-track)?
 * Which extensions require RFCs for big changes?
 * How do we ensure that WMF does not do all the decision-making regarding changes that affect MediaWiki generally?
 * Separate "general idea doesn't suck" review from "yup, we're all on board with this implementation" review?
 * Writing good RFCs:
 * Should we have a group of editors who help do administrative work on RFCs?
 * How does this process dovetail with release engineering?

Agenda
Etherpad: https://etherpad.wikimedia.org/p/RFC_process_summit
 * 10 minutes - overview of problems and questions
 * 30 minutes - discussion