Wikimedia Technical Committee/Charter
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. |
This charter outlines how the Wikimedia Technical Committee or TechCom is expected to function. TechCom replaces 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
[edit]TechCom 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
[edit]TechCom 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 TechCom. The committee helps guide the vision and direction of the Wikimedia technical projects.
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
[edit]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. TechCom 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.
Policies regarding documentation targeted at developers are in scope. This particularly includes policies regarding source code documentation as well as documentation of system design. Documentation aimed at wiki users or wiki owners is not in scope.
The scope also 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
[edit]Any technical work that falls into one or more of these categories should be brought to the committee:
- Strategic
- Cross-cutting
- Hard to undo
TechCom 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 TechCom 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.
When TechCom 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 TechCom, the issue should be escalated through the CTO for resolution.
Process
[edit]The RFC process (Requests For Comment) is the default mechanism through which TechCom 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, TechCom 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 TechCom, they should be published and disseminated in ways that make it easy for the target audience to be aware of and find them.
TechCom decisions and recommendations are based on the expertise and judgment of its members, informed by input from others. In rare cases, TechCom could diverge from community consensus. Developers or teams who proceed counter to TechCom decisions should be prepared to provide their rationale for doing so. Conflicts can be escalated to the CTO.
TechCom does not make resourcing decisions. RFCs brought to TechCom should include a plan for how they will be implemented. When TechCom does feel strongly about priorities or resourcing, they would work with the CTO, who has influence and/or authority in those areas.
TechCom publishes its agenda and deliberations on mediawiki.org.
Membership
[edit]TechCom 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.
TechCom 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.