Requests for comment/Governance

Problem statement
The Wikimedia engineering community has traditionally made decisions using a mix of do-ocracy and rough consensus. In the last years, we have augmented this with a formal RFC process driven by the architecture committee. This has helped to broaden discussions, and resulted in a better shared understanding on a range of topics.

However, we are also seeing issues with the current process:


 * Lack of clarity on the overall technical direction of MediaWiki and the Wikimedia platform.
 * Difficulty of scaling the decision making process.
 * Stakeholder involvement & legitimacy.
 * Clarity and transparency of decision making process.

Prior art
[Goal: Give a brief summary and pointers to options we looked at.]

See also this prior etherpad discussion.
 * IETF process
 * Python PEP process
 * Rust
 * Debian
 * W3C

Strawman proposal
[Goal: Summarize key ideas that we consider worth adopting, and point to prior art. Provide rationale by explaining how each addresses specific issues.]

More structured RFC decision process
Based on the Rust decision making process.


 * Nominate a shepherd from a (sub)team to guide an RFC through the process.
 * 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.
 * At the end of the "Final Comment Period", the (sub)team decides based on the points made in the RFC discussion, and justifies its decision based on the overall project principles and priorities. If any new facts or aspects are surfaced in this discussion, a new Final Comment Period needs to be started before making a decision.

Scaling the decision making process with sub-teams
Based on Rust subteams.


 * The core team is responsible for creating sub-teams, with a member of the core team as its team leader. Initial membership is determined by the leader, later changes are by consensus within the team.
 * Each sub-team has a specific vision and problem set to work on, and the team leader is responsible for keeping the team on topic.
 * Sub-teams are empowered to decide on RFCs within their scope (subject to achieving wider consensus; see below). The team leader is responsible for elevating RFCs with unclear or broader scope to the core team.

Achieving consensus
Sub-teams are still asked to work toward consensus among interested parties with the shared goal of finding the best technical solution to a problem. Sub-teams are encouraged to enlist experts to ensure the sub-team has the right people to set the best direction.

The core team (ArchCom) serves as the "appeals court" in cases where a subteam has made a decision that hasn't yet achieved wider consensus and is disputed by the wider Wikimedia engineering community. Appeals are raised by means of RFC.