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.
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. For wikimedia, this includes coordinating with WMF Product and Technology teams, and with affiliated technical organizations like WMDE.
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.
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.
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.
Purpose and mandate
The Architecture Committee will make decisions and set policies regarding architectural and high-level technical issues. Those decisions will be informed by discussions with and between interested members of the technical community.
The committee will work closely with the WMF Product and Technology departments (including the Mediawiki team), and with other organizations like the WMDE, to encourage alignment between product development and long-term platform goals. The committee is organized and funded by the WMF, but represents the entire technical project and community, and ultimately the movement.
The committee is responsible for all the official software that serves wikimedia users. That includes Mediawiki and extensions, services, and other software running on the production cluster, along with official mobile apps. Archcom will work closely with Product teams to ensure alignment between the architectural vision and product development. The scope does not include developer tools, software running as WIkimedia Cloud Services (formerly "labs"), or other non-production technologies.
The committee has standing on questions around architecture, performance, security, database schemas, automated tests, and other technical factors. It does not officially control hardware, deployment scripts and processes, code review, team methodologies (e.g. agile/scrum), code of conduct, and other social factors.
Committee members are selected based on their expertise, experience, and judgment, relative to Mediawiki and related systems.
Archcom should have members who represent specific teams within the WMF, including Operations and Product. However, members need not be employed or associated with any specific entities, and representation from outside the WMF is expected.
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.
How does this relate to the new Mediawiki team?
The Mediawiki team is focused on the Mediawiki software itself, while archcom has a much broader scope. Also, the Mediawiki team will take on some engineering work itself, while archcom only deals with discussions, decisions, and planning.