Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Foundation

Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure

 

 

Wikipedia foundation RSS feed   Index | Next | Previous | View Threaded


p858snake at gmail

Nov 6, 2012, 11:30 AM

Post #1 of 17 (757 views)
Permalink
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure

(Double Post, Since this was crossposted in the first place, and to
make sure I hit both lists, Sorry Wikitech)

On Tue, Nov 6, 2012 at 1:03 PM, Erik Moeller <erik [at] wikimedia> wrote:
> The way we’d get there:
>
> I’m prepared to resign from my engineering management responsibilities
> and to focus solely on my remaining role as VP of Product, as soon as
> a successor for VP of Engineering has been identified. We would start
> that hiring process probably in early 2013. I’m recommending to Sue
> that we seriously consider internal candidates for the VP of
> Engineering role, as we have a strong engineering management team in
> place today.
>
> So realistically we'd probably identify that person towards the end of
> the fiscal year.

Due to the nature of the foundation and to ensure continued growth and
prosperity I would be hoping that the foundation ensured both
positions became "vacant" and the person/s are chosen on the merits of
their applications to ensure the continued and best growth.

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


nemowiki at gmail

Nov 7, 2012, 8:40 AM

Post #2 of 17 (726 views)
Permalink
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure [In reply to]

Crossposting is tricky – Sue's answer didn't reach wikimedia-l as far as
I can see. From
http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064281.html :
----
Hi K. Peachey,

Generally speaking, the WMF posts and boards for every vacancy. (I
think there's a policy document somewhere to that effect --
regardless, it's been our practice for years.) Sometimes we skip the
posting & boarding process if there's a sufficiently compelling
reason, but mostly we post and board every position.

And so yes, indeed, we will post and board the head of Engineering
vacancy, because it's a newly-created position, and it's vacant. We
won't be posting and boarding the head of Product, though, because it
is not a newly-created position and it's not a vacancy. Even though
the responsibilities and scope of the role are shifting, it is an
existing position, and it has an incumbent (Erik).

Thanks,
Sue
----
K. Peachey, 06/11/2012 20:30:
> (Double Post, Since this was crossposted in the first place, and to
> make sure I hit both lists, Sorry Wikitech)
>
> On Tue, Nov 6, 2012 at 1:03 PM, Erik Moeller <erik [at] wikimedia> wrote:
>> The way we’d get there:
>>
>> I’m prepared to resign from my engineering management responsibilities
>> and to focus solely on my remaining role as VP of Product, as soon as
>> a successor for VP of Engineering has been identified. We would start
>> that hiring process probably in early 2013. I’m recommending to Sue
>> that we seriously consider internal candidates for the VP of
>> Engineering role, as we have a strong engineering management team in
>> place today.
>>
>> So realistically we'd probably identify that person towards the end of
>> the fiscal year.
>
> Due to the nature of the foundation and to ensure continued growth and
> prosperity I would be hoping that the foundation ensured both
> positions became "vacant" and the person/s are chosen on the merits of
> their applications to ensure the continued and best growth.
>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l [at] lists
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
>

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


sgardner at wikimedia

Nov 7, 2012, 8:51 AM

Post #3 of 17 (725 views)
Permalink
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure [In reply to]

On 7 November 2012 08:40, Federico Leva (Nemo) <nemowiki [at] gmail> wrote:
> Crossposting is tricky Sue's answer didn't reach wikimedia-l as far as I
> can see. From
> http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064281.html :

Oh thanks, Nemo. I don't know what went wrong there, but I appreciate
you catching it :-)
Sue

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


quimgil at gmail

Nov 7, 2012, 10:00 AM

Post #4 of 17 (728 views)
Permalink
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure [In reply to]

Hi, am I the only one having difficulties understanding the proposal and
what it implies?

On 11/05/2012 07:03 PM, Erik Moeller wrote:
> we need to split the current department into an engineering dept
> and a product dept in about 6-8 months.

It is strange to see "engineering" and "product" side by side, since (as
i understand them) these words belong to different categories. :)

Do you mean a "platform" team and "product" team, both filled with
engineers and other profiles but each one focusing on different things?
The MediaWiki (platform) team and the Wikimedia (product) teams, so to say?

Or are you indeed referring to the classical separation between "product
managers + designers" and "developers + testers"? The first ones
defining requirements and the second ones implementing them?

Or something else? Reading your email +
http://wikimediafoundation.org/wiki/Staff_and_contractors +
http://www.mediawiki.org/wiki/Wikimedia_Engineering wasn't enough for me
to understand.

What is clear from your email is that the current Engineering team is
underrepresented at a high level and you Erik have too much in your
bucket. A split and flattening getting more people in the high decision
levels makes total sense.

What also seems to be clear is that such reorganization should solve the
slightly schizophrenic tension of priorities between Wikimedia/product
and MediaWiki/platform, right?

Whatever the result, I hope we end up with teams where software
developers, sysadmins, product managers, designers etc are well mixed in
focused teams going after clear common goals.

--
Quim

