User:KSmith (WMF)/ArchCom thoughts/Vision

Context

This page is the work of Kevin, informed by conversations with RobLa (and others). It is very draft-y, and completely unofficial. I am not advocating for this vision (nor against it). I am merely documenting it, so at some point it could be discussed and debated. The goal is for it to get to a state where it can move out of my user space. Until then, I'll continue to work on it here, hopefully with collaboration from others (including Robla).

Overview

Many FLOSS projects are handled by a “Benevolent Dictator” or BDFL (Benevolent Dictator For Life). Examples of BDFL include Linus for Linux and Guido for Python. A working model for a similar committee can be found in various teams of the Rust language project (Swift also has a very similar process). This includes "architecture", both of the software and related systems, but extends to other areas as well.

MediaWiki and/or the Wikimedia production clusters might benefit from having a high-level steering committee, which would perform some or all of those functions. The Architecture Committee (ArchCom) already takes on some of these responsibilities, to varying degrees. The steering committee described in this document could be a successor to ArchCom, or might become an umbrella above ArchCom, or perhaps ArchCom itself could evolve to fit this larger scope.

Scope

This new committee’s scope would extend beyond the architecture of MediaWiki. It would include all the software run on the Wikimedia production servers, and by extension, the processes (like code review) that lead to the generation of the code. It could even extend to issues of community culture (where here “community” is the greater MediaWiki developer community, not the content communities such as wikipedia editors).

Areas that could potentially fall within the bounds include:

• Overall roadmap and direction of MediaWiki (and extensions that are running on the production cluster)
• Technical design of major new features
• Shepherding RfCs (Requests for Comment) through discussion, and making final decisions
• Coding conventions
• Performance and optimization concerns
• Security concerns
• Tool support
• Infrastructure, including code repositories, continuous integration (CI),
• Developer community norms, such as mailing list etiquette

Note that the committee wouldn't be making decisions in all those areas, but it would have a say in how those decisions got made.

One proposed dividing line could be that the committee would have overall responsibility for everything on the cluster that isn't specifically managed by ops.

Philosophy

The committee's purpose would not be to make technical decisions, except when it is absolutely necessary to do so. It would be to help the technical community make decisions. Decisions are best made in the open, based on input from all interested parties. Unanimity would almost never be required, and even consensus might not be helpful, as it can lead to the dysfunction of "designed by committee". The "teal organization" model (described in the book Reinventing Organizations) might be a good fit here.

Someone proposing an idea should document the idea in enough detail for it to be reviewed by others. Concerns and criticisms should be addressed in some way, even if just to acknowledge them and to disagree, or to accept the risks. The committee would manage the processes related to those reviews, as well as providing advice and input where appropriate. Committee members would participate in the conversations, but their technical comments would not have special status. This would be an RfC process, as described below.

Membership

TBD.