My brief thoughts: * It makes sense to have a handful of folks as a core review & planning group.
* However, I would consider avoiding using the term "Architect" for its members as it's easily conflated with existing WMF job titles. I think job titles are pretty unreliable indicators at the best of times, and of course can be wildly inconsistent across companies. * I've got no particular patience for over-formal community processes like Wikipedia adminship voting, nor interest in replicating those processes. While there are plenty of problems with the traditional FOSS concept of "meritocracy", I still have great affection for the "do-it-ocracy" notion that folks who actually get stuff done should be recognized as fulfilling the roles they are performing. As such, I'd recommend a slightly more formal role for additional "lead reviewers" or "module owners" in the code review & RFC processes; not as *gatekeepers* so much as to provide a next-step for getting something moving that's stalled -- a potential contributor or a team within WMF working on a feature should be able to easily determine who to talk to about getting a go/no-go or advice on what to do in case of a no-go. (For comparison, I occasionally write patches for Firefox and Firefox OS; they have a *really full* bug tracker and your only hope of getting a patch reviewed is to actually request review from a particular person. A list of module owners like <https://wiki.mozilla.org/Modules/FirefoxOS> is a lifesaver for a casual contributor who doesn't know everybody on the Mozilla teams.) -- brion 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 > > [1] > http://lists.wikimedia.org/pipermail/wikimediaannounce-l/2011-March/000130.html > [2] > http://lists.wikimedia.org/pipermail/wikimediaannounce-l/2011-June/000186.html > -- > Erik Möller > VP of Engineering and Product Development, Wikimedia Foundation > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