> To avoid fear and anxiety, and to make sure the plan makes sense, I
> want to start an open conversation now. If you think any of the below
> is a terrible idea, or have suggestions on how to improve the plan,
> Id love to hear from you. Ill make myself personally available to
> anyone who wants to talk more about it. (I'm traveling a bit starting
> tomorrow, but will be available via email during that time.) We can
> also discuss it at coming tech lunches and such.
>
> Theres also nothing private here, so Im forwarding this note to
> wikitech-l@ and wikimedia-l@ as well. That said, theres no urgency in
> this note, so feel free to set it aside for later.
>
> Heres why Im recommending to Sue that we create distinct engineering
> and product departments:
>
> - Itll give product development and the user experience more
> visibility at the senior mgmt level, which means well have more
> conversations at that level about the work that most of the
> organization actually does. Right now, a single dept of ~70 people is
> represented by 1 person across both engineering and product functions
> - me. That was fine when it was half the size. Right now its out of
> whack.
>
> - Itll give us the ability to add Director-level leadership functions
> as appropriate without making my head explode.
>
> - I believe that separating the two functions is consistent with Sues
> recommendation to narrow our focus and develop our identity as an
> engineering organization. It will allow for more sustained effort in
> managing product priorities and greater advocacy for core platform
> issues (APIs, site performance, search, ops improvements, etc.) that
> are less visible than our feature priorities.
>
> A split dept structure wouldnt affect the way we assemble teams --
> wed still pull from required functions (devs, product, UI/UX, etc.),
> and teams would continue to pursue their objectives fairly
> autonomously.
>
> Its not all roses -- we might see more conflict between the two
> functions, more us vs. them thinking, and more communications
> breakdowns or forum shopping. But net I think the positives would
> outweigh the negatives, and there are ways to mitigate against the
> negatives.
>
> The way wed get there:
>
> Im prepared to resign from my engineering management responsibilities
> and to focus solely on my remaining role as VP of Product, as soon as
> a successor for VP of Engineering has been identified. We would start
> that hiring process probably in early 2013. Im recommending to Sue
> that we seriously consider internal candidates for the VP of
> Engineering role, as we have a strong engineering management team in
> place today.
>
> So realistically we'd probably identify that person towards the end of
> the fiscal year.
>
> Obviously I cant make any promises to you that in that brave new
> world, youll love whoever gets hired into the VP of Engineering role,
> so theres some unavoidable uncertainty there. Ill support Sue in the
> search, though, and Im sure shed appreciate feedback from you on the
> kind of person who you think would be ideal for the job.
>
> The VP of Product role would encompass a combination of functions.
> Howie and I would work with the department to figure out what makes
> sense as an internal structure. My opening view is that Analytics and
> User Experience are potential areas that may benefit from dedicated
> Director-level support roles. (Analytics is tricky because it includes
> a strong engineering piece, but also a research/analyst piece working
> closely with product.) The new structure would therefore be as
> follows:
>
> * VP of Engineering -> Directors of Engineering
> * VP of Product -> Director of Product Development, plus new
> Director-level functions (we've discussed UX/Design as a likely new
> leadership function, and Analytics as a _potential_ area to centralize
> here because it works so closely with product)
>
> Why Product? Im happy to help the org in whatever way I can; I
> believe Id be most useful to it in focusing there and helping build
> this relatively new organizational function. Based on my past
> experience, Howie & I make a great team. I know how engineering
> operates, which could help mitigate against some of the aforementioned
> issues. Plus, our product priorities generally already reflect lots of
> thought and consideration, and we have no intent of reopening
> questions like "Is Visual Editor the top product priority".
>
> I look forward to hearing your thoughts & discussing this further in
> coming weeks.
>
> All best,
> Erik
>
> --
> Erik Mller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
>


_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


sgardner at wikimedia

Nov 7, 2012, 12:05 PM

Post #5 of 17 (726 views)
Permalink
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure [In reply to]

On 7 November 2012 11:47, Terry Chay <tchay [at] wikimedia> wrote:
> Take care,
>
> terry

Terry this is great, thank you for writing it. I was on a two-hour
call glancing at this thread, knowing Erik's travelling, and wondering
if I should reply in his stead. Glad you did it :-)

Thanks,
Sue

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


erik at wikimedia

Nov 7, 2012, 2:33 PM

Post #6 of 17 (725 views)
Permalink
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure [In reply to]

On Wed, Nov 7, 2012 at 10:00 AM, Quim Gil <quimgil [at] gmail> wrote:

> Whatever the result, I hope we end up with teams where software developers,
> sysadmins, product managers, designers etc are well mixed in focused teams
> going after clear common goals.

Absolutely. Teams are assembled cross-functionally to ensure that all
required skills are present in a team. This will not change in the new
structure. Indeed there are ways in which we need to do better (e.g.
involving ops/architects earlier in the development process on major
feature initiatives). The departments represent functional groupings,
while teams are inherently cross-functional, which is a pretty
conventional structural approach.

I've asked Howie to weigh in a bit on the definition and role of
Product Managers, User Experience Designers, Visual Designers,
Interaction Designers, Research Analysts, Community Liaisons and other
functions grouped in Product. I'll write a bit more in this thread in
a few days as well (about to head to Bangalore for the hackathon
there).

All best,
Erik

--
Erik Mller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


tbayer at wikimedia

Nov 7, 2012, 2:38 PM

Post #7 of 17 (729 views)
Permalink
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure [In reply to]

