On Tue, Nov 5, 2013 at 5:57 PM, Erik Moeller erik@wikimedia.org wrote:
tl;dr: I’d appreciate thoughts from the Wikimedia technical community at large whether the designation of individual technical contributors as "architects" should be meaningful, and if so, how to expand it beyond the original triumvirate (Brion, Tim & Mark), e.g. by transitioning to a community-driven process for recognizing architects.
Hi all,
in March 2011 and June 2011, Brion Vibber, Mark Bergsma and Tim Starling were announced as Lead Software Architect, Lead Operations Architect and Lead Platform Architect of the Wikimedia Foundation, respectively. Together, these three individuals laid much of the foundation of Wikimedia’s technical infrastructure, from MediaWiki itself to our caching and load balancing setup. So it was a logical step to recognize their immense contributions, and to entrust them with continued high-level stewardship in Wikimedia’s technical ecosystem.
Since then, WMF's engineering organization has grown pretty dramatically. We've also seen increased engagement in the Wikimedia technical community from other organizations. Wikimedia Germany is probably most notable among them with the Wikidata project, and Wikia has partnered directly on VisualEditor development and is generally striving to increase visibility of its open source modifications to MediaWiki.
At WMF, this has increasingly raised the question how the architecture of Wikimedia’s technical infrastructure can be evolved at this new, larger scale, and how we can bring more voices into that conversation. I've shared this note with the architects ahead of time and taken some initial feedback into account.
Rob Lanphier has taken a lead role in giving the RFC process a kick in the pants as a solid, asynchronous, transparent process for organizing and resolving technical proposals. Brion, Tim and Mark are explicitly listed as the three individuals who can close an RFC (interpreting or helping reach consensus, or making an informed decision where there’s a lack of community participation), and have helped clear the RFC backlog and evolve the architecture guidelines. In addition, Rob is organizing the MediaWiki architecture summit in January, where we can talk about some of the most pressing or contentious architectural questions in person.
However, Brion, Tim and Mark are not infinitely scalable, nor are they immortal (except in our hearts). They can’t be in every conversation, know every part of Wikimedia’s technical ecosystem, review every RFC, etc. We also have many other deeply talented technical contributors, including some who have many years of experience in our technical context specifically -- not just at WMF. Beyond just making technical decisions, architectural leadership creates opportunities for mentorship, modeling and nurturing the kind of behavior we want to foster in our technical community.
So how should this role evolve going forward? Some possible paths (you know I like to present options ;-):
Option A: We change nothing and don't promote any new people into architect roles for a while. I truly don’t think this is an option for much longer -- we need to find better ways to encourage some of our other capable technical contributors to feel ownership over Wikimedia’s technical direction, and fill gaps in architectural leadership today. That said, it would be possible to make the RFC process more egalitarian and to reduce the emphasis on formalized technical leadership.
Option B: WMF handles it as it sees fit. This basically means WMF gets to decide who to designate as "Architects" and at what point, which would mostly leave this decision in the hands of managers. This is a very WMF-centric view of the world, but it’s of course the way most organizations operate.
Option C: We get rid of the special role of architects. I personally don’t favor this option either, because I think recognizing the most sane and experienced voices in our technical community and according them some real leadership influence over Wikimedia’s technical direction is important (and a useful counterbalance to pointy-haired folks like yours truly ;-).
Option D: We come up with some kind of open process for designating/confirming folks as architects, according to some well-defined criteria (including minimum participation in the RFC process, well-defined domain expertise in certain areas, a track record of constructive engagement, etc.). Organizations like WMF can choose to recognize this role as they see fit (likely according salary increases to individuals who demonstrate successful architectural leadership), but it’s a technical leadership role that’s awarded by Wikimedia’s larger technical community, similar to +2 status.
Each of these would need to be unpacked and further developed. For option D in particular, I think it’s important to recognize that the level of impact beyond WMF for technical decisions varies significantly. While parts of WMF’s overall operating infrastructure are of interest to third parties, decisions that primarily relate to keeping our cluster and network secure, performant and stable are really ours to make and it’s unlikely that relevant architectural decisions would e.g. be driven by a third party employee. At the same time, we still aspire to making such work accessible and visible to volunteers.
I do think it’s possible to make option D work in a way that recognizes the need for different kinds of architectural leadership (e.g. MediaWiki development vs. network architecture), and that applies selection standards that are consistent with a role’s impact on the community.
I’m sure there are other possible ways to proceed as well (aren't there always :P) and would love to hear your thoughts.
All best,
Erik
I am in favor of preserving the status quo.
BDFLs are a very useful check on the tendency of technical discussions to devolve into bikeshedding. When this occurs, it is preferable to put the development community on track by having a decision procedure that vests an individual with the authority to make a call that everyone agrees to respect. As I interpret it, the sarcastic connotation of the term is meant to remind everyone (BDFLs included) that the title is bestowed on someone for practical reasons, and not because anyone thinks that BDFLs are infallible. The puck simply needs to stop somewhere, and the right person for the role is usually whomever is going to be the least objectionable and most likely to make sober judgment calls. The fact that the term is slightly absurd and mythical is useful, because it underscores the fact that the title has very little to do with fairness and everything to do with a shared interest in keeping things moving forward.
What you are proposing is that we determine who is infallible and benevolent, so we can style them dictators for life. This kind of wide-eyed earnestness about the term "architecture" is very dangerous. It misses the essential irony, and in so doing it risks transforming an institution which satirizes (and thus curbs) inscrutable authority with one that enshrines it.