Hi folks,
Over the past few weeks (including WikiDev '16) we've had several
conversations the Wikimedia software development governance model.
For a lot of people, the most important aspect of this is MediaWiki.
More generally, though, the scope is about we deploy to Wikimedia
sites that we intend to maintain, enhance, and further leverage.
On Wednesday, January 20, we intend to continue this conversation, and
welcome your participation:
<https://phabricator.wikimedia.org/E135>
In particular, we plan to discuss the work that Gabriel Wicke started:
<https://phabricator.wikimedia.org/T123606>
"WIP RFC: Improving and scaling our technical decision making process"
...which is mainly a pointer to:
<https://www.mediawiki.org/wiki/Requests_for_comment/Governance>
I've quoted the current text as of this writing below, and you're
welcome to reply on list or on the talk page (though let's try to
ensure a summary of important comments gets captured on T123606).
Based on the conversations I've been part of (and Gabriel's initial
writeup), Rust's governance model seems to be the leading candidate to
iterate toward. This doesn't necessarily mean making one big change
with a fanfare-laden launch, but let's discuss.
Wait until Wednesday's IRC session if you have to (22:00 UTC, 14:00
PST), but we'd love to hear your thoughts sooner.
Rob
p.s. Here's the link to the RFC
<https://www.mediawiki.org/wiki/Requests_for_comment/Governance>
...and below is the plain text from [mw:Requests for comment/Governance].
Problem statement
[Goal: Describe the problem we are seeing with the current process,
and why it is important to solve them.]
Difficulty of making clear and accepted decisions on important and
broad topics.
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.]
IETF process
Python PEP process
Rust
Debian
W3C
See also this prior etherpad discussion.
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. The
team leader is responsible for elevating RFCs with unclear or broader
scope to the core team.