On Wed, Nov 7, 2012 at 2:16 PM, Platonides <Platonides [at] gmail> wrote:
> On 07/11/12 22:21, Federico Leva (Nemo) wrote:
>> Terry Chay, 07/11/2012 21:04:
>>>> You aren't the only one. It turns out we use a lot of industry
>>>> terminology, without realizing that we are poorly communicating what
>>>> that means to most people. [...]
>>>> First of all, this will help greatly to the others (you already
>>>> read it): <http://wikimediafoundation.org/wiki/Staff_and_contractors>.
>>
>> Thanks for your explanation but personally I'm more confused than before
>> about the difference between Engineering and Product, also because the
>> terminology didn't appear internally consistent. :-)
>
> I feel like you, Nemo. I am glad by Terry explanation, but as I went on
> reading it, the less I felt I understood it. It would benefit from a
> more layman explanation. Maybe it's just complex to everybody.
>
>
>> So, to keep it simple, that page has:
>>
>> 2 Engineering and Product Development
>> 2.1 Platform
>> 2.2 Features
>> 2.3 Technical Operations
>> 2.4 Mobile and Special Projects
>> 2.5 Language
>> 2.6 Product
>>
>> and as first approximation "Product" would be something like 2.2+2.6 and
>> "Engineering" something like 2.1+2.3, with 2.4 and 2.5 aside?
>
> I thought that 2.4 (Mobile) would also be Product.
>
>
>
>>>> [...] On the "Engineering" side, there exists an amalgam of
>>>> specific focused groups with their own directors. The focused groups
>>>> are: Language (formerly "i18n and Experimentation",
>>>> internationalization/localization/globalization is a cross-cutting
>>>> concern), and Mobile (formerly, "Mobile and Special Projects: the
>>>> mobile web, the mobile app, also including Wikipedia Zero). The
>>>> "area" focused ones are: Operations (keeping the lights on), Platform
>>>> (keeping the code working) and Features (ostensibly new features). [...]
>>
>> What you call the Engineering side here, at a first glance, could seem
>> product development, and in fact those two "focused groups" currently
>> have some members which are under 2.6 (Product). Surely the same happens
>> for the other areas you mentioned.
>
>
> You can see several teams in that page, with members from multiple
> "sections". Which leads to the (naive?) question on what's the purpose
> of being splitted in those sections if then the work is done in teams
> with a completely different organization.
>
>
> After staring for a while to [[Staff and contractors]] and trying to
> match people with its work, my only conclusion is that I don't know what
> most employees do.
>
It often (not always) helps to click through to the employee's user
page and read the "My work" section there. Earlier this year, Gayle
harassed us all a lot to put something informative there ;)

--
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


steven.walling at gmail

Nov 7, 2012, 2:46 PM

Post #8 of 17 (730 views)
Permalink
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure [In reply to]

On Wed, Nov 7, 2012 at 2:16 PM, Platonides <Platonides [at] gmail> wrote:

> > Thanks for your explanation but personally I'm more confused than before
> > about the difference between Engineering and Product, also because the
> > terminology didn't appear internally consistent. :-)
>
> I feel like you, Nemo. I am glad by Terry explanation, but as I went on
> reading it, the less I felt I understood it. It would benefit from a
> more layman explanation. Maybe it's just complex to everybody.


Simplest possible explanation of what Erik is proposing: we need to split a
large department in to two, and add more managers. It's too big ad too
critical for one person to manage.

In three steps...

1. Right now there is one department, Engineering & Product Development.
It includes engineers, designers, product managers, community liasons, data
analysts, and more. It's the biggest department at the Wikimedia
Foundation.
2. In 6-8 months there will be two departments, Engineering and Product
Development. Each will have their own leaders that report to Sue, instead
of everyone reporting to Erik. Engineering will contain software engineers
and their managers, for the most part. Product Development will contain
designers, product managers, and data analysts, for the most part.
3. There will also probably be new Director-level positions under the
new departments, such as to manage the design team.

That glosses over the entirety of the reasons for proposing this and the
benefits, obviously. Howie's explanation of what each of these roles are
will help define why product development is distinct from engineering, I'm
sure.

Steven
_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


erik at wikimedia

Nov 7, 2012, 2:49 PM

Post #9 of 17 (728 views)
Permalink
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure [In reply to]

On Wed, Nov 7, 2012 at 2:16 PM, Platonides <Platonides [at] gmail> wrote:

> You can see several teams in that page, with members from multiple
> "sections". Which leads to the (naive?) question on what's the purpose
> of being splitted in those sections if then the work is done in teams
> with a completely different organization.

The purpose of functional groupings is to ensure that there is
coordination and communication among people who share a function (e.g.
all designers), and that they have management support, ideally from
someone who understands their function and purpose in the
organization, and is able to help them grow in their career and as an
individual contributor. It creates escalation points in case of
conflicts, and can help to remove blockers.

The purpose of team groupings is to ensure that a team is assembled
cross-functionally, from all the required skills, and fully focused on
delivering its objectives.

The two organizational models are complementary; the singular focus on
one or the other tends to lead to silos. Achieving a healthy balance
between intra-functional team development and growth and
cross-functional delivery is one of the key challenges of management.

Erik

--
Erik Mller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


hfung at wikimedia

Nov 7, 2012, 8:53 PM

Post #10 of 17 (730 views)
Permalink
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure [In reply to]

Picking up this thread as Erik asked me to explain the different functions
that fall under "Product". To do that, it's worth describing in a bit more
detail how our project teams work.

This may be a bit reductive (apologies in advance), but there are a basic
set of things that need to happen when building a product. These things
happen regardless of what the product actually is (e.g., t-shirts count):

1. Decide what to build
2. Design it
3. Build it
4. Measure how it's used (if you want to improve the product)

Roughly speaking, that's how we organize our teams when it comes to
building features. Product Managers decide what features to build,
Designers design the feature, Developers build the feature, and Analysts
measure how the features perform. (features = things on our websites or
mobile that readers or editors would use).

Let's take PageCuration as an example of a feature that WMF developed. In
this case, the feature development team consisted of a Product Manager,
Designers, Developers, and Analysts, all working together. Here's how the
various roles worked:

