Architecture Summit 2014/Architectural value, guidelines, and process

Subpage for the discussion of what we value in our current codebase, how to reflect that in the architecture guidelines, and tweaks to our RFC process at the summit.

Overview
We need to find the valuable examples in our architecture and codebase to see what good ideas we should replicate (or not break) in the future. That way we can add those lessons to the architecture guidelines.

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

 * What did we do right in the past?
 * What lessons do we draw from those examples?
 * 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 are the next steps?
 * 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 should we prioritize the resolution of RFCs?
 * Does it make sense to prioritize RFCs such that it's possible to target specific MediaWiki releases? (e.g. 1.24)?
 * Looking at MediaWiki's past architecture decisions, what are the pieces / decisions / directions are you most proud of, or have come to appreciate the most?
 * Where is your ideal balance between "architectural purity" vs. maximizing performance vs. developer's time to build?

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