User:KSmith (WMF)/ArchCom thoughts

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).

Vision
One vision of the Architecture Committee (ArchCom) is that it would become more of a high-level steering committee, and would perform some or all of the functions that in 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.

Scope
This vision for the committee’s scope extends beyond the architecture of MediaWiki. It includes 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 of ArchCom include: Note that many of those would normally be delegated to others, and ArchCom would only get involved as an arbiter or decider of last resort.
 * 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

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

RfC Process
Any major change to a process or technical direction should go through an RfC process, to ensure that the relevant stakeholders have had a chance to give input. After comments have been received and addressed, ArchCom would determine whether it has sufficient consensus to proceed to implementation. Note that different levels of consensus might be required for different proposals, based on size, risk, etc.

History
Prior to the RfC process, proposals would be emailed to wikitech-l, and discussion would happen there. A lack of discussion might be interpreted by some as an indication of consensus. This was formalized as the Requests for comment/Process, which directs the discussion to wiki pages and/or Phabricator tasks. See also Requests for comment.

Details
Anyone can draft an RfC. It must have an associated phab task, and will often have an associated wiki page. The phab task enters the ArchCom process by being added to the #ArchCom-RfC phab project. Tasks start in the Inbox column, where they can be triaged by RobLa or someone else in ArchCom.

An RfC generally goes through the following states: NOTE: It would be great to have a diagram showing the possible state changes
 * Needs triage
 * Not ready for ArchCom to consider
 * Needs an ArchCom shepherd
 * Only for “important” RfC’s; others could go straight to backlog
 * Backlog
 * Don’t even have a plan for a plan yet.
 * Might not have a shepherd if it’s not needed
 * In progress/on track
 * No consensus yet
 * ArchCom has said “the idea sounds good”
 * Developer is working (e.g. on a prototype) to help frame discussion or build consensus
 * Doesn’t need discussion; “maybe check back in 3 months”
 * Under discussion (via phab comments or other channels?) (“Needs Discussion”)
 * No consensus yet
 * RFC meeting might accelerate it
 * Ready for interactive RFC meeting (weekly on IRC)
 * Final comment
 * Approved

ArchCom shepherds
Each RfC is assigned a member of ArchCom to act as its “shepherd” The shepherd:
 * From https://phabricator.wikimedia.org/T125865 :
 * Makes sure that stakeholders are informed.
 * Guides the discussion.
 * Once the discussion plateaus or stalls & in coordination with the RFC author(s), announces and widely publicizes a "Final Comment Period", which is one week.
 * Acts as the single point of contact within ArchCom for communication about this RfC
 * (other shepherd responsibilities?)

Columns in #ArchCom-RfC

 * Backlog (blocked or draft)
 * Inbox
 * Needs shepherd
 * Under discussion
 * Ready for RFC meeting
 * Final comment
 * ArchCom Approved

Other related projects/workboards
#Architecture - No longer actively monitored. Candidate to be deleted?

#ArchCom - Unclear purpose. Probably need to update the phab project description.