1. Product Manager [1]: Represents the user's point of view. Works with
the rest of the team to identify and solve a user problem. For example, we
knew that the backlog for Special:NewPages on the English Wikipedia was
consistently too large and that existing page patrollers felt overworked.
To solve the problem, we needed to make page patrolling more efficient
[2]. Product Manager worked with the rest of the team to develop potential
solutions to this problem. The outcome of this was the decision to build
two separate features for the end user (i.e., page patrollers):
Special:NewPagesFeed [3] (redesign of Special:NewPages) and the Curation
Toolbar.

The Product Manager worked with the rest of the WMF and volunteers in the
community to identify specific features by asking question such as "If we
were to redesign Special:NewPages, what kind of information would page
patrollers want to see that would make their jobs more efficient. Out of
this inquiry came ideas like surfacing the # of categories, # of citations,
whether an article is an orphan, a snippet of the content, etc. as these
pieces of information would help the patroller determine which articles
warranted attention. Fabrice Florin was the Product Manager.

We also have a Community Liaison (Oliver Keyes) who is responsible for
reaching out to the editor community to make sure the feature we're
building actually meets the needs of our editors. The Community Liaison
creates the space where community members can give input into the feature
by holding IRC chats, on-wiki discussions, reaching out to editors, etc.

2. Designer: The designer then takes this input and designs the user
interface for Special:NewPagesFeed. Part of this is Interaction Design [4]
e.g., how are the elements of the page laid out so that page patrollers can
easily parse the information? How does a page patroller actually
accomplish the task of selecting an article to review (e.g., should there
be a "Review" button associated with each article, or should the article
link be sufficient?). Does this action open up a separate tab? How should
filtering of this list work? Etc.

There's also Visual Design: How do we use color to help identify the
different states of an article? How can icons be used to reduce the
cognitive load associated with parsing information? How can we create a
look & feel that's visually engaging?

Brandon Harris and Vibha Bamba were the designers for Page Curation.

3. Developer: The developers then take these functional and design ideas
and code the feature. On this project, the developers were Ryan Kaldari
and Benny Situ.

4. Analyst: The data analyst works with the developers to determine what
types of stats would give the team a handle on whether/how the feature is
being used. For example, here is the dashboard that Dario Taraborelli:
http://toolserver.org/~dartar/pc/

These roles aren't rigidly defined. For example, ideas for features can
come from anywhere, not just the Product Manager. In my view, a
well-functioning team is one where everyone is engaged in coming up with
ideas. But there should be someone responsible for ensuring that the
various ideas come together into a coherent whole, ones that addresses the
problem at hand. That responsibility lies with the Product Manager.

Also, Product Managers and Designers don't spec out stuff which they then
hand over to developers to build. Teams work collaboratively to come up
with solutions.

That's how our project teams are structured. When it comes to the proposed
organizational structure, "Product" consists of Product Managers,
Designers, and Analysts (1, 2 and 4) and "Engineering" consists engineers
across the different areas Terry describes. One way to view it is that
"Product" involves everything outside of writing code for a feature and
developers in "Engineering" write the code. It's oversimplification (e.g.,
analysts write code for analytics work, designers may prototype), but I
think it's directionally useful.

The individuals in Product and Engineering are then matrixed into project
teams like the one described above for Page Curation so project team
structure != organizational structure.

Howie

[1] http://www.quora.com/How-can-I-learn-to-be-a-good-Product-Manager
[2] This is a slight oversimplification
[3] https://en.wikipedia.org/wiki/Special:NewPagesFeed
[4] http://en.wikipedia.org/wiki/Interaction_design


On Wed, Nov 7, 2012 at 2:49 PM, Erik Moeller <erik [at] wikimedia> wrote:

> On Wed, Nov 7, 2012 at 2:16 PM, Platonides <Platonides [at] gmail> wrote:
>
> > You can see several teams in that page, with members from multiple
> > "sections". Which leads to the (naive?) question on what's the purpose
> > of being splitted in those sections if then the work is done in teams
> > with a completely different organization.
>
> The purpose of functional groupings is to ensure that there is
> coordination and communication among people who share a function (e.g.
> all designers), and that they have management support, ideally from
> someone who understands their function and purpose in the
> organization, and is able to help them grow in their career and as an
> individual contributor. It creates escalation points in case of
> conflicts, and can help to remove blockers.
>
> The purpose of team groupings is to ensure that a team is assembled
> cross-functionally, from all the required skills, and fully focused on
> delivering its objectives.
>
> The two organizational models are complementary; the singular focus on
> one or the other tends to lead to silos. Achieving a healthy balance
> between intra-functional team development and growth and
> cross-functional delivery is one of the key challenges of management.
>
> Erik
>
> --
> Erik Mller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l [at] lists
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
>
_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


sgardner at wikimedia

Nov 7, 2012, 10:03 PM

Post #11 of 17 (727 views)
Permalink
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure [In reply to]

Hey folks,

I think all the conversation about this is really helpful, and it's
been particularly useful thus far to hear from community members about
what's confusing about the current and proposed structures. ("Not
being confusing" isn't the primary motivation for a restructure, but
it's obviously worth consideration.)

I do want to underline though, from Erik's original note, this: "To
avoid fear and anxiety, and to make sure the plan makes sense, I
want to start an open conversation now. If you think any of the below
is a terrible idea, or have suggestions on how to improve the plan,
Id love to hear from you," and "I look forward to hearing your
thoughts & discussing this further in coming weeks."

I kind of have the sense that people are considering this a done deal.
I understand why people might assume that -- in an ordinary
organization, a note like Erik's doesn't go out until things are
pretty much locked down. But it's important that you realize that's
not what's happening here: your input is wanted. Particularly for
staff who'd be directly affected by these changes --- this is your
window to shape what happens. If you think there are likely to be
downstream effects of these proposed changes that are worth
considering, or additional improvements that could be folded into
this, or an aspect that warrants being revisited: this is your window.
You can talk with Erik (by e-mail because he's travelling), me, Gayle,
or whoever else seems relevant. That was the whole point of Erik's
note :-)

