Thinking about this, I am somewhat afraid that any public voting process may become more similar to Requests for Bureaucratship (RfB).
For those not familiar with this process, it's an even more brutal thing than RfA (Requests for Adminship). Bureaucrats are socially the people that close the RfAs, and technically the only people with the ability to actually make someone an administrator. The typical support required to pass RfB is 90%, as opposed to the 70-75% [1] of RfA. For a while the RfB process was considered impossible to pass, which led people to relax their requirements of the candidates, and in turn led to the process being passable again! An interesting feedback loop for regulation of the process. The thing is, everyone on the English Wikipedia agrees that RfA sucks. Everyone just thinks it sucks for different reasons, so nobody can agree on a better process. I don't want to see this happen to any process that we come with. Dan [1]: There are exceptions to this, and people have passed with lower percentages. Chad on this list is one such exception. On 6 November 2013 01:57, 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 -- Dan Garry Associate Product Manager for Platform Wikimedia Foundation _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
