-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 11/05/2013 05:57 PM, Erik Moeller 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.

Since this thread is about architecture and governance it makes sense to step back and look at the architecture and governance of our technical project(s).

In my humble opinion any step formalizing community roles should help separating concepts that are still tangled:

1. Wikimedia Foundation professional titles and roles vs open source community roles.

2. MediaWiki open source project meritocracy vs Wikimedia movement meritocracy.

For instance, the nomination of a MediaWiki release team with Mark & Markus was very helpful in these directions.

Open source community roles include admins, +2, release team members and, it seems, architects. The handling and discussion about community roles should be driven by the the open source project, not by the WMF.

The architecture of MediaWiki and the architecture of the Wikimedia infrastructure are different things. The meritocracy of the MediaWiki project and the meritocracy of Wikimedia tech should be different things.

Yes, there is a big overlap but the differences are relevant. If we talk about software architecture and community roles in this open source project, a thread like this could refer to "Architectural leadership in the MediaWiki project" and could be driven by the current community architects.

I hope this doesn sound too abstract or beyond the point of the thread because I believe it is at the core of the question. I don't have an opinion between the options suggested by Erik, because these questions come first:

Do the three architects consider themselves assuming this role as WMF employees or as community members?

Do they consider their roles to be part of a MediaWiki centric meritocracy or a Wikimedia centric meritocracy?

What is their opinion about moving forward their current team of three?

Because these three long-term contributors have earned their community reputation and are clearly smart, the chances are that many of us would agree with any common answer they would agree with themselves.

- -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

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.

Le 06/11/13 02:57, Erik Moeller a écrit :

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.

<snip>

Hello,

I would have a look at the way IETF is handling its RFC process. I wrote about it back in July in the thread "proposed RFC process":

http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070241.html

The workflow is as bureaucratic as you can imagine given the number of parties involved and all the political / commercial context that goes behind creating internet standards. You can still achieve a RFC pretty "quickly".

To scale out the architects roles, I would formalize the concept of self organized working groups. Their responsibility would be to produce a draft to be presented to a technical board. Once the standard is approved / implemented / released, the working group is disbanded.

How would it work?

Any individual having an idea would expose it on wikitech-l to gain people to its cause. They would form a self organized working group using whatever tools and practices they agree upon. The aim of the group would be to produce a draft.

The technical board would be made of the smartest people we have, ideally including non wikimedia people. To name a few, at the *very minimum* I would include Brion, Tim, Mark and Ori and definitely Daniel Kinzler from WMDE, probably adding Rob as the facilitator.

The board responsibilities would be: - provide support to the working group leaders - ensure working groups are progressing - handle conflicts between members of a group - ensure the working groups work are not overlapping - accept the produced drafts as RFC.

Whenever a working group publishes a draft, it would be reviewed by whoever is interested and amended until it has consensus. The draft is then proposed to the technical board which has the final word and publish the draft as a RFC.

As to who is going to implement the RFC, I guess it depends on who needs it in the first place. Most of the time it would be for Wikimedia, so the Wikimedia engineering managers would be responsible to get the standard implemented, released and deployed. The draft could well propose a working implementation as well.

If a working group is working on an ambitious feature, it could probably use some real life meeting from time to time.

The technical board could use some monthly meetings much like the RFC review IRC meeting we are already having.

Finally, the MediaWiki architecture summit would gather all the working groups members and technical board members with an agenda of drafts to approve or vision of the next working groups to form.

Example:

https://www.mediawiki.org/wiki/Requests_for_comment/LESS

Working group was Ori Livneh, Jon Robson, Steven Walling. They came with a draft and implementation after a few review cycles.

Along the process Brion stepped in to offer technical reviews/guidance.

Brion eventually accepted it by marking the RfC complete and merging the implementation.

End result: MediaWiki now supports LESS.

My ERROR: rounding error in '%s cents' % 0,02

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 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

[1] http://lists.wikimedia.org/pipermail/wikimediaannounce-l/2011-March/000130.h... [2] http://lists.wikimedia.org/pipermail/wikimediaannounce-l/2011-June/000186.ht... -- 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

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 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

[1] http://lists.wikimedia.org/pipermail/wikimediaannounce-l/2011-March/000130.h... [2] http://lists.wikimedia.org/pipermail/wikimediaannounce-l/2011-June/000186.ht... -- 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

On Tue, Nov 05, 2013 at 05:57:31PM -0800, Erik Moeller wrote:

So how should this role evolve going forward? Some possible paths (you know I like to present options ;-):

The "architect" title, besides the job description that you described, is also a seniority level within the WMF's engineering department. Other organizations do e.g. "sr./staff/sr. staff" and/or numeric levels, we do "associate / (blank) / sr. / (lead) architect". At least that's my understanding of what was presented during the last all-staff and documented on officewiki.

What would happen to this seniority level, if any of the options you presented were to be adopted? You seem to hint that there would be a mapping with option D ("salary increases") but it's not clear to me how direct of a mapping or a prerequisite would that be.

I don't think it'd reasonable to say that we have, as an organization with ~180 FT staff, a peer review process, an HR department, managers, directors & VPs *but* you can't be promoted inside the organization until an open community process says so (or, in case of option A, *at all*). It'd be even more illogical considering that currently no other positions exist where there is such a connection: this hasn't been the case for promotions to Sr. -- and, even in the leadership track, there have been promotions to managers, directors & VPs, with no such open community process.

If that's not the intention, on the other hand, I think it's useful to either hear WMF management's views on that or, if it is up for discussion, have this discussion in parallel with this one.

Whether we like it or not, the existing title has *two* meanings as it is —and my understanding is that the salary aspect came first, too— and I don't think we can have a meaningful discussion for the one without knowing the implications for the other.

Regards, Faidon

On Wed, Nov 6, 2013 at 2:57 AM, Erik Moeller erik@wikimedia.org wrote: ...

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.

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.

So how should this role evolve going forward? Some possible paths (you know I like to present options ;-):

...

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.).

besides beeing technically very capable, mark, brion, and tim are really nice persons on a personal level. they stay out of political discussions, are not arrogant, always concentrate on helping to evolve technically, and do not shy away from dirt work. as imo people tend to attract theirlikes, i would see also an option that each of them is allowed to choose the person who helps in their respective domain.

but, if you think its better to take option D, and mark, brion and tim think this helps i am all for it.

rupert.