So to be super-clear: None of this is a done deal at this moment. Lots
of conversations are happening in various places, and it's all good.
That's why Erik made the pre-announcement --- to create a window for
discussion & iteration and further thinking :-)

Thanks,
Sue



--
Sue Gardner
Executive Director
Wikimedia Foundation

415 839 6885 office
415 816 9967 cell

Imagine a world in which every single human being can freely share in
the sum of all knowledge. Help us make it a reality!

https://donate.wikimedia.org/

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


nemowiki at gmail

Nov 8, 2012, 1:28 AM

Post #12 of 17 (729 views)
Permalink
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure [In reply to]

Sue Gardner, 08/11/2012 07:03:
> I kind of have the sense that people are considering this a done
deal. [...]
>
> So to be super-clear: None of this is a done deal at this moment. Lots
> of conversations are happening in various places, and it's all good.
> That's why Erik made the pre-announcement --- to create a window for
> discussion & iteration and further thinking :-)

Thank you for clarifying this. Another thing I found confusing in
Terry's email is that he called it a "decision" (another terminology
inconsistency problem? ;-) ).

Howie Fung, 08/11/2012 05:53:
> [...]
> That's how our project teams are structured. When it comes to the proposed
> organizational structure, "Product" consists of Product Managers,
> Designers, and Analysts (1, 2 and 4) and "Engineering" consists engineers
> across the different areas Terry describes. One way to view it is that
> "Product" involves everything outside of writing code for a feature and
> developers in "Engineering" write the code. It's oversimplification (e.g.,
> analysts write code for analytics work, designers may prototype), but I
> think it's directionally useful.
>
> The individuals in Product and Engineering are then matrixed into project
> teams like the one described above for Page Curation so project team
> structure != organizational structure.

Thank you for this short explanation and its long (useful) premise.
It would seem that the tentative answer to my question, pending more
insight from Erik when he has time, is "more scattered rather than less".

A thing your answer doesn't cover is that not only project team
structure != organizational structure (with Erik's words, functional
groupings != team groupings), but also (it seems) "project team
structure != team structure", i.e. not all teams are the same.
By browsing the wonderful
https://www.mediawiki.org/wiki/Category:WMF_Projects , one can see that
each project has different ad-hoc teams (specified in the infobox), but
some teams are more consistent/frequent than others, with the tightest
groupings being the permanent teams mentioned also on the staff page,
who mostly move together from one project to another. On the opposite
side of the spectrum we have "electrons" who are not in any team (and
don't have any "day-to-day management"?) but move across many projects
("serving" many teams).
It would seem to me that you can't treat everything in the same way?

Steven Walling, 07/11/2012 23:46:
> On Wed, Nov 7, 2012 at 2:16 PM, Platonides <Platonides [at] gmail> wrote:
>
>>> Thanks for your explanation but personally I'm more confused than
before
>>> about the difference between Engineering and Product, also because the
>>> terminology didn't appear internally consistent. :-)
>>
>> I feel like you, Nemo. I am glad by Terry explanation, but as I went on
>> reading it, the less I felt I understood it. It would benefit from a
>> more layman explanation. Maybe it's just complex to everybody.
>
>
> Simplest possible explanation of what Erik is proposing: we need to
split a
> large department in to two, and add more managers. It's too big ad too
> critical for one person to manage.

This is very clear and it's not hard to see that it's needed, but it
doesn't actually explain the need for a split.
If, for instance, one "only" needs to make more equal functional
groupings so that "each C-level has to sign an equal amount of holiday
permissions"[1], instead of inventing boundaries between "Engineering"
and "Product" or other names for almost-fake separations, one could as
well just keep the two together, call it an "area" or "super-department"
with its VP[2] and then Chief 1 and Chief 2 under it... or whatever.
But the further explanations will help us understand what are the aims
and how it's expected to achieve them.

Nemo

[1] Simplifying at most; fake example with probably wrong terminology even.
[2] Speaking of terminology bikeshedding, I never understood that "VP of
Engineering and Product Development" were actually /two/ VP roles.
Previous discussion:
<http://thread.gmane.org/gmane.org.wikimedia.foundation/59115/focus=59147>

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


quimgil at gmail

Nov 9, 2012, 11:05 AM

Post #13 of 17 (711 views)
Permalink
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure [In reply to]

Thank you for the explanations.


On 11/07/2012 11:47 AM, Terry Chay wrote:
> It turns out we use a lot of industry
> terminology, without realizing that we are poorly communicating what
> that means to most people.

Actually I'm familiar with industry terminology, and also with the wrong
assumptions and prejudices it carries many times. I know *you* get it
right but a basic goal of any reorg is that *everybody* gets it right
now and in the future.

While it makes total sense to organize Product Management, Design and
Analytics under "Product Development", it feels old school and odd to
leave out the software engineers fully dedicated to product development.
It enforces the old vision that software development is something that
comes apart and after the product definition. But being Erik (a software
developer himself) the proposed VP in that area I don't need to insist
in this point.

The current proposal of having software developers working on products
(Language, Mobile, Platform...) together with Operations (sysadmins, not
directly involved in product development) feels just as old school and
odd. The common denominator seems to be "teams that know to code", "the
command line dudes", etc. I might be mistaken, but it feels as
consistent as a VP of Presentations overseeing Marketing, Analytics,
Design and other teams with high communications skills and able to
produce great slides. :)

