Wikimedia Technical Committee/Charter

This charter outlines how the Wikimedia Technical Committee or T-Comm is expected to function. T-Comm would replace the existing Wikimedia Architecture Committee (ArchCom), inheriting its membership and basic structure. The new name more accurately reflects the proposed new scope and mandate.

Mission Statement
T-Comm is the guardian of the integrity, consistency, stability and performance of the software supporting the Wikimedia projects. It acts as the senior advisor and the convergence point of all decisions related to technical work that is strategic, cross-cutting, and/or hard to undo.

Purpose
T-Comm is really an extension of the CTO’s role. Within Wikimedia, technology leadership is not vested in a single individual, but in the technical community. That leadership is focused in T-Comm.

The Wikimedia Technical Committee will make decisions and set policies regarding high-level technical issues. Those decisions will be informed by discussions with and between interested members of the technical community.

Areas within scope
The scope of the committee includes 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. T-Comm will work closely with teams within the foundation to ensure alignment between the architectural vision and product development.

The committee has standing on questions around architecture, performance, security, database schemas, automated tests, and other technical matters.

The scope does not include developer tools, software running as Wikimedia Cloud Services (formerly "Labs"), or other non-production technologies. Nor does its scope include hardware, team methodologies (e.g. agile/scrum), code of conduct, and other social factors.

Types of issues within scope
Any technical work that falls into one or more of these categories should be brought to the committee: T-Comm members cannot monitor every possible repository commit or Phabricator task, so they must rely on the cooperation of others. Developers with +2 rights in any repo deployed at Wikimedia or included in MediaWiki tarballs, as well as managers or others who work with those technical projects, should watch for relevant issues. Anyone who sees an issue matching the above criteria which T-Comm is not already aware of should alert the committee, regardless of who is doing the work. This is similar to how performance, security, and legal concerns should be raised by anyone who notices a potential issue.
 * Strategic
 * Cross-cutting
 * Hard to undo (because it creates artifacts or exposes new public interfaces)

When T-Comm becomes aware of an issue that falls within their scope, they might choose to route it through one of their processes. If the proponent of the work disagrees with any actions or recommendations made by T-Comm, the issue should be escalated through the CTO for resolution.

Process
The RFC process (Requests For Comment) is the default mechanism through which T-Comm works. In addition to reviewing relevant proposed technical work, the RFC process can be used to refine and ratify policies and guidelines. Anyone (including committee members) can propose a new policy or guideline through the RFC process.

When presented with an RFC, T-Comm might decide that the issue does not fall within their scope. Depending on the specific case, they might have brief or lengthy discussions, in private or in public, before issuing a decision. The goal is to avoid having the committee itself be a bottleneck.

Once policies or guidelines have been approved by T-Comm, they should be published and disseminated in ways that make it easy for the target audience to be aware of and find them.

T-Comm decisions are based on the expertise and judgment of its members, informed by input from others. In rare cases, T-Comm could diverge from community consensus. Their decisions are not binding. However, if a developer or team proceeds counter to T-Comm recommendations, they should be prepared to provide their rationale for doing so.

T-Comm does not make resourcing decisions. RFCs brought to T-Comm should include a plan for how they will be implemented. When T-Comm does feel strongly about priorities or resourcing, they would work with the CTO, who has influence and/or authority in those areas.

T-Comm publishes its agenda and deliberations on mediawiki.org.

Membership
T-Comm members should collectively bring skills and experience from a wide range of teams and disciplines. The WMF CTO is automatically a member.

Each member is expected to be available at least 4 hours per week for committee work. That includes meetings, administrative work, and technical work. For this to be practical, someone not on the committee will need to take on much of the administrative work which, so far, has either been done by members or has not gotten done.

T-Comm has full discretion over adding or removing members, with the CTO having veto power. Committee membership is not tied to employment by the WMF or any other organization. The target size is about 10 members.