On Tue, Nov 5, 2013 at 5:57 PM, Erik Moeller <[email protected]> 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. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