And whoever leads the proposed "Engineering" team still would need to
deal at a high level with two very different agendas: those from teams
actually developing software features and those from the operations
teams, the latter probably still complaining that they don't get as much
attention at the top level.

So...

If the goals are "narrowing focus" + "scale the dept, and take seriously
our identity as a tech org (as stated by Sue)" (Erik says) then why not
flattening more all this tech structure?

Something like

- Product Management.
- Design.
- Software development.
-- Features
-- MediaWiki.
-- Language.
-- Mobile.
- Operations.
- Analytics.

This would mean 5 tech managers (already leading their teams) where now
you have Erik alone, 4 of them focused on product development +
Operations. Erik himself could act as EVP overseeing the product
development activities, since this is the narrowed focus now. He should
focus on vision, strategy and glue between the tech teams and with the
rest of WMF. The reporting and leadership of each team would be done by
those 5 managers, now interacting with Sue & "non-tech managers" more often.

Doesn't this sound like a more flat and scalable org, with a clearer
tech org identity?

PS: yes, it's easy for an outsider to shuffle proposals without much
background and knowledge of the day to day. :) But since you asked for
feedback... I hope it's useful, regardless of what you decide at the
end. Thank you for listening!

--
Quim

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


sgardner at wikimedia

Nov 10, 2012, 10:22 AM

Post #14 of 17 (709 views)
Permalink
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure [In reply to]

Quim, thanks for writing that. I am happy about the conversations that are
happening about this, and I'm finding people's thoughts and input useful.
There have been (and are being) lots of face-to-face conversations as well
as the ones on the lists and in other venues: it's all good.

There is of course no perfect ideal solution --it's a balancing-act among
multiple considerations-- and there is zero likelihood that we'll come up
with a result that is understandable for everyone, and fits their ideal
version of how the org should work. That's okay: we don't need to be
perfect (and there is no "perfect") --- we just need to be always
evolving-towards-better, as the org grows and changes. I'm glad Erik kicked
this off with a request for input: the input is useful :-)

Thanks,
Sue
On Nov 9, 2012 11:05 AM, "Quim Gil" <quimgil [at] gmail> wrote:

> Thank you for the explanations.
>
>
> On 11/07/2012 11:47 AM, Terry Chay wrote:
>
>> It turns out we use a lot of industry
>> terminology, without realizing that we are poorly communicating what
>> that means to most people.
>>
>
> Actually I'm familiar with industry terminology, and also with the wrong
> assumptions and prejudices it carries many times. I know *you* get it right
> but a basic goal of any reorg is that *everybody* gets it right now and in
> the future.
>
> While it makes total sense to organize Product Management, Design and
> Analytics under "Product Development", it feels old school and odd to leave
> out the software engineers fully dedicated to product development. It
> enforces the old vision that software development is something that comes
> apart and after the product definition. But being Erik (a software
> developer himself) the proposed VP in that area I don't need to insist in
> this point.
>
> The current proposal of having software developers working on products
> (Language, Mobile, Platform...) together with Operations (sysadmins, not
> directly involved in product development) feels just as old school and odd.
> The common denominator seems to be "teams that know to code", "the command
> line dudes", etc. I might be mistaken, but it feels as consistent as a VP
> of Presentations overseeing Marketing, Analytics, Design and other teams
> with high communications skills and able to produce great slides. :)
>
> And whoever leads the proposed "Engineering" team still would need to deal
> at a high level with two very different agendas: those from teams actually
> developing software features and those from the operations teams, the
> latter probably still complaining that they don't get as much attention at
> the top level.
>
> So...
>
> If the goals are "narrowing focus" + "scale the dept, and take seriously
> our identity as a tech org (as stated by Sue)" (Erik says) then why not
> flattening more all this tech structure?
>
> Something like
>
> - Product Management.
> - Design.
> - Software development.
> -- Features
> -- MediaWiki.
> -- Language.
> -- Mobile.
> - Operations.
> - Analytics.
>
> This would mean 5 tech managers (already leading their teams) where now
> you have Erik alone, 4 of them focused on product development + Operations.
> Erik himself could act as EVP overseeing the product development
> activities, since this is the narrowed focus now. He should focus on
> vision, strategy and glue between the tech teams and with the rest of WMF.
> The reporting and leadership of each team would be done by those 5
> managers, now interacting with Sue & "non-tech managers" more often.
>
> Doesn't this sound like a more flat and scalable org, with a clearer tech
> org identity?
>
> PS: yes, it's easy for an outsider to shuffle proposals without much
> background and knowledge of the day to day. :) But since you asked for
> feedback... I hope it's useful, regardless of what you decide at the end.
> Thank you for listening!
>
> --
> Quim
>
> ______________________________**_________________
> Wikimedia-l mailing list
> Wikimedia-l [at] lists**org <Wikimedia-l [at] lists>
> Unsubscribe: https://lists.wikimedia.org/**mailman/listinfo/wikimedia-l<https://lists.wikimedia.org/mailman/listinfo/wikimedia-l>
>
_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


erik at wikimedia

Nov 19, 2012, 7:54 PM

Post #15 of 17 (709 views)
Permalink
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure [In reply to]

On Sat, Nov 10, 2012 at 12:35 AM, Quim Gil <quimgil [at] gmail> wrote:

> While it makes total sense to organize Product Management, Design and
> Analytics under "Product Development", it feels old school and odd to leave
> out the software engineers fully dedicated to product development. It
> enforces the old vision that software development is something that comes
> apart and after the product definition.

Hi Quim,

