[Wikitech-l] MediaWiki Developer Summit: Future of the Architecture Committee

Hi all, A late notice for people at MWDS, and my apologies for everyone else. We (ArchCom + me) have belatedly added a session called "Future of the Architecture Committee" after the "How MediaWiki Slows Us Down" plenary, which will be at 1:45pm PST on Tuesday (tomorrow) Task associated with this: https://phabricator.wikimedia.org/T87605 Here's the list of questions we currently plan to tackle: 1. Should the ArchCom continue to exist as a committee with regular meetings? 2. Who takes care of RFCs? 3. Who drives paying down technical debt? 4. How does ArchCom/whatever integrate with quarterly planning at WMF and in the MediaWiki dev community in general? I've included my earlier email below titled "No more Architecture Committee?" as refresher prereading for this (and ignore my rampant transposition of the middle letters of BDFL, though in my defense, the BDFL issue is a BFD) :-) Rob ---------- Forwarded message ---------- From: Rob Lanphier <robla(a)wikimedia.org> Date: Thu, Jan 15, 2015 at 8:04 PM Subject: Fwd: No more Architecture Committee? To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> (Alright...let's try this again!) Hi everyone, The current MediaWiki Architecture Committee[1] has its roots in a 2013 Amsterdam Hackathon session[2], where we had a pair of sessions to try to establish our architectural guidelines[3]. It was there that we agreed that it would be good to revive our then moribund process for reviewing RFCs[4]. Since no one there really knew whose job it was to review these things, I believe I said "how about we start with everyone with 'architect' in their title at WMF?", which was met with uncomfortable shrugging that I interpreted as "consensus!", and no one corrected me. Thus Brion Vibber, Mark Bergsma, and Tim Starling became the founding members of the Arch Committee. Subsequent to that meeting, I pretended to proceed as though a decision was made. However, over the past year and half since then, there's been much more uncomfortable shrugging. Even Brion, Mark, and Tim have not seemed entirely comfortable with the idea. It was widely acknowledged that the group was heavily biased toward the lower parts of our server software stack. The committee agreed to add Roan Kattouw and Daniel Kinzler to the group as a means of providing a wider perspective, with the added bonus of adding at least one person who isn't a WMF employee. So, here we are today. I believe no one would dispute the credentials of every member of the group. Brion, Tim, and Mark have an extremely long history with the project, being employees #1, #2, and #3 of the WMF respectively, and all having contributed massively to the success of Wikipedia and to MediaWiki as general purpose wiki software. In most open source projects, one of them would probably be BFDL[5]. Roan and Daniel are more "recent", but only in relative terms, and also have very significant contributions to their name. All have the widespread respect of pretty much everyone in the MediaWiki developer community. Additionally, I hear quite a bit of relief that the previously moribund RFC process is doing much better now. Things are moving, and if you know how to work the process and aren't proposing anything too wild, you can get an RFC approved pretty quickly. The committee has made a lap through the entire backlog of RFCs. Still, the uncomfortable shrugging continues. The group is broader, but still lacks the breadth, particularly in front end and in the development of newer services such as Parsoid and RESTBase. This aspect is pretty obviously something that can be fixed. Another problem is that the scope of the group isn't clear to everyone. Is this group responsible for leading, or merely responsible for reviewing big ideas from others to ensure continuity and sanity? How big does an idea need to be before an RFC needs to be written (as opposed to just dropping a patch in Gerrit)? Defining the scope of the group is also a fixable problem. However, I don't sense much of a desire to fix things. The dominant meme that I hear is that we should go back to the day before uncomfortable shrugging led to a committee becoming BFDL. What I fear, though, is that we will develop a system lacking in conceptual integrity[6], as individual warring fiefdoms emerge. It's quite simple to argue this is already happening. So, where does that leave us? Do we need a BFDL? If so, who should pick? Should it be someone in the project? Should the WMF hire someone to lead this? If not, do we keep the committee? Do we just let this be consensus based? On the leadership front, let me throw out a hypothetical: should we have MediaWiki 2.0, where we start with an empty repository and build up? If so, who makes that decision? If not, what is our alternative vision? Who is going to define it? Is what we have good enough? In general, I feel a sense of urgency that seems lacking in the status quo. We've made progress over the past couple of years, but it doesn't feel like our progress is entirely up to the task. We have a collection of *many* instances of individual or small team excellence that are sadly the mere sum of their parts. My intuition is that we lose out on multiplicative effects as we fail to engage the wider group in our activities, and as we lack engineering-level orchestration. Team-level pride in fantastic work drifts into project-level despair, as many excellent engineers fail to grasp how to make big changes outside of their limited domains. Perhaps I'm being too hyperbolic. Perhaps the answer is "embrace the chaos; it's the Wiki Way(tm)" I don't buy it, but I'm probably one of the easier people to convince of this. I think if this is the way it's gonna be, someone needs to make the case how this is actually working now. Step up. Perhaps I'm also suffering from living inside the WMF echo chamber for too long. It could be that the general pessimism about the direction of MediaWiki (or lack thereof) is not shared out here. Perhaps people who get most of their news from this mailing list are perfectly happy with the status quo, and appreciate the balance we've struck with our weekly meetings and a committee whose membership is not entirely static. To be clear here: this is not an announcement about actually disbanding the committee. Even though I had a hand in creating it, it'd be dumb for me to unilaterally pressure the committee to disband. I may nudge and cajole (like I'm doing here), but I'm first and foremost looking to figure out what the consensus is, and then follow through on it. Discuss. Rob [1] https://www.mediawiki.org/wiki/Architecture_committee [2] https://www.mediawiki.org/wiki/Architecture_meetings/Amsterdam_Hackathon_20… [3] https://www.mediawiki.org/wiki/Architecture_guidelines [4] https://www.mediawiki.org/wiki/Requests_for_comment [5] https://en.wikipedia.org/wiki/Benevolent_dictator_for_life [6] http://c2.com/cgi/wiki?ConceptualIntegrity