On Fri, Jan 16, 2015 at 5:04 AM, Rob Lanphier <ro...@wikimedia.org> wrote:

> Do we need a BFDL?



On Fri, Jan 16, 2015 at 8:18 AM, Erik Moeller <e...@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 <tstarl...@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.

-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to