User:KSmith (WMF)/ArchCom presentation

What is this page
I have been asked to draft a presentation which describes the new purpose and structure of the Architecture committee. This page is a place where I can write the text, and then ask for feedback.

My goal is to synthesize the thinking of the CTO and the existing committee members. Undoubtedly some of my own biases and preconceptions will show up in the text, and I am relying on the review cycle(s) to correct those.

How to collaborate
Please help me develop this page. If you have questions, concerns, or suggestions, please use the talk page (Discussion tab). If you feel strongly about a specific change, or if you believe it would be uncontroversial, you can go ahead and directly edit the text here. I'll see the change, and if I have concerns about it, I'll let you know.

High-level need
Every large body of software needs someone to steer it. Someone who understands the high-level goals, and the technical details. Someone to hold an architectural vision, and to ensure development is consistent with it.

Placing this responsibility in a committee is both practical (it would probably be impossible for an individual) and aligns with our values around collaboration.

There should also be clear processes and channels to have conversations, to build consensus, and to communicate decisions, around large technical issues.

''Questions: Should this say something about coordinating between different groups, like MWF/WMDE? Should this say something about encouraging alignment between long-term vision and WMF team goals and plans?''

What is not currently working
The existing Architecture Committee (archcom) was established in 2014, with members being added and removed over the years. Its focus has been on reviewing and approving RFCs (Requests for Comment). It has done valuable work, but there are some areas for improvement:
 * It is not always clear what warrants an RFC and what doesn't
 * The RFC process can take a long time and move slowly
 * There is no clear mandate to be proactive, as opposed to reacting to proposed RFCs
 * Some important functional areas (e.g. operations) are not represented on the committee
 * There are no defined processes to drive improvements at a very high architectural level
 * It unclear whether committee members should make decisions based on their own expertise, or should just follow the consensus of the technical community

Overview of proposed solution
We propose a new charter for archcom. One that clarifies its scope and expands its membership. The new archcom would be more proactive, would try to focus on issues at a higher level, and would best use the talents of its members.

Mission statement (of the committee)
The Architecture Committee is the guardian of the integrity, consistency, stability and performance of the software related to wikimedia projects. It acts as the senior advisor and the convergence point of all technical cross-cutting issues such as data management, security and architecture integrity.

Scope (of the committee)
The committee is responsible for all the official software that serves wikimedia users. That includes Mediawiki and extensions, services, and mobile apps. It includes any bots, gadgets, skins, etc. that run on production clusters. It does not include developer tools, software running as WIkimedia Cloud Services (formerly "labs"),

The committee has standing on questions around architecture, performance, security, database schemas, automated tests, and other technical factors. It does not officially control processes such as hardware, deployment scripts, code review, team methodologies (e.g. agile/scrum), code of conduct, and other social factors.

Membership
Committee members are selected based on their expertise, experience, and judgment, relative to Mediawiki and related systems. Members need not be employed or associated with any specific entities (such as the WMF). Members are added or removed by the committee itself.

Potential processes (extremely high level)
The committee would hold regular private meetings, and public meetings (on IRC) as needed. They would continue to manage an RFC process similar to the existing one. They would also oversee task forces/working groups, which would include both committee members and non-members, who would focus on a specific technical issue.

The details would be up to the committee, and could change over time.