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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to