On Fri, Jan 16, 2015 at 5:04 AM, Rob Lanphier robla@wikimedia.org wrote:
Do we need a BFDL?
On Fri, Jan 16, 2015 at 8:18 AM, Erik Moeller erik@wikimedia.org wrote:
Within the organizational pattern we use, the way to complement Damon's and my roles is usually with a CTO
On Fri, Jan 16, 2015 at 7:57 AM, Tim Starling tstarling@wikimedia.org wrote:
The problem is that the (Architecture Committee) work is mostly administrative and not empowered. Committee members are skeptical of many of the current ideas floating around at the moment, and have their own ideas about what things should be priorities, but have no expectation that those ideas will be considered for resourcing.
(...) It's not a community open source project, it is an engineering
organisation with a strict hierarchy. We don't have a BDFL, we have a VPE.
We need a healthy MediaWiki open source software project in the first place. Without this, no committee, dictator or CTO will save the project in the long run. And Wikimedia works for the long run.
Wikimedia is a movement and MediaWiki is an open source software project. While the Wikimedia Foundation plays a key role in the development of MediaWiki, the structure of the open source project must be driven by community merit. The MediaWiki platform roadmap should be discussed and agreed at a community level. Resourcing should be a consequence of technical agreement, not the cause. Project roles should be a consequence of project merit, not the cause. The WMF Engineering structure should support and complement the MediaWiki OSS community structure, not replace it.
The five people forming the Architecture Committee are in a privileged position, receiving the support from the MediaWiki developer community and the WMF Engineering management. I don't think dismantling this team is a good idea both in terms of open source project and WMF competence and health, no matter how problematic the current situation is. The rest of us should help moving the current situation forward, not backward.
Tim identifies lack of empowerment and top-down WMF management as key problems. Opinions might differ interpreting the current situation, but I guess all of us agree that an architecture committee can only work if they are empowered to be co-pilots of the MediaWiki platform roadmap.
However, it is true that the current situation is not sustainable. The ArchCom is not directly active in the WMF quarterly planning (some of its members take part, but they do it mainly because of their WMF individual roles). Meanwhile, most of the ArchCom work goes to administrative work and RfC discussions that are not among the top priorities of the project. A missed opportunity, certainly.
The first steps to fix this problem could be:
* Identification of key MediaWiki platform areas and their architects / maintainers. Currently "MediaWiki Core" has no less than 210 components identified at https://www.mediawiki.org/wiki/Developers/Maintainers . We should have just a handful of areas covering all these components, with owners identified and empowered to keep their area tidy and build the roadmap with the rest of architects.
* Prioritization of architecture topics, so we all agree at least on what is urgent/important. https://phabricator.wikimedia.org/tag/architecture/ and https://phabricator.wikimedia.org/tag/mw-rfcs/ are a step forward, but they still don't reflect the priorities needed.
If the current ArchCom grows to include the architects of MediaWiki areas, and if this wider team gets regularly involved in prioritization of architecture tasks, RfC discussions, and WMF platform planning... probably we will go in the direction we want this big software project to go. Only then I would start discussing the need of a BFDL or a CTO. Considering the appointment of one of these roles before addressing the core of the problem would put us more in a compromise, imho.