Requests for comment/Governance
| Governance | |
|---|---|
| Component | Collaboration |
| Creation date | |
| Author(s) | Gabriel Wicke, Rob Lanphier |
| Document status | declined |
Problem statement
editThe 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 (including lack of rationale and reasoning behind decisions).
Prior art
editRFC-based technical decision making has a long history, starting with Arpanet in the late 1960s. Prominent examples are:
- IETF process
- Python PEP process
- Rust
- Debian
- W3C
- ZeroMQ Collective Code Construction Contract (42/C4)
- Swift Evolution Process
Several members of ArchCom looked into several of these models on the third day of WikiDev16, and recorded some notes in this etherpad discussion (mirrored at Requests_for_comment/Governance/2016-01-06 meeting)
Strawman proposal based on Rust
editThe Rust community's governance process seems to be especially suitable for our needs and philosophy. In the last year, they faced similar challenges to ours, and managed to scale to 331 RFCs by 127 community members, of which 161 were accepted and merged[1]. While heavily drawing on prior art (Python and IETF in particular), their process seems to be very streamlined for modern online collaboration, and is well documented in a thoughtful RFC.
The two ideas I think we should in particular adopt are these:
More structured RFC decision process
editBased on the Rust decision making process.
- Nominate a shepherd from a working group 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 working group 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. The goal is to reach as wide consensus among discussion participants and working group as possible. In case of lack of consensus in the working group, the group leader can make a decision in consultation with the ArchCom.
Scaling the decision making process with affiliated working groups
edit"Working groups" in this document are based on Rust subteams.
- The ArchCom is responsible for spinning up or shutting down working groups, with a member of the ArchCom as its working group leader. Initial membership is determined by the leader, later changes are by consensus within the working group.
- Each working group has a specific vision and problem set to work on, and the working group leader is responsible for keeping the working group on topic.
- Working groups are empowered to decide on RFCs within their scope, following the Rust decision making process.
- The working group leader is responsible for elevating RFCs with unclear or broader scope to the ArchCom.
- In case of conflicts, the ArchCom can intervene to ensure that decisions are made in line with the overall project principles and priorities, and the agreed upon processes are followed.