your post touches on quite a few different points, so let me try to
articulate my views on what I see as some key themes and give my take
on those, and I hope others jump in as well.

1) Do Product Managers hand down requirements from up high and
software development comes after product definition?

Fortunately, generally not. We were much more guilty of this in the
days before WMF had Product Managers. The 2009 usability initiative
(AKA Vector) had functional requirements defined in a grant proposal
before developers had been hired, and the development process was very
waterfall-style, with limited (perceived and therefore actual)
flexibility to change course on the part of the team. We started
seriously ramping up Product in 2011-12, and also gave some teams
training in agile methodology to move away from either ad hoc or
waterfall-style development.

Teams that have dedicated PMs typically pull from multiple functions
(design, development, product management) working together at
peer-level and negotiating requirements on a day-to-day basis. PMs
sometimes play more of a servant leadership role, sometimes are more
directive, depending on what's required in a given context.

However, there are at least two major issues with this model:

- So far, some teams have benefited significantly more than others
from access to scarce staffing in areas like UI/UX. Top feature
priorities like Visual Editor and Editor Engagement get lots of UI/UX
love, while behind-the-scenes changes which can also have major
user-facing implications (e.g. Scribunto) have received relatively
little. More bridges have been built recently, thanks to the intrepid
efforts of notorious bridgebuilders like James Forrester and Steven
Walling, but there's still work to do.

This (i.e., developer and platform improvements not receiving UX love)
is a common problem in the industry and explains why Gerrit's UI is a
clusterf^Wbit challenging while other more user-facing Google products
have good-to-great UIs. We can't resource everything perfectly, but
I'd like to ramp up our UI/UX staffing a bit in part to mitigate these
types of resourcing issues.

- We've not pulled in ops, senior engineers and site architects
sufficiently in feature teams throughout a product's lifecycle, which
has sometimes led to miscommunications and frustrations. (A single
email or RT ticket isn't sufficient to establish a shared
understanding of what needs to happen.)

This does _not_ mean developers getting grouped together with ops
people but being walled away from product. A Product Manager needs to
be just as aware of a major site architectural issue related to a
feature as the developers working on the same team, even if the PM's
understanding is more abstract.

2) What's the common denominator for a functional separation, and does
it mean people start thinking in silos?

I've written a bit more about the difference between functional and
team-level organization here:

http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064298.html

Even so, I acknowledge that there's a risk of the Product Department
seeing itself as solely responsible for the long term product roadmap,
and insufficiently creating venues either for other developers or for
the community at large to influence that thinking. After all, who
decides that a new "Editor Engagement" team is created, as opposed to
- say - a "Multimedia" or "Content Curation" or "API" team?

If we go forward with the proposed approach, much of the
responsibility for creating better venues for collaborative thinking
about product priorities will fall onto me and my team, and I would
certainly appreciate the freed up time to help organize such
discussions across the organization and the movement. But there's also
a role for leadership here that, I think, needs to be explicitly
acknowledged: for example, it was ultimately the Board's decision to
make editor engagement the organization's top priority, upon the
recommendation of the Executive Director. That's why I think it's
crucial that more brains influence her thinking directly.

3) Why not have an even flatter structure?

My prediction with a structure like the one you propose would be the following:

If you increase the number of direct engineering-related reports to
Sue from 1 to 5, her ability to meet and seriously interact with any
one of them will drop to close to zero, with no time for goal-setting
conversations, career pathing, or serious conflict resolution. An
"EVP" role, held by me or someone else, focused on "Product" would
quickly gravitate to taking on most of those responsibilities, leading
to the common frustrations that you have when you have a "boss" and a
boss (feelings of inequity and unfairly limited access to the ED). IMO
you'd essentially end up with a structure similar to the current one,
except for a higher drama factor.

This prediction is based in part on some broader observations about
the role of hierarchy in WMF.

Whether you like or dislike hierarchy (I'd personally prefer a far
less hierarchical organization), we can't deny the current reality or
the forces that have created it. The same forces that create a desire
for clearly laid out plans (an Annual Plan with targets, goals,
quarterly milestones, etc.), are also the ones that tend to reinforce
traditional hierarchical thinking. That begins at the Board-level and
continues through new organs like the FDC, through relationships with
funders, etc.

As noted above, the organization's top priorities today have
ultimately been decided by the Board on recommendations from the ED
through instruments such as the annual planning process, individual
Board resolutions, etc. That's a pretty traditional, hierarchical way
of setting the agenda for an organization like Wikimedia. Upsides or
downsides of that approach notwithstanding, my main point here is what
it means for the rest of the organization.

If you have a pretty high expectation to be a "plan and execute"
organization with ever-improving standards of accountability, and that
expectation comes from the top, a structure that exhibits a high
degree of conflict or tension with those objectives will tend to
shift, by formal or informal means, to accommodate that objective (or,
which is worse, you'll end up with a massive disconnect between
leadership and the rest of the org).

I do think, though, that regardless of whether we do the split as
originally described, and regardless of whether we do it sooner or
later, we need to bring more senior folks into the conversation w/ Sue
and her direct reports. As long as we embrace a fairly conventional
hierarchy, we should definitely strive to at least make it as porous
as possible. We've done a bit more recently (such as a leadership
retreat pulling together at least all the managers), but there's a lot
more to do.

Erik
--
Erik Mller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


qgil at wikimedia

Nov 21, 2012, 6:02 PM

Post #16 of 17 (695 views)
Permalink
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure [In reply to]

Thanks Erik for the extensive response.

Ultimately what counts is ongoing progress. If the model proposed is an
improvement from the current, solving specific problems we currently
have, then fine and I'm all or it.

I'm still stuck in one point:

On 11/19/2012 07:54 PM, Erik Moeller wrote:
> 3) Why not have an even flatter structure?
>
> My prediction with a structure like the one you propose would be the following:
>
> If you increase the number of direct engineering-related reports to
> Sue from 1 to 5, her ability to meet and seriously interact with any
> one of them will drop to close to zero, with no time for goal-setting
> conversations, career pathing, or serious conflict resolution.

One could ask why so many things need to be reported to or pass through
a single person? This is the factor defining the angle of verticality of
an organization.

Why not having more decentralized reporting (broadcasting),
goal-setting, career path, or serious conflict resolution?

Why not betting on a more brave contemporary model being a non-profit
foundation, with hundred-something employees, an open source culture, an
Internet culture, a wiki culture, a remote work culture, a contributors
culture, an online community culture, a San Francisco Bay tech startup
inspiration?

I understand what you are explaining about the board being the first
body defining this kind of game. As for today the board is an entity too
unilateral and abstract for me, but I'm willing to help bringing this
type of message to them if these opinions are shared by others.

BUT

Well, at least your proposal doesn't go against this scenario. Perhaps
is one step in that direction. Good enough here and now, I guess. Thank
you for trying! And for opening this discussion. Just please consider
further steps flattening and decentralizing the WMF.

There is a blog post & video circulating these days, about how GitHub
Inc is organized as a company. They also manage a version control system
promoting decentralized collaboration, plus other tools supporting this
core goal and the big community around it. They are also
hundred-something. They have also offices in San Francisco. They are
also a young organization growing fast. Etc.

The video is interesting and entertaining. The slides are simple and
fun. I'm not a person for watching 40min YouTube videos, even less about
HR & business management topics - but this one was very interesting to
watch. Even if only as a documentary of how certain company running
certain product I like happens to work:

Your team should work like an open source project
http://tomayko.com/writings/adopt-an-open-source-process-constraints
http://youtu.be/mrONxcyQo4E

--
Quim

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


erik at wikimedia

Nov 21, 2012, 8:49 PM

Post #17 of 17 (698 views)
Permalink
Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure [In reply to]

On Wed, Nov 21, 2012 at 6:02 PM, Quim Gil <qgil [at] wikimedia> wrote:
> There is a blog post & video circulating these days, about how GitHub Inc is
> organized as a company. They also manage a version control system promoting
> decentralized collaboration, plus other tools supporting this core goal and
> the big community around it. They are also hundred-something. They have also
> offices in San Francisco. They are also a young organization growing fast.
> Etc.

Yeah, I'm familiar with it. There's also a similarly interesting
description of the organizational culture at Valve (makers of
Half-Life, Portal, etc.) in the form of their employee handbook:

http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf

I like a lot about the picture these presentations and documents
paint, and I think there's a ton we can learn from them. There are of
course also crucial differences between Wikimedia and a Git hosting
company or a game developer, and less obvious ways that power is
exercised in both organizations (e.g. the role of the founders).

> Well, at least your proposal doesn't go against this scenario. Perhaps is one step in that direction.

[.Fair warning, below is really starting to drift away from being
on-topic for wikitech-l and going into general OD stuff.]

I believe so. I do think we should have bigger conversations about
what kind of organization we want to be, and what tradeoffs we'd need
to accept if we wanted to move away from what's stilll in many ways a
fairly hierarchical model. Like I said, I don't think you can make
major structural changes in isolation, or you'll just end up with
mismatched expectations and broken hearts. ;-)

I do think flat structures are pretty enticing, though. I encourage
you (and anyone) to look a bit more into the way things currently work
if you want to help be part of continued evolutionary change. I've had
conversations with Sue about this and she's pretty open to supporting
well-justified structural changes (hence this discussion). The Board,
too, is generally open-minded and responsive.

An example where I think change is badly needed is the Annual Planning
process. There are few aspects of WMF that follow as conventional a
hierarchical model as this one. You see the output: a 71 page document
[1] describing the organization's planned financials, key activities
and targets, etc. To get to that point, we went through a multi-month
process driven primarily by managers, sending drafts and submissions
up and down and up the organizational ladder, with final review by Sue
and ultimate approval by the Board. This was followed by the Narrowing
Focus resolution, the Narrowing Focus process (with again lots of
leadership involvement), the Narrowing Focus document and its
approval, the Wikimedia Foundation FDC submission and its approval,
etc.

That's a lot of time spent on meta-level work. I'm not arguing it's
time and effort wasted, but I do think there's a lot of room for
streamlining and consolidating processes. I also think it's predicated
on the assumption that creating a more comprehensive plan will lead to
a better outcome, and I would challenge that belief -- there's a
threshold at which point the opposite is true, and I think in a lot of
our work that threshold is very low because the unknowns are pretty
large and new ideas and opportunities may emerge all the time.

Moreover, to get back to the point you were making, I think this is
the kind of thing that creates a lot of dependency on conventional
management approaches -- time that could be spent, by those same
people, on doing the actual work the plan talks about, while creating
a less rigid harness for the organization as a whole, in turn allowing
for structures to be simplified and enabling greater autonomy across
the board.

So, I'm not arguing against deeper structural changes -- just for
change that's harmoniously managed in concert with the various other
factors at play.

Cheers,
Erik

[1] https://upload.wikimedia.org/wikipedia/foundation/4/4f/2012-13_Wikimedia_Foundation_Plan_FINAL_FOR_WEBSITE.pdf

--
Erik Mller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

_______________________________________________
Wikimedia-l mailing list
Wikimedia-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l

Wikipedia foundation RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.