Re: [Wikimedia-l] Moving the technical infrastructure out of the US

2020-09-30 Thread Erik Moeller
On Tue, Sep 29, 2020 at 3:36 PM Joseph Seddon  wrote:

> I believe options are going to be explored for sustainability but right now
> legally speaking the US is the best jurisdiction for hosting us now


> and the foreseeable future.

I can't foresee the future. But Trump's first term in office is very
troubling. Relentless attacks on journalists, escalation of political
violence, attempts to undermine Section 230 protections, attempts to
remove apps from app stores by Executive Order, etc.  -- checked by a
judiciary that's increasingly aligned with the Trump agenda. That's
the United States today. From this we can extrapolate plausible
scenarios in which the question where to locate Wikimedia's core
assets could become the single most urgent strategic question the
movement faces.

I hope that some preliminary contingency plans exist or are being
developed, and I'm sure that the movement-wide debate will widen if
the US continues its downward slide into authoritarianism.


Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] New essay on the ambiguity of NC licenses

2020-08-13 Thread Erik Moeller
On Tue, Aug 11, 2020 at 2:51 PM Samuel Klein  wrote:
> There should be no 'collaborative and transformative work' done on this
> archive

Bulk uploads often entail collaboration or transformation as the
uploads are organized, and as format issues and other considerations
are worked through. If you want to enable uploads in a wiki context, I
don't think you'll be able to (or want to!) get around that. :) That's
part of the reason why I think the upload stage should be reserved for
the point when licensing issues have in fact been resolved.

> Erik, to your point — yes, this should also include old books that are in
> the process of relicensing, if those books have been uploaded to us by or
> on behalf of a license holder, and we are confirming that and working
> through related steps.

Is your assumption that the set of works that would be so archived is
closer to being usable in Wikimedia projects (i.e. freely licensed)
than any other set of works? If so, I still don't see how this is
true. The decision to apply a license like NC is often a very
intentional one, difficult to reverse, as the many discussions about
this license have shown. In contrast, the decision to just use
conventional copyright is often not a decision at all. In many cases,
a copyrighted work may be "free for the asking".

> It helps our work to have a persistent public place (not randomly deleted
> from time to time!) to discuss determining their license status, getting
> formal and informal license clearance, discussions with the contributors to
> refine their understanding of options, debates among ourselves about
> whether a license grant was sufficient and how to obtain more clarity, 

I agree with that! I think it could be done e.g. in a WikiBase
instance which focuses on tracking URLs of valuable educational
content rather than files. This would have some advantages:

- it is inclusive of material under all licensing terms, in any repository
- it is inclusive of material that is not trivially downloadable or
that is in formats that require conversion or transformation
- it can hold URLs to collections alongside URLs to single files

It could be scoped to track material that is associated with plausible
efforts to liberate it for use in Wikimedia, e.g., organized under

And what of archiving? As I said before, a partner like the Internet
Archive would IMO be well-suited to help archive URLs that permit it,
without requiring the manual labor of managing copies in some kind of

Fundamentally I just don't buy the apparent premise that amassing NC
type content, or content under your "any legal way but not yet free"
formulation, actually helps in the goal of content liberation. Is that
stuff worth archiving? Sure, but Wikimedia is not the IA.

I do appreciate the discussion, and the WikiNotYetFree proposal (even
if I disagree with its premise for the same reasons).  If there's
interest in the idea formulated above, of a wiki that truly is a
clearinghouse and not an archive of nonfree content, I would be happy
to try to help articulate it further.


Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] New essay on the ambiguity of NC licenses

2020-08-07 Thread Erik Moeller
On Sun, Aug 2, 2020 at 3:52 PM Samuel Klein  wrote:

> I don't think we should mix NC with free-knowledge licenses .
> I do absolutely think we should maintain an archive, visible to the public
> with at most a simple hoop to jump through, of material that is offered to
> us in any legal way but not yet free.

Such an archive would _unavoidably_ "mix NC with free-knowledge
licenses" -- because all collaborative and transformative work
happening in the archive itself would be released under free knowledge
licenses. Worse, any meaningful transformations of the archived works
would result in derivative works that remain nonfree, directly
enlisting volunteers in the creation of nonfree knowledge.

In any event, why create an archive for works under borderline terms,
while ignoring more restricted works that could be plausibly released
under a free license tomorrow? Works that are nonfree for simple
economic reasons (e.g., some old but useful textbook) may often be
easier to "set free" than those which are nonfree for reasons of
longstanding policy (e.g, the WHO example). Why amass the latter and
ignore the former? I don't see how this would strengthen Wikimedia's
free knowledge commitment, but I can easily see how it could weaken it
considerably and very quickly, whether or not that's the intent.

To be clear, I think creating free summaries and descriptions of
nonfree works (from traditional textbooks and scientific papers to
Khan Academy videos) is very much in line with the Wikimedia mission.
I don't think it requires hosting the works. To the extent that there
is concern about losing access to works that are currently available
via public URLs, the use of Internet Archive enabled citation URLs
provides a great example for how to avoid such link rot.

I'm sure there are also plenty of tech and non-tech ways Wikimedia
could support volunteers and chapters that work on outreach to set
more educational works free, none of which require the creation of a
nonfree archive.


Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] New essay on the ambiguity of NC licenses

2020-07-14 Thread Erik Moeller
James wrote:

> I simply wish that such a position would convince more
> organizations. WHO has repeatedly told me that we, as a non-profit, are
> already free to use their work and if we chose not to, that is on us.

I agree of course that this sort of institutional inertia can be
incredibly frustrating, especially in cases like WHO -- a publicly
funded international institution which should be putting its work in
the public domain. For all its own institutional failings (and there
are many, past and present), the US was at least able to get that much
right in its copyright laws more than 100 years ago. I don't believe
we should let publicly funded institutions that use restrictive
licensing terms off the hook, and there's a degree to which positive
persuasion needs to be coupled with public pressure here.

Like Pete, I'm curious about resources & practices folks have found
useful in persuading individuals or institutions to release materials
under free licenses. I'll reiterate that my sense is that _new_
partnerships that focus on material yet to be created may be a good
way to get a foot in the door, so to speak.

Alessandro wrote:

> At least, we should start centralizing that non-free material locally uploaded
> since it's already there. I would like logos of Universities and coat of arms
> of public administration and doubtful old images that according to some
> platforms are free but for Commons are not (gray areas), to be on a NC
> part of Commons, or a dedicated platform (i always link
> and

I agree that a nonfree wiki that does not alter existing policies
(i.e. is not intended to open the door to NC) is a reasonable thing to
consider for practical reasons; however, I personally oppose these
proposals on practical grounds. While the opposition to the main
proposal is currently a minority, I suspect the ratio would change
rather quickly if the proposals were more widely announced.

I see two primary scenarios for how a nonfree wiki could play out:

- scenario A: a nonfree wiki is successful at policing uploads and
usage consistent with the policies across wikis. Uploaders from those
communities are frequently frustrated and confused by deletions,
discussion, and policies of the nonfree wiki, just as they are
frustrated by deletions, discussions, and policies on Wikimedia
Commons today. With one more wiki in the mix, the process of uploading
files is increasingly seen to be akin to a Klingon Pain Stick Ritual.

- scenario B: a nonfree wiki is unsuccessful at policing uploads, and
becomes a DMCA magnet or worse. Communities are frustrated because
their own rules for limiting nonfree uploads are frequently violated
through the transclusion of files from the nonfree repository.

In fact, a combination of those two scenarios -- where there's deep
frustration about both enforcement and lack thereof -- seems most
likely to me.

It's worth asking whether there are good ways to improve the handling
and patrolling of nonfree files. I suspect there are many, but I'm
pretty sure the creation of a separate repository for this stuff is an
idea that doesn't withstand scrutiny. Exemptions must be considered in
a project-local context, both in terms of policy and concrete use, by
a community in its own language, and any improvements to efficiency
must start from this central premise.


Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] New essay on the ambiguity of NC licenses

2020-07-11 Thread Erik Moeller
Hi James :)

(This is my last reply for today, given the recommended posting limit
on this list.)

> We all agree that NC licenses are exceedingly poor due to the reasons
> listed, yet we leave a lot of useful content (such as Khan academy videos)
> less accessible to our readers because we disallow any such use.

I completely agree. I'm wondering if efforts have been made at the WMF
or chapter level to partner with these organizations on new
initiatives, where a more permissive license could be used? This could
perhaps help to introduce CC-BY-SA/CC-BY to orgs like Khan Academy,
and help lay the groundwork for potentially changing their default

> This is a balance between pragmatism and idealism.

I disagree with your framing here. There are many pragmatic reasons to
want to build a knowledge commons with uniform expectations for how it
can be built upon and re-used. It's also pragmatic to be careful about
altering the incentive structure for contributors. Right now,
Wikimedia Commons hosts millions of contributions under permissive
licenses. How many of those folks would have chosen an "exceedingly
poor" (your words) option like NC, if that was available? And if a
nonfree carve-out is limited to organizations like Khan Academy, how
is such a carve-out fair and equitable to contributors who have, in
some cases, given up potential commercial revenue to contribute to
Wikimedia projects?

If a license is "exceedingly poor" and harmful to the goals of the
free culture movement, incorporating more information under such terms
strikes me as neither idealistic nor pragmatic -- it would just be


Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] New essay on the ambiguity of NC licenses

2020-07-11 Thread Erik Moeller
On Sat, Jul 11, 2020 at 3:10 PM Michael Peel  wrote:

> I remember reading Erik’s blog post a decade or so ago, which convinced me 
> that -NC was useless due to its ambiguity - where exactly is the line drawn 
> between what is commercial and what is not? I can’t find it now is the canonical location of
that essay. I and others have updated it a bit since it was first
written, but it could definitely use some love :)

> Is there any way we could convince CC to deprecate the useless -NC licenses?

I doubt it given how pervasive it is. Back when those discussion were
hot, we were able to convince CC to add the "Approved for Free
Cultural Works" stamp you see on license pages like this one, to set
them apart more clearly:

It would be nice to see CC take a more active stance in at least
discouraging the use of NC in circumstances where it's not appropriate
(it's possible I've missed some work by CC to that effect).


Wikimedia-l mailing list, guidelines at: and
New messages to:

[Wikimedia-l] New essay on the ambiguity of NC licenses

2020-07-11 Thread Erik Moeller
Hi folks,

Pete Forsyth wrote a new essay on the ambiguities of the NonCommercial
("non-commercial use only") provision in Creative Commons licenses,
which I wanted to share in case it's helpful for folks making the case
against using NC to cultural institutions or others (or in the
occasionally resurgent debate to permit NC within Wikimedia):

It argues that NC is so ambiguous in its defining restriction that it
almost defeats the point of attaching a CC license at all. I feel this
complements the longer (dated!) essay at nicely.



Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] [Wikimedia Announcements] Announcing a new Wikimedia project: Abstract Wikipedia

2020-07-02 Thread Erik Moeller
This is wonderful news. :)

Thank you for the foresight to support this important initiative, and
huge thanks to Denny for continuing to tirelessly explore new ways to
make knowledge truly universally accessible! This project has the
potential to become a new foundation for learning about our world in
any language. I look forward to seeing this idea come to its fullest



Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] Giving Commons a bigger public

2020-05-23 Thread Erik Moeller
On Sat, May 23, 2020 at 4:20 PM Florence Devouard  wrote:

> For some reasons, it is true for "kitimaguru", but if I search for
> "lamp" (EN) versus "lampe" (FR), or "key" (English) versus "clé"
> (French), I really do not get the same results at all

I noticed that Hay just added a locale switcher, which as of this
writing allows you to switch into Dutch. As the list of locales
expands, you should get better results in each of those languages.

When the language is set to English, it will match against
labels/aliases in other languages, but will privilege matches against
English labels/aliases, and show the English description. It's
basically the equivalent of typing into the Wikidata search box, with
the Wikidata language set to English. Because there is no English
match for the Swahili word, that one works well even when the language
is set to English -- it'll rank the Swahili match as the first result.
But if you type "clé" into the Wikidata search box in English, the
first result is "Cleveland".



Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] Giving Commons a bigger public

2020-05-23 Thread Erik Moeller
On Fri, May 22, 2020 at 10:10 AM Gerard Meijssen

> Hay Kranen created a proof of concept where Commons is searched for
> pictures that (per standard) use a "depicts" statement.

This is a beautiful proof of concept; thank you for sharing it,
Gerard, and thank you, Hay, for developing it. It really illustrates
the power and importance of the Structured Data efforts.

To pick a different example, imagine that you want to illustrate an
article about the importance of wheelchair accessibility at your
university. You might try a major search engine like Google Images.
Try replacing the word "wheelchair" with translations in other
languages. Note how the result sets are different, and how you may get
a much smaller set of results in languages with a smaller Internet
presence. (English) (Swahili, far less
relevant and smaller set)

In contrast, the use of Wikidata items means that, as long as a label
exists for a given language, you can search in _any_ language and get
the same images:

The fact that the UI of this tool is currently English is an
implementation detail; even with Hay's implementation, you can type in
"kitimaguru" and get the same results as in English.

It would be wonderful to see this functionality developed further, and
to ultimately make this kind of search functionality central to the
user experience for Wikimedia Commons, so that speakers of any
language are  given _meaningful_ access to freely reusable media.



Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] .org TLD for sale?

2020-01-10 Thread Erik Moeller
On Wed, Jan 8, 2020 at 5:23 PM Katherine Maher  wrote:
> Quick update here. You may have seen some press coverage already, but this
> week, a group of technologists, non-profits, policymakers, and internet
> governance folks filed in California to create a cooperative membership
> corporation, whose purpose would be to administer the .ORG domain and its
> revenues on behalf of global non-profits and in support of the open,
> multistakeholder internet.

Truly brilliant nonprofit diplomacy -- thanks much for the update, and
huge thanks to everyone who's worked on this! :) Here's hoping that
the enclosure of .org can still be averted.



Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] .org TLD for sale?

2019-11-23 Thread Erik Moeller
Thanks for sharing this, Andy. This appears to be a major governance
failure on the part of ICANN (sadly, not for the first time). I'm glad
Wikimedia is among the first orgs on this list.

I don't think it's too late to stop this, especially as all evidence
points to corrupt inside wheeling-and-dealing. I would normally not
link to El Reg, but the connections Kieren has dug up deserve further
investigation by more reputable outlets.

Utterly unacceptable attempt to enclose the commons. Please do help
continue direct attention to this.



Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] Supporting Wikinews [was: Reviewing our brand system for our 2030 goals]

2019-05-13 Thread Erik Moeller
On Fri, May 10, 2019 at 5:54 AM Фархад Фаткуллин / Farhad Fatkullin

> I feel I can give a relatively neutral comment on the part quoted below.

Dear Farhad,

Thanks so much for sharing your observations re: . I'm glad to hear that the project is
publishing on a diverse range of topics, and that it includes original
reporting. It's also really good to learn that it's a place where
smaller language can publish stories before they're formally approved.

What really sets Russian Wikinews apart from the other Wikinews
language editions is that it's consistently been publishing stories
pretty much every day for quite some time now. I'd still love to know
if there's anything in particular that has made this possible, but
perhaps it's just "the right people at the right time", as is often
the case with smaller online communities. I very much hope that the
project will be able to keep it up.

In contrast, compare, for example, the month of April in the English
Wikinews edition:



Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] Farewell, Erik!

2019-02-07 Thread Erik Moeller
Thank you, Erik, for helping Wikimedia to know itself! I've always
appreciated the incredibly rich detail in your reports, your
willingness to unpack the awesome complexity of the wiki-verse, and
your insistence that this knowledge should be as free and open as the
Wikimedia projects are. I've learned a ton from you, and I am looking
forward to reading more about your new adventures as a volunteer. :)

From one Erik to another - my best wishes!

Wikimedia-l mailing list, guidelines at: and
New messages to:

[Wikimedia-l] Jamal Khashoggi's call to action

2018-10-17 Thread Erik Moeller
Up until recently, Saudi Arabian journalist Jamal Khashoggi worked for
the Washington Post. What happened to him? I couldn't say it better
than Wikipedia: [1]

(begin quote)

  On 2 October 2018, Khashoggi entered the Saudi Arabian consulate in
  Istanbul to obtain documents related to his marriage; he never left the
  building and was subsequently declared a missing person.
  Anonymous Turkish police sources have alleged that he was murdered
  and dismembered inside the consulate.

(end quote)

The Washington Post has now published Khashoggi's last column, titled
appropriately, "What the Arab world needs most is free expression".
[2] In it, he writes of the need for translation efforts and platforms
for free expression:

(begin quote)

  Arabs need to read in their own language so they can understand
  and discuss the various aspects and complications of democracy
  in the United States and the West. If an Egyptian reads an article
  exposing the actual cost of a construction project in Washington,
  then he or she would be able to better understand the implications
  of similar projects in his or her community.

  The Arab world needs a modern version of the old transnational
  media so citizens can be informed about global events. More
  important, we need to provide a platform for Arab voices. We
  suffer from poverty, mismanagement and poor education.
  Through the creation of an independent international forum,
  isolated from the influence of nationalist governments
  spreading hate through propaganda, ordinary people in the
  Arab world would be able to address the structural problems
  their societies face.

(end quote)

I'm wondering what folks in the Wikimedia community and movement make
of this call to action. Is there more that Wikimedia can do, for
example, to support translation of news articles into many languages?

There is nothing in Jamal's own op-ed that indicates that it would be
legally permissible to translate it. This is, unfortunately, the norm
for news; there are few outlets that use a Creative Commons license,
and those that do, typically tend to choose the most restrictive

Perhaps there would be value in an organized community effort that
would pick up news articles [3] that _are_ licensed under free
licenses, and translate them into as many languages as possible. If
launched under a prominent umbrella -- e.g., Wikimedia --, this might
then also help incentivize more outlets to selectively license content
openly, permitting translation. Beyond its intrinsic value, such an
effort would also help the Wikimedia projects by expanding the reach
of impacted citations into more languages.

Thoughts? Does Jamal's call to action resonate in other ways with
Wikimedia's mission?



[1] -- written by
multiple authors and distributed under Creative Commons Attribution
ShareAlike-License 3.0 Unported

-- quoted as fair use

[3] Likely restricted to some subset of outlets, e.g., sources most
Wikipedia editions would accept as citations

Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] Wikimedia Social: non-profit social networking service ?

2018-04-09 Thread Erik Moeller
On Mon, Apr 9, 2018 at 12:46 AM, Leinonen Teemu  wrote:
> I have been looking for social networking service that would be fair: not 
> abusing
> personal data, funded by community, respecting privacy, accepting anonymity,
> free/libre/ open source etc. Haven’t found many. The Diaspora* Project[1] is 
> not
> moving forward very fast and the Mastodon[2] is more a microblogging service
> rather than a social network service.

Wikimedia projects are social networks, but they are purpose-driven
social networks [1] where participants are more strongly connected
through their overlapping interests than through pre-existing social
connections. To the extent that Wikimedia should develop better social
networking tools, they should IMO be along the lines of the ideas
being prototyped by WikiProject X [2][3]. Improving other social tools
routinely used in connection with Wikimedia work, such as IRC and
mailing lists, likely would also have near term benefit.

I don't think that you can make a compelling argument that building
general purpose social networking software (as in, share cat+baby
pictures with friends) is in scope of Wikimedia's mission. But
Wikimedia organizations do use general purpose social networks like
Twitter and Facebook for outreach. I do think, given the Wikimedia's
strong orientation towards open source and open standards,
that_participating_ in open, decentralized communities like Mastodon
would be an appropriate way to extend that presence on existing
platforms. I personally think Diaspora can be safely ignored at this
point, and am hoping a better open FB alternative will emerge.



Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] About Facebook Linked in some of Wikimedia projects

2018-03-01 Thread Erik Moeller
On Thu, Mar 1, 2018 at 11:32 AM, Strainu  wrote:

>> Personally, I'd love to see WMF or a chapter set up a public Mastodon
>> instance; the project has matured significantly since its first
>> release and is at least a viable free/open alternative to the
>> Twitter-ish forms of social networking. FB still has event management
>> functions that are difficult to substitute, however.

> Even if there would be an open-source alternative with all the
> Facebook functionality, installing, maintaining and promoting it would
> be a huge waste of money.

I would agree if we compared centralized service to centralized
service (e.g. Ello vs. Facebook), but the premise of services like
Mastodon is federation between servers (instances) using open
protocols like ActivityPub. This means that even small organizations
can credibly host "instances" of a social network like Mastodon while
participating in the larger federation of users (you can follow users
from other instances, reply to their statuses, etc.). Mastodon is the
first IMO fairly successful implementation of this approach; it has
more than 1M accounts of which about 10% show recent activity, and it
already is reaching subcultures beyond the usual suspects.

To give you an idea of the cost, you can run a mid-size instance with
a few thousand users, automated backups and monitoring for tens of
dollars a month (the main cost is in person-time, but most instances
like this are run by volunteers and supported by donations). So I do
think it would be very possible even for an interested volunteer to
set up an instance with reasonable uptime, backup and monitoring
characteristics for exploratory use. Certainly it would be possible at
reasonable cost for WMF or a chapter to do so, possibly with some
"active contributor on Wikimedia projects" requirement for creating an

Once again, the crucial point here is that instances communicate with
each other, so even though your own instance may only have a few
thousand users, you are part of the larger "fediverse" which includes
software with completely different UIs implementing the same protocol.

A nice intro for the unfamiliar:

Incidentally, the protocol used by Mastodon, ActivityPub, recently
became a W3C recommendation:

Of course, I'm not opposed to people using FB for organizing -- I
think it's a totally reasonable choice, for the reasons you say -- but
I do think it's worth keeping an eye on federated social networks in
general, and Mastodon in particular, as a potential alternative space
for Wikimedia to engage in, _including_ for outreach. The numbers are
obviously still a drop in the bucket compared with the mega-networks,
so pragmatic considerations may reasonably prevail in many


Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] About Facebook Linked in some of Wikimedia projects

2018-02-28 Thread Erik Moeller
On Wed, Feb 28, 2018 at 5:31 PM, James Heilman  wrote:
> I am not seeing any link to Facebook here?

It's part of a banner, not sure the banner is set to 100%. It says:

"Azərbaycanca Vikipediya ilə daim əlaqədə olmaq üçün bizi "Facebook"da izləyin!"

in small font at the top, with a link to:

Personally, I'd love to see WMF or a chapter set up a public Mastodon
instance; the project has matured significantly since its first
release and is at least a viable free/open alternative to the
Twitter-ish forms of social networking. FB still has event management
functions that are difficult to substitute, however.


Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] September 28: Strategy update - Final draft of movement direction and endorsement process (#25)

2017-10-22 Thread Erik Moeller
On Fri, Oct 20, 2017 at 5:56 PM, Andreas Kolbe  wrote:

> I think it would be good to do some legal work to gain that clarity. The
> Amazon Echo issue, with the Echo potentially using millions of words from
> Wikipedia without any kind of attribution and indication of provenance at
> all, was raised on this list in July for example.

There is some basic attribution in the Alexa app (which keeps a log of
all transactions). As I said, I don't see a reason not to include
basic attribution in the voice response as well, but it still seems
worth pointing out. Here's what it looks like in the app (yup, it
really does say "Image: Wikipedia", which is all too typical):

I'm all in favor of a legal opinion on bulk use of introductory
snippets from Wikimedia articles without attribution/license
statement. While I'm obviously not a lawyer, I do, however, sincerely
doubt that it would give you the clarity you seek, given the extremely
unusual nature of authorship of Wikipedia, and the unusual nature of
the re-use. I suspect that such clarity would result only from legal
action, which I would consider to be extremely ill-advised, and which
WMF almost certainly lacks standing to pursue on its own.

> If CC-BY-SA is not enforced, Wikipedia will stealthily
> shift to CC-0 in practice. I don't think that's desirable.

Regardless of the legal issue, I agree that nudging re-users to
attribute content is useful to reinforce the concept that such
attribution goes with re-use. Even with CC-0, showing
providence/citations is a good idea.

> An interesting question to me is whether, with the explosion of information
> available, people will spend so much time with transactional queries across
> a large number of diverse topics that there is little time left for
> immersive, in-depth learning of any one of them, and how that might
> gradually change the type of knowledge people possess (information
> overload).

It's a fair question; the Internet has certainly pushed our ability to
externalize knowledge into overdrive. Perhaps we've already passed the
point where this is a difference in kind, rather than a difference in
degree, compared with how we've shared knowledge in the past; if
[[Neuralink]] doesn't turn out to be vaporware, it may push us over
that edge. :P

That said, people have to acquire specialized domain knowledge to make
a living, and the explosive growth of many immersive learning
platforms (course platforms like edX, Coursera, Udacity; language
learning tools like Duolingo; the vast educational YouTube community,
etc.) suggests that there is a very large demand. While I share some
of your concerns about the role of for-profit gatekeepers to
knowledge, I am not genuinely worried that the availability of
transactional "instant answers" will quench our innate thirst for
knowledge or our need to develop new skills.

I'm most concerned about information systems that deliver highly
effective emotional "hits" and are therefore more habit-forming and
appealing than Wikipedia, Google, or a good book. The negative effect
of high early childhood TV use on attention is well-documented, and
excessive use of social media (which are continuously optimized to be
habit-forming) may have similar effects. Alarmist "Facebook is more
addictive than crack" headlines aside, the reality is that social
media are great delivery vehicles for the kinds of little rewards that
keep you coming back.

In this competition for attention, Wikipedia articles, especially in
STEM topics, have a well-deserved reputation of often being nearly
impenetrable for people not already familiar with a given domain.
While we will never be able to reach everyone, we should be able to
reach people who _want_ to learn but have a hard time staying focused
enough to do so, due to a very low frustration tolerance.

I think one way to bottom line any Wikimedia strategy is to ask
whether it results in people getting better learning experiences,
through WMF's sites or through affiliates and partners. Personally, I
think the long term focus on "knowledge as a service" and "knowledge
equity" is right on target, but it's also useful to explicitly think
about good old Wikipedia and how it might benefit directly. Here are
some things that I think might help develop better learning
experiences on Wikipedia:

- a next generation templating system optimized for data exploration,
timelines, etc., with greater separation of design, code, data and
- better support for writing/finding articles that target different
audiences (beginners/experts)
- tech standards and requirements for embedding rich, interactive
"explorable explanations" beyond what any template system can do
- commissioned illustrations or animations for highly complex topics
(possibly organized through another nonprofit)
- assessment partnerships with external groups to verify that learners
get what they need from a given resource

In practice, this could translate 

Re: [Wikimedia-l] September 28: Strategy update - Final draft of movement direction and endorsement process (#25)

2017-10-20 Thread Erik Moeller
On Fri, Oct 20, 2017 at 12:51 AM, James Salsman  wrote:
> Erik,
> Should interactive web, internet of things, or offline services
> relying on Foundation encyclopedia CC-BY-SA content be required to
> attribute authorship by specifying the revision date from which the
> transluded content is derived?

James -

I don't think there's a sufficiently strong justification for
modifying the manner of attribution specified in the "Terms of Use",
which in any case would only apply to re-use of future revisions of
CC-BY-SA/CC-BY content that's not also exempted by "fair use".

As a best practice, I do believe including timestamp or version
information is helpful both for re-users themselves and for end users.
[[Progressive disclosure]] keeps such information manageable. In my
own re-use of CC-0 data from Wikidata, Open Library and similar
sources, I do include timestamp information along with the source.
Example re-use from Wikidata:


Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] September 28: Strategy update - Final draft of movement direction and endorsement process (#25)

2017-10-12 Thread Erik Moeller
On Tue, Oct 10, 2017 at 7:31 AM, Andreas Kolbe  wrote:

> Wikidata has its own problems in that regard that have triggered ongoing
> discussions and concerns on the English Wikipedia.[1]

Tensions between different communities with overlapping but
non-identical objectives are unavoidable. Repository projects like
Wikidata and Wikimedia Commons provide huge payoff: they dramatically
reduce duplication of effort, enable small language communities to
benefit from the work done internationally, and can tackle a more
expansive scope than the immediate needs of existing projects. A few
examples include:

- Wiki Loves Monuments, recognized as the world's largest photo competition
- Partnerships with countless galleries, libraries, archives, and museums
- Wikidata initiatives like mySociety's "Everypolitician" project or Gene Wiki

This is not without its costs, however. Differing policies, levels of
maturity, and social expectations will always fuel some level of
conflict, and the repository approach creates huge usability
challenges. The latter is also true for internal wiki features like
templates, which shift information out of the article space,
disempowering users who no longer understand how the whole is
constructed from its parts.

I would call these usability and "legibility" issues the single
biggest challenge in the development of Wikidata, Structured Data for
Commons, and other repository functionality. Much related work has
already been done or is ticketed in Phabricator, such as the effective
propagation of changes into watchlists, article histories, and
notifications. Much more will need to follow.

With regard to the issue of citations, it's worth noting that it's
already possible to _conditionally_ load data from Wikidata, excluding
information that is unsourced or only sourced circularly (i.e. to
Wikipedia itself). [1] Template invocations can also override values
provided by Wikidata, for example, if there is a source, but it is not
considered reliable by the standards of a specific project.

> If a digital voice assistant propagates a Wikimedia mistake without telling
> users where it got its information from, then there is not even a feedback
> form. Editability is of no help at all if people can't find the source.

I'm in favor of always indicating at least provenance (something like
"Here's a quote from Wikipedia:"), even for short excerpts, and I
certainly think WMF and chapters can advocate for this practice.
However, where short excerpts are concerned, it's not at all clear
that there is a _legal_ issue here, and that full compliance with all
requirements of the license is a reasonable "ask".

Bing's search result page manages a decent compromise, I think: it
shows excerpts from Wikipedia clearly labeled as such, and it links to
the CC-BY-SA license if you expand the excerpt, e.g.:

I know that over the years, many efforts have been undertaken to
document best practices for re-use, ranging from local
community-created pages to chapter guides and tools like the
"Lizenzhinweisgenerator". I don't know what the best-available of
these is nowadays, but if none exists, it might be a good idea to
develop a new, comprehensive guide that takes into account voice
applications, tabular data, and so on.

Such a guide would ideally not just be written from a license
compliance perspective, but also include recommendations, e.g., on how
to best indicate provenance, distinguishing "here's what you must do"
from "here's what we recommend".

>> Wikidata will often provide a shallow first level of information about
>> a subject, while other linked sources provide deeper information. The
>> more structured the information, the easier it becomes to validate in
>> an automatic fashion that, for example, the subset of country
>> population time series data represented in Wikidata is an accurate
>> representation of the source material. Even when a large source
>> dataset is mirrored by Wikimedia (for low-latency visualization, say),
>> you can hash it, digitally sign it, and restrict modifiability of
>> copies.

> Interesting, though I'm not aware of that being done at present.

At present, Wikidata allows users to model constraints on internal
data validity. These constraints are used for regularly generated
database reports as well as on-demand lookup via . This kicks
in, for example, if you put in an insane number in a population field,
or mark a country as female.

There is a project underway to also validate against external sources; see:

Wikidata still tends to deal with relatively small amounts of data; a
highly annotated item like Germany (Q183), for example, comes in at
under 1MB in uncompressed JSON form. Time series data like GDP is
often included only for a single point in 

Re: [Wikimedia-l] September 28: Strategy update - Final draft of movement direction and endorsement process (#25)

2017-10-09 Thread Erik Moeller
On Sat, Oct 7, 2017 at 1:00 PM, Andreas Kolbe  wrote:

> ... and it will all become one free mush everyone copies to make a buck. We
> are already in a situation today where anyone asking Siri, the Amazon Echo,
> Google or Bing about a topic is likely to get the same answer from all of
> them, because they all import Wikimedia content, which comes free of
> charge.

I wouldn't call information from Wikimedia projects a "mush", but I
think it's a good term for the proprietary amalgamation of information
and data from many sources, often without any regard for the
reliability of the source. Google is the king of such gooey
amalgamation. Its home assistant has been known to give answers like
this, sourced to "":

 "According to details exposed in Western Center for Journalism's
  exclusive video, not only could Obama be in be in bed with the
  communist Chinese, but Obama may in fact be planning a
  communist coup d'état at the end of his term in 2016."

See, e.g., this article

for other egregious examples specifically from Google's featured responses.

It's certainly true that Wikipedia is an easy target for ingestion,
not just because of its copyright status, but also because it is
comprehensive, multilingual, unrestricted (as in, not behind a paywall
or rate limit), and even fully available for download. But copyright
status is not really a major barrier once you are talking about fact
extraction and "fair use" snippets.

For Google, I suggest a query like "when was slavery abolished?"
followed by exploring the auto-suggested questions. In my case, the
first 10 questions point to snippets from:

- (twice)
- USA Today
- Reuters
- Wikipedia (twice)

Even for its fact boxes, where Wikipedia excerpts often feature
prominently, Google does not exclusively rely on it; the tabular data
contains information not found in any Wikimedia project. Even the
textual blurbs often come from sources of unclear provenance; for
example, country blurb text (try googling "France" or "Russia") is not
from WP.

This amalgamation will get ever more sophisticated and more
proprietary (specific to each of these corporations) as AI improves.
That's because it lets companies pry apart "facts" and "expression":
the former are uncopyrightable. As textual understanding of AIs
improves, more information can be summarized and presented without
even invoking "fair use", much in the same way as Wikipedia itself
summarizes sources.

It's the universe of linked open data (Wikipedia/Wikidata,
OpenStreetMap, and other open datasets) that keeps the space at least
somewhat competitive, by giving players without much of a foothold a
starting point from which to build. If Wikimedia did not exist, a
smaller number of commercial players would wield greater power, due to
the higher relative payoff of large investments in data mining and AI.

> I find that worrying, because as an information delivery system,
> it’s not robust. You change one source, and all the other sources
> change as well.

As noted above, this is not actually what is happening. Commercial
players don't want to limit themselves to free/open data; they want to
use AI to extract as much information about the world as possible so
they can answer as many queries as possible.

And for most of the sources amalgamated in this manner, if provenance
is indicated at all, we don't find any of the safeguards we have for
Wikimedia content (revisioning, participatory decision-making,
transparent policies, etc.). Editability, while opening the floodgate
to a category of problems other sources don't have, is in fact also a
safeguard: making it possible to fix mistakes instead of going through
a "feedback" form that ends up who knows where.

With an eye to 2030 and WMF's long-term direction, I do think it's
worth thinking about Wikidata's centrality, and I would agree with you
at least that the phrase "the essential infrastructure of the
ecosystem" does overstate what I think WMF should aspire to (the
"essential infrastructure" should consist of many open components
maintained by different groups). But beyond that I think you're
reading stuff into the statement that isn't there.

Wikidata in particular is best seen not as the singular source of
truth, but as an important hub in a network of open data providers --
primarily governments, public institutions, nonprofits. This is
consistent with recent developments around Wikidata such as query

Wikidata will often provide a shallow first level of information about
a subject, while other linked sources provide deeper information. The
more structured the information, the easier it becomes to validate in
an automatic fashion that, for example, the subset of country
population time series data represented in 

Re: [Wikimedia-l] September 28: Strategy update - Final draft of movement direction and endorsement process (#25)

2017-10-03 Thread Erik Moeller
On Tue, Oct 3, 2017 at 4:10 AM, Andreas Kolbe  wrote:

> Reading between the lines of statements like "Knowledge as a service",
> "essential infrastructure", "tools for allies and partners to organize and
> exchange free knowledge beyond Wikimedia", etc., my sense is that the
> document, without saying so explicitly, is very much written from the
> perspective that the likes of Google, Amazon, Apple, Bing (and anyone else
> developing digital assistants and other types of knowledge delivery
> platforms) should be viewed as key partners in the exchange of free
> knowledge, and served accordingly, through the development of interfaces
> that enable them to deliver Wikimedia content to the end user.
> My problem with that is that those are all for-profit companies, while the
> volunteers that contribute the free content on which these companies'
> profit-making services are based are not only unpaid, but actually incur
> expenses in contributing (mostly related to source access).

This seems to be a somewhat prejudiced "reading between the lines".
For-profits like Google, Amazon, Apple, Microsoft will extract as much
information as they can from as many sources as they can giving back
as little as they have to (which includes some activity designed to
maintain and increase goodwill, which itself has value), _regardless
of what Wikimedia does or doesn't do_. They have built knowledge
graphs without the use of Wikidata and without significant assistance
from WMF, incorporating information from countless proprietary sources
alongside free sources.

The power of an open, nonprofit approach to "knowledge as a service"
is precisely to democratize access to knowledge graph information: to
make it available to nonprofits, public institutions, communities,
individuals. This includes projects like the "Structured Data for
Wikimedia Commons" effort, which is a potential game-changer for
institutions like galleries, libraries, archives and museums.

Nor is such an approach inherently monopolistic: quite the opposite.
Wikidata is well-suited for a certain class of data-related problems
but not so much for others. Everything around Wikidata is evolving in
the direction of federation: federated queries across multiple open
datasets, federated installations of the Wikibase software, and so on.
If anything, it seems likely that a greater emphasis on "knowledge as
a service" will unavoidably decentralize influence and control, and
bring knowledge from other knowledge providers into the Wikimedia

I had no involvement with this document and don't know what focusing
on "knowledge of a service" really will mean in practice. But if it
means things like improving Wikidata, building better APIs and content
formats, building better Labs^WCloud infrastructure, then the crucial
point is not that companies may benefit from such work, but that
_everybody else does, too_. And that is what distinguishes it from the
prevailing extract-and-monetize paradigm. For-profits exploting free
knowledge projects for commercial gain? That's the _current state_. To
change it, we have to make it easier to replicate what they are doing:
through open data, open APIs, open code.


Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] Mailing list usability: Observations about Mailman 3

2017-08-17 Thread Erik Moeller
On Thu, Aug 17, 2017 at 7:59 AM, rupert THURNER
>> A somewhat related ticket about trying to unify our discussion platforms
>> was discussed in a session at Wikimania:

> Interesting thanks for the pointer. Compared to the options listed there a
> mailman upgrade looks rather straight forward and, personally I d really
> appreciate if it could be done, for the benefits Eric listed.

To be clear, I don't think an upgrade to MM3 would be straightforward;
it would be quite a hairball keeping multiple people busy and should
only be done incrementally. I say this only to avoid feeding a "Why
haven't we done this simple thing yet" narrative that sometimes
develops around software updates/upgrades, not in order to
specifically criticize your statement. This isn't a simple update by
any means.

I think the Q/A site vs. mailing list are very complementary
approaches. A StackExchange style knowledge platform certainly may
serve certain use cases identified in the ticket Niharika linked to,
and some experimentation with different approaches seems wise.

One word of caution -- open source clones are often poor carbon copies
that lack important functionality and algorithmic sophistication that
made the platforms they are cloning successful. This may include even
wiki-style functionality (for example, Quora has an "Answer Wiki"
feature sometimes used to highlight the salient aspects of the best

Without such correctives, you may replicate certain well-known
problems with upvote/downvote systems, such as a bias towards old
answers that received lots of votes early on but have been superseded
by much better responses.

The upvote/downvote feature in the Mailman 3  UI [*] that I mentioned
is so minimal that I think it can be ignored for all intents and
purposes, and would probably best be removed or disabled to minimize
confusion and clutter.


[*] to be precise, it is a feature of Hyperkitty, the archive frontend
that also allows posting through the web

Wikimedia-l mailing list, guidelines at: and
New messages to:

[Wikimedia-l] Mailing list usability: Observations about Mailman 3

2017-08-14 Thread Erik Moeller
Hi folks,

The topic of list usability has come up here a few times in the past,
and efforts have been made over the years to pilot alternative forum
systems like Discourse, or to redirect more conversations to talk
pages.  Yet the mailing lists continue to be used for a significant
share of long-form Wikimedia discussions and announcements (see stats
at [1]).

There's a Phabricator ticket [2], currently marked as stalled, for
upgrading Wikimedia's mailing list software, Mailman, to the newest
version. Mailman 3 is a complete rewrite, and this upgrade would
unquestionably be a major team-level effort. I've recently set up a
Mailman 3 install [3] (without archive migration) and wanted to share
some observations that may help with a decision to stay on the Mailman
2 line or attempt an upgrade. Sent to wikimedia-l because I think this
discussion deserves a bit more mind-share beyond the developer

To see an active Mailman 3 community, check out the Fedora project's:

== The good ==

You can make a user account (including with third party providers,
opening the door for Wikimedia account integration), which makes
managing your subscriptions a bit easier. You don't have to sign up to

You can post through the web. This is a pretty big deal, as it opens
up list participation to folks who don't want to use email for this
purpose. It makes the whole experience more forum-like for those who
prefer that.

The interface is responsive and mobile-friendly. It uses the
widespread "Bootstrap" theme which is a bit generic but pleasing

You can search the archives.

There are some nice forum-like activity indicators in the web
interface and (sure to be controversial) upvote/downvote buttons for
posts, though the latter seem to largely be ignored in real-world

While setting the software up was difficult (easier if you have prior
familiarity with Django), I did not encounter any showstopper bugs.

== The bad ==

The web interface does not degrade gracefully to users without
JavaScript: important features just stop working.

The list administration tool has some new features, but it has also
lost old features. For example, while Mailman 2 lets you easily change
per-user moderation from the the "held messages" interface, this is
still an open task in Mailman 3. [4]

The more modular approach in Mailman 3 means that features don't
always play together. For example, you can delete a list, but deleting
the archives requires manual execution of an un-official Python code
snippet. [5]

This modularity also means some defaults are unhelpful. For example,
the default emails generated by the software do not link to the web
interface, because the web interface is a separate module that may not
be installed.

== The ugly ==

The platform is not yet ready for translation, and the interface is in
English only. Quoth the project leader in response to whether it is
possible to change the UI language: [6]

> Unfortunately no. We've never gotten much traction for fully
> translating Mailman 3. We've had some interest but what we really
> need is a champion to drive the initiative. One of our biggest blockers
> is choosing a translation platform that's compatible with our free software
> constraints, but also requiring a minimal amount of ongoing infrastructure
> support from us.

(Hey, I think I know such a platform.)

Faithful migration will likely also require some level of custom
development. Quoth the docs: [7]

> The short version is that as of now, upgrading from Mailman 2.1
> to Mailman 3.1 is buggy.
> Now the long version. Because of the changes in Database Schema,
> migrating from Mailman 2.1 to Mailman 3.1 is not very easy, though it
> can be done with some scripting. We are working on it and it should be
> working soon, we don’t have an exact timeline on it though.
> Archives however can be imported into Hyperkitty easily, however URLs
> to attachments are going to break because the URL paths are different
> in Hyperkitty. Although, You might be able to retain your HTML archives
> from Mailman 2.1 and continue archiving newer emails in Hyperkitty.

== What to do? ==

It's doubtful that Mailman 3 will magically advance in leaps and
bounds over the coming years. Adoption generally tends to drive
interest and development, and a WMF decision to upgrade may motivate
others to work towards solving longstanding problems like the i18n
issue. The Fedora installation appears to show that it's possible to
run Mailman 3 at scale already, though I haven't spoken to them about
their experiences.

I don't believe that the usability advantage Discourse currently
enjoys is inherent to web forums -- Mailman 3 shows that there is a
development path to make mailing lists more accessible and friendly,
as well, even if there is still a lot of work to be done.

My main recommendation would be to evaluate the state of play towards
a more explicit choice between 

Re: [Wikimedia-l] Wikitribune!

2017-04-28 Thread Erik Moeller

I think it's a great initiative! First, kudos for using the CC-BY
license. I have reviewed a large number of nonprofit journalism
outlets over the last few months [1], and this decision alone would
set the project apart from even the public interest media sphere.
There are only a few nonprofit news/journalism projects using a free
or semi-free license, e.g.:

- Common Dreams (lefty/progressive site) uses CC-BY-SA
- Mosaic (science publication) uses CC-BY
- The Conversation (sort of a nonprofit/academic uses CC-BY-ND
- ProPublica uses CC-BY-NC-ND
- Aeon (science/philosophy) uses CC-BY-ND for some content

But for the most part, even nonprofit publications tend to use
conventional copyright, making it difficult for Wikimedia and other
free culture projects to collaborate with them (and of course the more
restrictive CC licenses above are not Wikimedia-compatible either).

I hope the license will apply to photographs/videos as well as text,
since a lot of media files will be of immediate value to the free
culture world.

Second, kudos for not paywalling the content. A lot of people seem to
re-discover the idea of paywalls in 100 different forms and sell it as
innovative. Again, it prevents collaboration with other communities.

There's no mention in the FAQ as to whether WikiTribune will be
nonprofit or not, or whether that's even on the table. I am guessing
the answer is no, but it would be good to clarify that. Similarly, it
would be good to make any commitment to the development/use of open
source software beyond WordPress explicit.

Good luck raising the $/supporter goal and hopefully launching the
site, will definitely be keeping an eye on it. :)



Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] More politics: "WMF Annual Report"

2017-03-02 Thread Erik Moeller
On Thu, Mar 2, 2017 at 12:26 PM, Stuart Prior

> As an example, anthropogenic climate change is a politically sensitive
> issue, but how can a consensus-driven movement not take into account that
> 97% of climate scientists acknowledge its existence
> ?
> [1] 
> Accepting a scientific consensus just isn’t a political position.

It isn't, but I think it's still worth thinking about context and
presentation. There are organizations whose job it is to directly
communicate facts, both journalistic orgs like ProPublica and
fact-checkers like Snopes/Politifact. In contrast, WMF's job is to
enable many communities to collect and develop educational content.

If the scientific consensus on climate change suddenly starts to
shift, we expect our projects to reflect that, and we expect that the
organization doesn't get involved in those community processes to
promote a specific outcome. The more WMF directly communicates facts
about the world (especially politicized ones), rather than
communicating _about_ facts, the more people (editors and readers
alike) may question whether the organization is appropriately
conservative about its own role.

I haven't done an extensive survey, but I suspect all the major
Wikipedia languages largely agree in their presentation on climate
change. If so, that is itself a notable fact, given the amount of
politicization of the topic. Many readers/donors may be curious how
such agreement comes about in the absence of top-down editorial
control. Speaking about the remarkable process by which Wikipedia
tackles contentious topics may be a less potentially divisive way for
WMF to speak about what's happening in the real world.

I do think stories like the refugee phrasebook and Andreas' arctic
photography are amazing and worth telling. I'm curious whether folks
like Risker, George, Pine, Chris, and others who've expressed concern
about the report agree with that. If so, how would you tell those
stories in the context of, e.g., an Annual Report?


Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] More politics: "WMF Annual Report"

2017-03-01 Thread Erik Moeller
On Wed, Mar 1, 2017 at 3:44 PM, Florence Devouard  wrote:
> For example... the message "one in six people visited another country in
> 2016"... illustrated by "SeaTac Airport protest against immigration ban.
> Sit-in blocking arrival gates until 12 detainees at Sea-Tac are released.
> Photo by Dennis Bratland.CC BY-SA 4.0"
> Really... "visiting a country" is a quite different thing from
> "immigrating".

The caption is in fact misleading because it uses the phrase
"immigration ban", which is a mischaracterization of the ban. The
Executive Order was not an immigration ban; it (temporarily) banned
people from those countries from entering the United States, even for
visits, with some exceptions. See:

If the photo remains, I recommend changing this caption to use either
"travel ban" or "entry ban"; both phrases are used in the Wikipedia


Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] Politics

2017-02-04 Thread Erik Moeller
On Sat, Feb 4, 2017 at 6:58 AM, Mike Godwin  wrote:
> (2) As I put it many times many years ago in the years before and
> after the SOPA/PIPA blackout, there are few POVs *less* neutral than
> the commitment to give all the information in the world to everyone
> for free. We are not a neutral enterprise, and we never have been.

Indeed not. I agree with Mike's entire post. WMF must speak out
against threats that directly impact its ability to serve its mission.
Sometimes it will be able to do so in concert with community action
(as in the case of SOPA/PIPA), sometimes it will be acting on its own
behalf. The WMF blog is exactly the right place for the latter type of

The revocation of some 60,000 visas [1] and implementation of a travel
ban targeting a religious group is precisely the type of action that
directly impacts WMF's ability to do its work. To frame this simply as
a matter of refugee policy misunderstands the nature of the executive
order [2], which also bars other visa holders from targeted countries.

The WMF is committed to internationalism and diversity through its
policies [3], through its long-standing participation in international
outreach programs like Google Summer of Code, through hosting,
supporting and participating in events all around the world, and --
most importantly -- through its mission and vision statement which are
global in scope and aspiration.

To make clear that it is opposed to this obvious violation of human
rights with all the consequences it has already entailed (regardless
of the possibly temporary suspension of the ban) is _precisely_ what
we should expect from WMF. We should object if it had _not_ issued a
statement. To frame this within the terms of the neutrality of the
encyclopedia is a mistake. The encyclopedia is neutral; the WMF most
definitely cannot be when its ability to do its work is threatened,
_especially_ in the jurisdiction within which it operates.

While I agree that it's important to define the boundaries of WMF's
political expression, I see its statement on EO 13769 as clearly
within any rational such definition that is consistent with its
mission and vision.





Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] With my thanks to everyone ...

2016-07-13 Thread Erik Moeller
Geoff --

Many thanks for all you've done for the movement! You helped take the
WMF to a new level of professionalism, built a fantastic team, and led
it during some of the most pivotal moments in the organization's
history. During our years of working together, I deeply admired your
dedication to continuously making things better, providing mentorship
to your team and across the org, and deftly navigating the complexity
of the wiki world.

Above all, you embodied the organization's mission and values every
day, whether it was about free speech, transparency and inclusiveness,
free culture, the threat of global surveillance, or any other issue.

YouTube is lucky to bring you on board, and WMF is lucky you've built
such a great team to take things from here. Congrats and best of luck!


Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] [recent changes]

2016-04-08 Thread Erik Moeller
Hey Denny --

Kudos for your well-reasoned decision, and for your service on the
Board during a very challenging time. One of the beautiful things
about Wikimedia is how much scope you can have to move things forward
without any special roles or affiliation. I very much look forward to
reading your crazy-or-maybe-not-so-crazy ideas!


Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] The Case for Federation: Should Parts of WMF Be Spun Off?

2016-03-24 Thread Erik Moeller
2016-03-21 13:53 GMT-07:00 Mark A. Hershberger :
> We've since held three meetings[3][4][5] and have planned two more.
> During the meeting planned for about six weeks from now[6], we intend
> to have a format that allows us to respond to questions or concerns from
> the larger community.

This is very encouraging, Mark, thanks for the summary! It sounds like
there's already quite a bit of traction for creating a MediaWiki
focused organization. I'll try to join the upcoming meetings and
provide input/help where I can. Is there an active asynchronous
conversation space about this somewhere (talk page, listserv, forum,
whatever)? If not, should we use
for ongoing conversation about this?


Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] The Case for Federation: Should Parts of WMF Be Spun Off?

2016-03-24 Thread Erik Moeller
2016-03-24 3:35 GMT-07:00 Andre Engels :

>> Since the "Mediawiki" trademark was lost to WMF the day you and
>> Anthere placed the logo into public domain [1], how can the WMF now
>> spin-off this new organization ?.

> That's incorrect, putting something in the public domain does not
> remove trademark rights.

Indeed, acknowledging that it did not need to enforce strong
copyrights on the logos to protect the trademarks, WMF released all
its remaining non-free logos under CC-BY-SA in October 2014:

"MediaWiki" is an internationally registered trademark, as you can
verify e.g., through


Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] The Case for Federation: Should Parts of WMF Be Spun Off?

2016-03-19 Thread Erik Moeller
2016-03-17 22:54 GMT-07:00 Pine W :
> I agree that these options should be explored. I'm wondering what the best
> way would be to facilitate this conversation.
> Perhaps, Erik, would you be willing to set up a page on Meta for discussion?

Hi Pine,

Thanks for the comments! I wanted to start here to get a sense if
people are supportive of the idea(s) in general. In my experience a
listserv is good for kicking things around a bit before getting too
emotionally invested. ;-) And this list has a good cross-set of folks
with different backgrounds including WMF and affiliates. If there's a
general sense that this is worth exploring further, then I'd be more
than happy to help organize pages on Meta, e.g. to think about
specific spin-offs like the MediaWiki Foundation (if there isn't
already an extant proposal for it).

> On the WMF side, I'm wondering how this would fit into their annual
> planning. Their plan is supposed to be published on April 1. This
> discussion will need resources from WMF's end in the form of staff time,
> including Katherine's, as well as Board time. The required investment in
> the short term will be modest, but cumulatively through the year it may be
> significant, particularly if the discussions get momentum. So I'm wondering
> how, at this point, it would be possible to take these discussions into
> account in the WMF AP.

Unless WMF plans to dramatically expand in the next fiscal (which I
doubt), I think this discussion can and needs to happen on its own
timeline. I expect that if WMF suggests to depart a bit from what's
written into a one-year plan, with good reasons, the institutions of
the movement will have the flexibility to accommodate that.

I also understand WMF folks are very busy with the plan right now, and
I don't think there's special urgency to this conversation, which is
one with lots of long term implications. I do hope folks have a chance
to weigh in, but if that happens over the course of few weeks/months
in different venues, I personally think that's fine.

> This series of operations, while complicated, may yield a more resilient
> movement in the end, possibly with more combined funding, more
> accountability and transparency, and more credibility.

Yes, I hope so. :) But let's take it slowly and poke at this from
different angles to see if it makes sense.



Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] The Case for Federation: Should Parts of WMF Be Spun Off?

2016-03-19 Thread Erik Moeller
2016-03-18 9:01 GMT-07:00 Sydney Poore :

Hi Sydney!

> Right now the central hub of the global movement is WMF. Despite other
> recent problems. The WMF is doing a great job of regularly communicating
> about the world wide movement.
> There needs to be a successful transfer of the global mission to another
> body/bodies or there is the risk that local growth will be even more uneven
> than today.

Yes, I agree with that, and I think it's generally what characterizes
successful federate models. A "Wikimedia Movement Association" with
global membership could address this. Let's say as a hypothetical that
grantmaking and evaluation responsibilities ultimately become part of
such a WMA's scope. That would naturally give it a lot of
responsibility for sharing practices, bringing attention to things
that work, and helping to organize postmortems or governance reviews
where appropriate.

Not being itself responsible for a large body of programs, and being
accountable to its members, it could be in a better position to foster
a global sense of belonging and accountability. I suspect a lot of us
would become dues-paying members of such an organization, and proudly

To the extent that it would do programmatic work, like organizing
conferences or developing tools for evaluation, it would likely do so
by contracting that work out to affiliates within the movement, or
externally if necessary. That would enable it to remain lean,
staffing-wise. And incidentally, it could enable organizations like
WMDE to bid for contracts alongside WMF, yielding the benefits of
light competition and greater geographic diversity.

What would a WMA _not_ do? It would not host servers, or deal with
trust and safety issues on the websites, or respond to DMCA notices,
or develop MediaWiki improvements.  It _might_ have a stewardship role
for movement resources, like the movement blog and potentially even
the brand assets, as an ultimate safety valve.

In short, a movement association would act as a direct proxy for the
movement, maintaining a network of clearly scoped short term and long
term relationships to advance the Wikimedia mission. It would not
replace the WMF, but it would give it a more clearly defined scope of
responsibilities and a more equal footing within the movement.


Wikimedia-l mailing list, guidelines at:
New messages to:

[Wikimedia-l] The Case for Federation: Should Parts of WMF Be Spun Off?

2016-03-19 Thread Erik Moeller
Hi folks,

Now that the dust has settled a bit, I would like to expand on an idea
that’s been touched on a few times (most recently, in an editorial by
William Beutler [1]): the notion that WMF might be a more effective
organization if it limited its own size in favor of focused spin-off
organizations and affiliates.

I was very much part of building the current WMF in terms of both size
and structure, but I also think recent events underscore the fragility
of the current model. WMF is still tiny compared with other tech
companies that operate popular websites, but it’s a vast organization
by Wikimedia movement standards. With nearly 300 staff [2] (beyond
even our ambitious 2015 strategic plan staffing numbers), it dwarfs
any other movement org.

I can see three potential benefits from a more federated model:

1) Resilience. If any one organization experiences a crisis, other
independent organizations suffer to a lesser degree than departments
within that organization.

2) Focus. Wikimedia’s mission is very broad, and an organization with
a clearly defined mandate is less likely to be pulled in many
different directions -- at every level.

3) Accountability. Within a less centralized federation, it is easier
to ensure that funding flows to those who do work the movement wants
them to do.

My experience is that growth tends to be self-reinforcing in budgetary
processes if there are now clear ceilings established. I think that’s
true in almost any organization. There’s always lots of work to do,
and new teams will discover new gaps and areas into which they would
like to expand. Hence, I would argue for the following:

a) To establish 150 as the provisional ceiling for Wikimedia movement
organizations. This is Dunbar’s number, and it has been used
(sometimes intentionally, sometimes organically) as a limiting number
for religious groups, military companies, corporate divisions, tax
offices, and other human endeavors.  [3][4] This is very specifically
because it makes organizational units more manageable and
understandable for those who work there.

b) To slowly, gradually identify parts of the WMF which would benefit
from being spun off into independent organizations, and to launch such
spin-offs, narrowing WMF's focus in the process.

c) To aim to more clearly separate funding and evaluation
responsibilities from programmatic work within the movement -- whether
that work is keeping websites running, building software, or doing
GLAM work.

Note that I'm not proposing a quick splintering, but rather a slow and
gradual process with lots of opportunity to course-correct.

More on these points below.

== Potential test case: MediaWiki Foundation ==

A "MediaWiki Foundation" [5] has been proposed a few times and I
suspect continues to have some currency within WMF. This org would not
be focused on all WMF-related development work, but specifically on
MediaWiki as software that has value to third parties. Its mission
could include hosting services as earned income (and potentially as an
extension of the Wikimedia movement’s mission).

MediaWiki is used today by numerous nonprofit and educational projects
that are aligned even with a narrow view on Wikimedia’s mission.
Examples include Appropedia, OpenWetWare, WikiEducator, W3C’s
WebPlatform, Hesperian Health Guides, and too many notable open source
projects to list.

Among commercial users, it has lost much ground to other software like
Confluence, but it remains, in my view, the most viable platform for
large, open, collaborative communities. Yet it’s a poorly supported
option: many of the above wikis are outdated, and maintaining a
MediaWiki install is generally more work than it needs to be.

Building a healthy third party ecosystem will have obvious benefits
for the world, and for existing Wikimedia work as well. It may also
create a proving ground for experimental technology.

Which work that WMF is currently doing would be part of an MWF’s
mandate? I don’t know; I could imagine that it could include aspects
like Vagrant, or even shared responsibility for MediaWiki core and
MW’s architecture.

== The Wiki Education Foundation precedent ==

It’s worth noting that this spin-off model has been tried once before.
The Wiki Education Foundation is an example of an organization that
was created by volunteers doing work in this programmatic space in
partnership with staff of the Education Program at WMF, who left to
join the new org. It is now financially independent, building its own
relationships with funders that WMF has never worked with, and
achieving impact at unprecedented scale.

LiAnna Davis, who is today the Director of Program Support at Wiki Ed,
wrote a detailed response to William’s blog post, which I think is
worth quoting in full [1]:

begin quote
I worked for the WMF for nearly four years and have worked for the
spun-off Wiki Education Foundation for the last two, and I strongly
support the idea of spinning off more parts of WMF into 

Re: [Wikimedia-l] any open search engine for web project starting

2016-03-19 Thread Erik Moeller
2016-03-18 21:44 GMT-07:00 SarahSV :
> On Fri, Mar 18, 2016 at 5:17 PM, carl hansen 
> wrote:
>> "We are building a nonprofit search engine for the Web"
>> Sounds alot like Knowledge Engine, if there were such a thing.
>> Any overlap with wikimedia projects?

> Thanks for the link, Carl. Erik and Lydia are advisors, so perhaps they
> could say a bit more about it.

Sylvain has been working on this stuff for a while, blissfully
ignorant of Wikimedia's discussions of search engines, rocketships and
so on. He reached out to me shortly before the public announcement and
we've talked a bit about governance, community & funding models. I've
agreed to provide some continued advice along the way but have not
otherwise been involved.

He recently posted on wikitech-l asking for suggestions how
Wikipedia/Wikidata could be integrated:

There's a lot of heavy lifting still until Common Search can become a
viable project even for narrowly defined purposes but I think it's a
very worthwhile effort. It also is -- I think correctly -- based on
the largest pre-existing open effort to index the web, the Common
Crawl. This could lead to a mutually beneficial relationship between
Common Search and Common Crawl. From a Wikimedia perspective, it might
develop into an opportunity to jointly showcase some of the amazing
stuff that Wikidata can already do.


Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] Wikimedia Foundation executive transition update

2016-03-10 Thread Erik Moeller
Congratulations to the Board and to Katherine!

It is good to see the organization led by a person with such a strong
and proven commitment to human rights, access to knowledge, and
transparency. I've also been deeply impressed by all the work
Katherine has done in her previous role at WMF.

Best of luck in facing the challenges ahead. :)


Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] Fwd: A conversation?

2016-03-10 Thread Erik Moeller
2016-03-09 23:21 GMT-08:00 SarahSV :

>> And no, I'm not a fan how things have played out so far, and I'm not
>> arguing for just moving on without addressing remaining grievances.
>> But this isn't how we should move forward.

> Erik, what do you see as the alternative?

To clarify, I was specifically objecting to the leaked private email,
not to addressing the issues with James' ejection from the Board. I
know James and worked with him especially on the Wikivoyage migration;
I understand well why he is so widely trusted and why this matter has
cut deep wounds.

I would suggest the following.

* I would still ask to give the Board a little time to finalize their
decision regarding the interim ED, which seems imminent. That means
not just announcing, but also some time to provide support and
orientation in that person's first weeks. (E.g., the interim ED will
need to build a relationship with the Board itself.)

* Until then, I suggest focusing on documenting rather than debating.
What Molly did with the timeline is a fine example of "collaborative
journalism" and the Wikimedia community is at its best when it
collects the facts in an NPOV manner. Coordinating this on a single
page can reduce the forest fire nature of this conflict. I strongly
recommend avoiding one-sided leaks of private emails and such for the
reasons I gave.

* Once the Board has a bit of bandwidth, the Chair of the Board
(Patricio) really is the primary person to look to for bringing
closure to this matter. Dealing with issues with current and former
Board members is _precisely_ the kind of thing a Board Chair needs to
demonstrate leadership on, because it can't be done by committee.

* To do this in a manner that's both transparent and consistent with
community norms, I've suggested engaging a professional facilitator.
(I believe Pete has also said so several times.) There could be a
private/public meeting, where there's a private discussion with James
and the facilitator, and a public joint statement that comes out of
this, even if it ends up being "agree to disagree". It's the
facilitator's job that this comes to pass.

* That public bit could lead into a general public discussion with the
Board. I would recommend a metrics meeting style format (video + IRC
backchannel) with a wiki page to submit questions beforehand, and +1

If that plan seems sensible, I would also suggest Jimmy disengage on
the James Heilman matter from here on and leave this issue to the
Board Chair to bring closure to.

Hope that helps. I know this has all been exhausting for lots of
folks, so please take it in the spirit in which it is intended, i.e.
to help bring closure to it in a step-by-step way.


Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] Fwd: A conversation?

2016-03-09 Thread Erik Moeller
2016-03-09 16:56 GMT-08:00 Pete Forsyth :

> I feel this message can provide important insight into the dynamics
> surrounding James H.'s dismissal, and various people have expressed
> interest in seeing it, so I'm forwarding it to the list. (For what it's
> worth, I did check with James H.; he had no objection to my sharing it.)

Pete, regardless of Jimmy's words in this email, like others, I fail
to see how it's okay to share a private email to this list. I can
think of a few instances where this might be ethically defensible --
like actual fraud being committed -- but this is not one of them. It's
totally fair for people to ask Jimmy to clear the air on stuff
himself, but this crosses the line, at least from my point of view.

This comes down to giving a person you're corresponding with an
honest, open channel by which they can apologize, clarify, and make
things right. By violating that private channel you're making it
implicitly impossible to have that kind of conversation.

Meatball Wiki, as you know, has some wise words on this kind of stuff. is a good page to

And no, I'm not a fan how things have played out so far, and I'm not
arguing for just moving on without addressing remaining grievances.
But this isn't how we should move forward. Criticizing people's
actions is fair game, even calling for resignation or other types of
structural and organizational change. This kind of picking out of
lines from private emails ought _not_ to be, in my view.


Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] Open and recorded WMF Board meetings

2016-03-02 Thread Erik Moeller
2016-03-02 23:22 GMT-08:00 Erik Moeller <>:
> Jimmy made a couple of suggestions earlier [1], including to publish
> all presentations given to the Board and to have a trusted community
> observer.

"Nearly all", to paraphrase accurately, and on re-reading the email
I'm not sure I understand the "observer" idea ("a program of invited
board observers from people who are well known and well trusted by the
community"). Personally, I do find it intriguing but I'm not sure it
would add much value transparency-wise, unless these observers play
some kind of role in the discussion of what gets published, i.e. they
effectively act as advocates for transparency.

> When it comes to presentations, the manual primarily refers to
> exceptions such as Legal presentations and documents "intended for
> presentation".

That should read: "intended for publication".

Erik (and now I'm really over my quota)

Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] Open and recorded WMF Board meetings

2016-03-02 Thread Erik Moeller
2016-03-02 22:56 GMT-08:00 Chris Sherlock :

> Let’s have the Board meetings be recorded. If they cannot be recorded,
> then I’d like the WMF to improve their meeting minutes.

Jimmy made a couple of suggestions earlier [1], including to publish
all presentations given to the Board and to have a trusted community

To discuss which practices to adopt, it's worth first looking at the
existing Board manual, which is a remarkably detailed document that
goes into many of these issues including the exact process for minutes
publication, what types of information is captured in minutes, and so
on. [2]

When it comes to presentations, the manual primarily refers to
exceptions such as Legal presentations and documents "intended for

I would recommend clarifying the standards under which such decisions
are made, perhaps in the manual itself, and indeed publishing
presentations going forward. For instance, I think one can make
reasonable arguments either way when it comes to revenue related
presentations, but there should be a general approach.

Personally I would recommend transparency for those, as well, with
confidential business income and similar data being omitted if
necessary. "Competitive analysis" and the like is generally not the
kind of thing that WMF is good at doing secretly, and indeed many of
its risk analyses have been made public. Certainly all strategy
presentations should be public.

As for minutes, again, it seems to me a matter of first clarifying,
possibly in the Board manual, what level of detail is appropriate. It
seems to me that the Board is adhering to a relatively risk-averse,
conservative approach right now, whereas WMF staff (which make many
risky and potentially sensitive decisions on a day-to-day basis)
capture significantly more individual-level detail in quarterly review
minutes without apparent ill effect. I understand the concern about
"speaking freely", but I personally think this is overstated in many

The Board, being a governance body, _will_ often talk about sensitive
issues that cannot be captured in detail, such as personnel,
management and legal matters. But that doesn't mean it cannot adhere
to a greater level of detail in capturing strategy conversations, for



Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] I am going to San Francisco

2016-03-01 Thread Erik Moeller
2016-03-01 21:32 GMT-08:00 Andreas Kolbe :

> The gift from the Brin Wojcicki Foundation is of a little bit of interest,
> because its public announcement[3][5] came a mere three days after the
> Wikimedia Foundation said[9]

I see we're moving the goalposts back to an earlier conspiracy theory,
I guess that's success. The Brin Wojcicki Foundation actually made
their first gift to WMF in the 2010-11 fiscal year, just at a lower
level. [1] I was in the first meeting with them back in 2010, as well.
From everything I recall, they were a wonderful partner, and were
simply interested in supporting Wikimedia's existing activities and



Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] Open letter: Issues needing addressing by the Wikimedia Foundation's Board of Trustees

2016-03-01 Thread Erik Moeller
2016-02-29 23:19 GMT-08:00 David Emrany :

> so reading your email, we also recall these quotes from the time of the
> Stanton Foundation fiasco ? [1]
> "The Executive Director and Chief Revenue Officer agree that in the
> future, any grants that are not unrestricted will receive a special
> high level of scrutiny before being accepted."
> ..
> "The ED plans, with the C-level team, to develop a better process for
> staff to escalate and express concerns about any WMF activities that
> staff think may in tension with, or in violation of, community
> policies or best practices. It will take some time to develop a
> simple, robust process: we aim to have it done by 1 May 2014."

I'm not sure if there's a question for me here? I wasn't involved in
the Belfer project until the postmortem. The ED transition happened
shortly thereafter. Regardless of whether it came up in that context
(I don't know for sure, but I doubt it), the follow-up was lost in the
shuffle. Nemo pointed that out a few months later, and Lila's final
response on the issue is here:


Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] I am going to San Francisco

2016-02-29 Thread Erik Moeller
> Anne, I have mentioned several times in the past few days here on this list
> Sue Gardner's 2008 email suggesting that the WMF enter into an "umbrella
> relationship/agreement" or "business deal" with Google. In case you missed
> it, here is the link again:
> Scroll to the very end of the document to see the email in question. I am
> still interested in learning what the results of that effort were.

Nothing other than establishing some mutual points of contact, as far
as I know. Back in 2008, Sue and I reached out -- as WMF just had
relocated to the Bay Area -- to major tech companies to introduce
ourselves, with the help of Jimmy and some of our early supporters. We
made a pitch for donations, and in-kind hardware support where
appropriate. By and large corporate support didn't go very far,
because usually folks wanted PR benefits at a level we couldn't give
them. Some individual major donors did give their support, as noted on
the benefactors page.

Incidentally, this was also the year in which Google launched Knol,
which was sort of their version of the Knowledge Engine (official
line: "We have no intent of competing with Wikipedia" -> media
reports: "Google launches Wikipedia killer"). It was later converted
to a WordPress blog.

We did continue to cultivate the relationship with Google and
continued to ask for support, and eventually Google made a one-time
$2M donation. [1] As you know, Google also was one of the early
supporters of Wikidata [2], and Sergey Brin's family foundation has
also given to WMF in the past. [3] This was all unambiguously good for
Wikimedia, and is all public knowledge.

Beyond those donations, we've generally had an informal relationship
with changing points of contact over the years. WMF has given tech
talks at Google, for example, or our point of contact might help us
get some passes for the I/O conference. Part of the mandate of the
partnerships hire WMF made last year was to bring more of a systematic
approach to these relationships, and as the org stabilizes it might be
good to seek a broad conversation as to what that ideally should look
like in terms of transparency, lines we shall not cross, etc.

Generally speaking, when WMF did enter into significant business
relationships, these are a matter of the public record in press
releases and such: Yahoo back in 2005, Kaltura, PediaPress, Orange,
the various WP Zero operators, some data center partners, etc. The
Apple dictionary integration Brion mentions in [4] is an exception to
the rule; contrary to Brion's recollection it actually predates even
Sue Gardner and, as far as I know, was not announced at the time.



Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] Open letter: Issues needing addressing by the Wikimedia Foundation's Board of Trustees

2016-02-29 Thread Erik Moeller
2016-02-29 19:24 GMT-08:00 Chris Sherlock :

> With the greatest of respect, I'm not sure how could come to the conclusion 
> that general
> Internet search was not a core component of the Knowledge Engine.

It's important to remember that this is a $250K grant, with a grant
period that ends later this year. It's clear that this was done
because everyone involved realized that the plans are likely to
change. Knight has given grants to WMF in the past, including a $600K
one with a longer grant period [1], so this isn't a particularly bold
step for them or for WMF. Within the scope of a grant with these
parameters, it's completely reasonable for WMF, at the end of the
grant period, to go back to Knight and say: "We've done everything we
committed to for the grant period [improve internal search etc.], but
we won't be doing anything beyond that."

That is not to say that this process was managed well -- obviously it
wasn't. But at least there are no catastrophic long term consequences
for the organization or for the movement, as far as I can tell. That
is, unless Larry Page read one of the early news stories and decided
to send a DESTROY WIKIMEDIA memo to all Alphabet companies, in which
case I expect Boston Dynamics robots to show up at New Montgomery
Street any day now. [2]



Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] Open letter: Issues needing addressing by the Wikimedia Foundation's Board of Trustees

2016-02-27 Thread Erik Moeller

It's good to read you here and on WW. I think you're raising
legitimate points that others have also sought progress on. I would
just suggest one thing. Right now the Wikimedia Foundation is going
through an ED transition, impacting nearly 300 staff members most
immediately. The Board's primary responsibility at this point is to
identify interim leadership, set that person up for success, and renew
the Board's bridge to the staff. Painful as the situation with James
Heilman is, it is legitimate to address it later, in a professional
and civil manner.

I would encourage James, Jimmy, Denny and others similarly to not
shoot from the hip at this time. I know something about shooting from
the hip, and it rarely moves things forward positively. ;-) This
dispute may need a facilitator and a quiet, generous conversation to
be settled amicably. Given that Dariusz voted to retain James, I trust
James hasn't done anything so dastardly that this cannot be done.

Everyone has had an incredibly long week. I am sure
everyone--including Board members, who are all volunteers with other
obligations--is still stressed right now about what's to come. People
don't make the best decisions when they are too stressed, too tired,
too busy. It's important that the Board is given some space to focus,
to move forward one step at a time.

I concur with your call for greater transparency and involvement of
the Board in meaningful conversations with staff and volunteers. I
also think other steps of Board reform, including better training for
Board members, ought to be considered. I would love to hear more from
recently appointed Board members like Guy and Kelly, to understand
their perspective on the last few months. But all in due time.



Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] [Wikimedia Announcements] Executive transition planning

2016-02-25 Thread Erik Moeller
2016-02-25 12:19 GMT-08:00 Gayle Karen Young :
> I know this isn't easy - not on the Board, not on the senior staff, not on
> the staff, and not on Lila.
> I'm so sorry and sad for all of us where this has come to, and there is an
> enormous amount of goodwill and skill in supporting the board in moving
> forward and doing the thorough planning it needs to do from this point
> onward.

Well said, Gayle, and best wishes in the journey ahead, both for WMF
and the movement, and for Lila. I'll go back to lurking for a bit, but
may chime in on some of the topics that have been raised in some of
the very constructive side conversations.



Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] Why we changed

2016-02-22 Thread Erik Moeller
2016-02-22 1:26 GMT-08:00 Tim Starling :
> I don't think it is plausible, given the data collected at:
> 25,000 new users were put into an HHVM bucket, so the whole site was
> twice as fast for them. Then they were tracked for a week. There was
> no improvement in engagement or productivity.
> I'm sure the performance improvements we did in 2004-2005 had a big
> impact, especially initial batch of 9 Tampa servers in February 2004.
> There must be a scale effect: going from 20s to 10s is much more
> important than going from 2s to 1s.

I'm familiar with that research. I suggested at the time (see talk) to
specifically also evaluate impact on existing users. My reasoning was
that a new editor faces many barriers and high cognitive load, and as
you say, performance improvements at the level realized here are
probably not going to be the thing that helps you in making those
first edits. But if you're a power user who, say, performs a ton of
category edits with low cognitive load, reducing the amount of time
spent waiting ought to increase productivity.


Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] Post mortems (second attempt)

2016-02-22 Thread Erik Moeller
2016-02-22 1:14 GMT-08:00 Yaroslav M. Blanter :
> Absolutely. This is absolutely what happened. At some point I had to state
> that if FLOW gets introduced on all talk pages I would stop using talk
> pages. I was replied that they are sorry but this is my choice.

Our early communications approach about Flow was terrible, it is true,
and I take responsibility for not handling it better. I saw some
messages that made me cringe, but I didn't step in to say "This is not
how we want to do things". I'm sorry. As for my own comms style when I
was around the wikis, I think people have often found it arrogant and
thereby offputting. I've learned over the years that folks who are
external to the community are often naturally better at this. It's
tempting as a (formerly very active) community member to draw on your
own expertise and hopes to the point that you're no longer listening,
or seen to be listening.

I believe Flow-related communications improved significantly later on,
but by that time a lot of bridges had already been burned^Wnuked from
orbit. I think this early history significantly impacted perception
especially in the English Wikipedia community, to the point that
raising the name of the project immediately triggers lots of people in
that community. At the same time, the more proactive and careful
approach later fostered some use cases, like the Catalan Wikipedia
converting its entire Village Pump over:

I think a fair evaluation of the project's merits will need to look at
what actually happened in those communities that adopted it, whether
it's for wholesale usage on pages like this, or on user talk pages.
And if the numbers look positive and there's something that can be
done to heal the hurt that was caused in how the project was handled
early on, I'm happy to help if I can, even just by saying "Sorry".


Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] Why we changed

2016-02-22 Thread Erik Moeller
Hi Lila,

Thanks for the message. I won't go into this and the other aspects of
the current situation in detail -- I think this is an important
conversation primarily with current staff and active community members
--, but I'll respond to a couple points that I think are important,
and for which I can provide some historical perspective.

> In the past year we managed -- for the first time since 2007 -- to finally
> stem the editor decline.

This is a pretty powerful statement! As many folks know, "stemming the
editor decline" was long a top organizational priority, due to
research that showed an increasing tendency for new editors to
encounter barriers, such as the Editor Trends Study, summarized here:

Many will remember the graph illustrating this study, which
specifically underscores that new editors' 1-year retention decreasing
dramatically during Wikipedia's most rapid growth, and remained low
since then.

As a consequence, an important number to pay attention to when
characterizing the editor decline is the number of new editors who
successfully join the project. Has that number increased or

It has not, as far as I can tell:

Note in interpreting all data that January is a seasonal recovery
month in editor statistics.

One number to look at here is "New editors", which is the number of
editors who have crossed the threshold of 10 edits in a given month.
For all Wikipedias combined, this number has been in the 12000-13000s
for the last 6 months. Near as I can tell, the last time it has
hovered around or below those levels for this long was a decade ago,
in December 2005. The more modern metric of "new editor activation"
(which does not seem to have the same level of data-completeness)
appears to show similar troubling signs:,ruwiki,itwiki,dewiki,frwiki,enwiki,eswiki,jawiki/metrics=RollingNewActiveEditor

Another key metric we paid attention to is the "Active Editors"
number, which has stagnated for a long time; it appears to continue to
do so with no recovery. The most complete visualization I was able to
find is still the one we created years ago, here:

Finally, there's the measure of "very active editors". These are folks
who make 100 edits/month, and one could also call this the "core
community". It's a measure less affected by new user barriers, and
more by the effectiveness of existing editing/curation tools. This is
one metric which does indeed show a positive trend, as was noted here:

This graph focuses on English Wikipedia; this table contains the
numbers for all languages combined, in the "Very active editors"

The numbers for "very active editors" appear to have stabilized at a
slightly higher level than previously. I can't find any firm
conclusion on what has caused this in Wikimedia's public
communications, but the HHVM rollout, long-planned and implemented in
December 2014 under Ori Livneh's leadership seems like a plausible

It seems reasonable to assume that very active editors would most
benefit from performance improvements.

One very positive trend is the Content Translation tool, and its
impact on new article creation, especially in combination with
targeted calls to action, as detailed here:

But overall, it seems premature of speaking of "stemming the decline",
unless I'm missing something (entirely possible). I don't mean to be
negative about it -- I do think it's a super-important problem, and
hence important to be clear and precise about where we are in
addressing it.

> In practice this means I demanded that we set standards for staff
> communication with our community to be professional and respectful. It
> meant transitioning people, shutting down pet projects

Like Brion, I'm also curious what this ("pet projects") refers to.
With regard to tech, I'm not aware of any major projects that were
shut down. I read that major feature development on Flow was
suspended, but active maintenance work to support an active trial
(launched after said announcement) on user talk pages is ongoing, as
far as I can tell:,n,z

To be clear, the course of action taken here -- to evaluate a
controversial tool for a specific use case, and see how it fares --
seems completely reasonable to me. I'm just curious if that's what
you're referring to, though, or if there are other examples, perhaps
outside engineering, you have in mind?


Re: [Wikimedia-l] [Foundation-l] Single login - decision 2004

2015-04-22 Thread Erik Moeller
On Tue, Apr 21, 2015 at 11:34 PM, Keegan Peterzell wrote:

 This is now complete [2]. That wasn't too bad.

Nicely done. :-) Kudos to you, Kunal  everyone else involved in
finally bringing this one home.


Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] A transition and a new chapter.

2015-04-13 Thread Erik Moeller
Hi all --

As Lila noted, since January 2008 I've worn many hats at the Wikimedia
Foundation, and in the six years before that I was a Wikipedian,
MediaWiki developer, and member of the WMF board of trustees. I became
involved in Wikipedia when I was 22 years old. :) The Wikimedia
movement has accomplished amazing things, but I believe it's time now
for me to do something different and new.

It's been a long and incredible journey, and one I am privileged to
have helped to shape. When I joined the Foundation in December 2007 we
were a staff of a dozen people, with barely enough funds to keep the
lights on. Since then, we've tackled challenges of a complexity and
scale faced by few other organisations. In doing so, we’ve been
generously supported by people all over the world who are grateful for
the gift of free knowledge.

I’m proud of and happy with what we've achieved. Reaching people on
mobile. Pioneering new approaches working with universities.
Painstakingly building a visual editing experience on top of wikitext.
:) I’m glad we’ve taken a stand when it matters (SOPA blackout, NSA
lawsuit) and that we don’t shy away from complex issues such as
community health and diversity.

I’m excited that Wikidata is growing in leaps and bounds with the help
of Wikimedia Germany, and that more and more powerful tools and
services are being built on the basis of Wikimedia APIs and data. I’ve
always believed that Wikimedia chapter and affiliate organizations are
key to the success of the movement, and I hope they are going to truly
thrive in years to come.

But it's time. As the leadership team begins to coalesce under Lila, I
want to open up space for the organization to learn and explore anew
-- and I’d like to rediscover for myself what it means to tackle
challenges outside of my areas of comfort and familiarity.

I’m very interested in the technical challenges of federated
collaboration, and am looking forward to getting my hands dirty in
that domain. I also want to explore how to make patterns of ethics,
policy, and self-governance more accessible and re-usable for
communities. In short, I’m itching to immerse myself in new problem
spaces and new ideas.

Lila, Damon, Terry, myself and others in the org have been discussing
how to organize product going forward to set the org up for success in
the years to come, and we’ll have an update on that very soon. This is
a very natural point for me to pursue something new.

What Wikimedia does in the world is wonderful  important. I’m sure I
will continue to cross paths with many of you in future as I continue
to move in free culture circles, and I very much look forward to it.

I’ll continue to be @ WMF full-time through April, and will make
myself available as necessary afterwards, for when the org needs human
institutional memory that surpasses digital archives. I wish you all
success and joy :-)


Erik Möller
VP of Product  Strategy, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Wikimedia Deutschland's new Executive Director will be Christian Rickerts

2015-03-02 Thread Erik Moeller
Thanks for the update, Tim Moritz, and congratulations on a successful
search. Christian -- willkommen in der Wikimedia-Bewegung und viel
Erfolg! :-)

Erik Möller
VP of Product  Strategy, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Wikimedia OTRS Annual Report

2015-02-25 Thread Erik Moeller
Patrik and everyone else involved in this -- this is pretty amazing work.
Thanks for everything you do, and thank you for documenting it so clearly.
Erik Möller
VP of Product  Strategy, Wikimedia Foundation
Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] [Wikitech-l] Types of allowed projects for grant funding (renamed)

2015-02-21 Thread Erik Moeller
On Sat, Feb 21, 2015 at 4:19 PM, MZMcBride wrote:

 Erik seems to be pushing toward a model that favors using OAuth and the
 MediaWiki API over deep integration that comes with a MediaWiki
 extension. He recently mentioned this here:

 He may be right that development for deployment to the Wikimedia
 Foundation cluster may not be the best approach for every project, but I
 think this view overlooks all the very real benefits that extension
 deployment includes.

I don't think one size fits all -- every case needs to be judged on
its merits, though in the case of GLAMWikiToolset I am definitely
arguing for considering separation from the MediaWiki codebase because
it is so highly specialized. I also think we sometimes still have a
tendency to underestimate the value of non-MediaWiki tools and apps,
even though they've contributed millions of edits to Wikimedia wikis
already (though to be fair, without Magnus Manske the tally would not
be nearly as awesome).

Regarding the criteria for grantmaking, I think this initial blanket
prohibition against all MediaWiki extension development is indeed
something we ought to revisit. These grants can cover tens of
thousands of dollars of paid work, so we shouldn't treat the review
and integration burden lightly, and avoiding stalled projects that are
going nowhere was a reason I advocated for this restriction to begin
with. But as long as there is a good plan in place -- either not
significantly dependent on WMF or with clear commitments negotiated
upfront -- I do agree that the risks can be significantly mitigated.

Damon, Luis and members of their teams will need to weigh in on this,
and will want to think through the implications for their respective
areas, but it's a good conversation to have -- keeping in mind that
Luis is just starting in his new role, so please give him at least a
few days to get up to speed. ;-)

Erik Möller
VP of Product  Strategy, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] [Wikimania-l] Announcement regarding Host for Wikimania 2016

2015-01-20 Thread Erik Moeller
Kudos to the team and to the jury for daring to try something totally
new  exciting for Wikimania 2016 that sounds just a little bit crazy.
:D I am hugely looking forward to being part of this -- and I think
everyone who signs up to come will do so in the spirit of exploration
 adventure in which this bid is undertaken.

I've been to many conferences, offsites, retreats and what have you.
The ones that stick most in my mind are the ones that combined an
interesting environment, challenges to overcome, and lots of rich,
intimate conversations, woven together into an unforgettable
experience. It sounds like Wikimania 2016 will have plenty of all of
the above. :)


Wikimedia-l mailing list, guidelines at:

[Wikimedia-l] [Wikimedia Announcements] Fwd: Tilman Bayer joins Product Strategy Department

2015-01-07 Thread Erik Moeller
FYI :)

-- Forwarded message --
From: Erik Moeller
Date: Tue, Jan 6, 2015 at 1:50 PM
Subject: Tilman Bayer joins Product  Strategy Department
To: Staff All

Hi all,

It’s my pleasure to announce that Tilman Bayer is joining the Foundation’s
Product  Strategy department as Senior Analyst. I would like to thank
Katherine Maher for supporting and helping to prepare this move from the
Communications department.

Tilman has been working with us since July 2011, and has been a Wikipedian
since 2003. He is leading the development of the organization’s new
quarterly report, and its integration with the quarterly review process. In
his role in Communications, he has already coordinated our reports in their
previous monthly format, and has kept detailed public minutes for the
majority of quarterly reviews at WMF. He will continue to do so.

He will ensure we not only continually refine and improve the quarterly
goalsetting, review and reporting processes, but can also look for
opportunities to highlight lessons learned - successes and failures -
across the organization and the Wikimedia communities, so these can
meaningfully inform our strategy.

In addition, Tilman will bring his many years of experience as a volunteer
and his insight into the many complexities and intricacies of the Wikimedia
universe to bear with product-related research and analysis questions,
supporting Product Managers and other team members as we dig into hard
problems that benefit from his expertise, e.g. simplification of templates,
translation tools, cross-wiki messaging tools, mathematics editing, etc.

Tilman was previously responsible for many day-to-day communications
responsibilities and supported or led key communications initiatives. These
responsibilities will be transitioned to other Communications team members,
including Fabrice Florin who is joining the team for 6 months (separate
announcement to follow).

Please join me in congratulating Tilman to this new role. Tilman - thank
you for taking this on; I look forward to continuing our work together!


Erik Möller
VP of Product  Strategy, Wikimedia Foundation

Erik Möller
VP of Product  Strategy, Wikimedia Foundation
Please note: all replies sent to this mailing list will be immediately directed 
to Wikimedia-l, the public mailing list of the Wikimedia community. For more 
information about Wikimedia-l:
WikimediaAnnounce-l mailing list
Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] WaPo Wikipedia's 'complicated; relationship with net neutrality

2014-12-08 Thread Erik Moeller
On Mon, Dec 8, 2014 at 8:35 PM, Jens Best wrote:

 Wikipedia Zero should be newly framed as a leading example of Public
 Free Knowledge.

Hey Jens,

I think your line of argument here is reasonable, and we are generally
thinking in the direction of how Wikipedia can be part of a broader
coalition dedicated to free access to knowledge. Wikipedia Zero
started off as an experiment to bring Wikipedia to millions of people
who could otherwise not afford it. But now we should think (and are
thinking) about the kind of coalition we want to create to bring free
knowledge to every person on the planet, rather than primarily
advocating for free access to Wikipedia.

I'd be indeed curious about your thoughts on how to define Public Free
Knowledge. IMO the licensing status of the material ought to play some
role in defining what kinds of resources should be made freely
available in this manner. I don't know that this should be an
absolutely non-negotiable criterion (even Wikimedia makes exceptions),
but it should count for something.

Freely licensed material (in a manner compatible with the Definition
of Free Cultural Works or the Open Knowledge Definition) is not tied
to a specific website and host; the ability to fork free knowledge is
a fundamental protection against the misuse of power. Moreover, if
society creates a social contract that freely licensed and public
domain information should be available free of charge, this creates
further incentives to contribute to a true commons. It protects our
heritage and reminds us to expand it. This is a position entirely
consistent with our mission, as well.

I agree with Mike that WMF needs to take a practical stance to bring
free knowledge to the largest number of people, and we need not
apologize for Wikipedia Zero -- it's a program that serves the
organization's mission well. But entirely practically speaking,
building a greater coalition in support of access to knowledge could
serve the mission to an even greater extent, if we manage to pull it

Imagine a world where you can take a smartphone or tablet without a
contract and immediately connect to an ever-growing library of free
knowledge, without charge. I couldn't think of a better 21st century
equivalent to the foundation of public libraries, and frankly of a
better way to even the odds for the survival of our species.


Erik Möller
VP of Product  Strategy, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Fundraising banner interfering with Google results

2014-12-07 Thread Erik Moeller
Hi all,

For the record, we've been able to confirm that our fixes, which were
already deployed Thursday, immediately addressed the issue on our end.
Google also picked up the updated robots.txt already on December 4,
according to Google Webmaster Tools. GoogleBot, for better or for
worse, nowadays executes JavaScript, which caused it to index the
banner text since the JS was not blacklisted prior to December 4.
We've pinged our Google contacts about faster re-crawling of impacted
pages; will follow up further on that front.

Erik Möller
VP of Product  Strategy, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Fundraising banner interfering with Google results

2014-12-07 Thread Erik Moeller
On Sun, Dec 7, 2014 at 2:10 PM, Russavia wrote:

 I can confirm that my edit to
 has now fixed the issue in Google search as it relates to that article, but
 the issue still remains on 8,600,000 articles (up from 8,540,000 articles
 yesterday). Dear Wikipedia readers produces 936,000 results
for me. Please note that Google uses a distributed index, and
depending where you are geographically, and where Google sends you
based on server load, you will get inconsistent results from query to
query. See this paper for a bit more detail on how these index
inconsistencies manifest:

Pages we know to have been re-crawled don't exhibit the issue, so it
should be only a matter of time for the index to catch up. Please also
note that the text being in the index does not automatically mean that
it will show up in a typical search. Any search for the phrase itself
will highlight it in the snippet (extract) shown in the search result
page as a match, while a typical search will not include the phrase
and will much less frequently identify the text to be a good match for
the user's search query, mitigating global user impact significantly.
We'd still like to resolve this completely as quickly as possible, of

Erik Möller
VP of Product  Strategy, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Fundraising banners (again)

2014-12-05 Thread Erik Moeller
On Fri, Dec 5, 2014 at 12:29 AM, Michel Vuijlsteke wrote:
 I think it's more than worrying that many of the results have the
 fundraising message as a summary.

Yep, this is very problematic. Even though the content is
JavaScript-generated, Google crawls it unless it's explicitly
excluded. This came to our attention this morning SF time, and we
quickly deployed fixes on our end:

This should fix the issue, but Google will need to recrawl the
affected pages. We've already reached out to our contacts there to see
if this can be done more quickly. Further background and analysis


Erik Möller
VP of Product  Strategy, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Au Revoir from WMUK CEO

2014-11-12 Thread Erik Moeller
Jon --

Thank you all the hard work for the movement, and for building a great team
and great foundations!  Hope to see you in different corners of the
movement  globe.

Erik Möller
VP of Product  Strategy, Wikimedia Foundation
Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Chapters and GLAM tooling

2014-11-10 Thread Erik Moeller
On Sat, Oct 25, 2014 at 5:58 PM, Erik Moeller wrote:
 Indeed, highly specialized tools for the cultural and education sector
 _are_ being developed and hosted inside Tool Labs or externally.
 Looking at the current OAuth consumer requests [5], there are
 submissions for a metadata editor developed by librarians at the
 University of Miami Libraries in Coral Gables, Florida, and an
 assignment creation wizard developed by the Wiki Education Foundation.

The Wiki Education Foundation just introduced its Assignment Wizard,
which is being developed with the help of an outside agency. As this
tool develops, there may be opportunities for sharing experiences with
other Wikimedia organizations:


Erik Möller
VP of Product  Strategy, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

[Wikimedia-l] Update regarding WMF's reporting practices

2014-11-05 Thread Erik Moeller
Hi all --

Starting this month, WMF will be shifting its organization-wide
reports from a monthly to a quarterly cadence. This reflects our
growth as an organization, and is intended to make important
developments more visible internally and externally.

== Background ==

Shortly after Sue became WMF’s Executive Director, she started giving
updates to the Board of Trustees about her work. These reports were
compiled for accountability purposes, and not without some
trepidation, Sue started sharing them publicly in January 2008. [1]
The reports have grown in scope and depth alongside the organization.

Where we think we can do better is in the following areas:

- We've not defined the threshold for report-worthy work clearly
enough, so work that represents a few person hours’ effort could get
more space than a whole team’s work over the course of the quarter;

- We've not consistently mapped reporting against organizational priorities;

- We’re not presenting a strategic view on what we’re learning, where
we’re changing direction and why;

- We’re not helping users of the reports consistently discover
quarterly review minutes, slides and other materials related to a
specific area, in part due to the reports not being aligned with the
quarterly rhythm.

In addition, given the dependency on an increasing multitude of inputs
(from across an organization that had fewer than 20 staff when these
monthly reports were launched, and now has more than 200), the reports
have increasingly gotten backlogged, to the point that we’re just now
releasing the August report.

At the same time, under Lila the organization has shifted into a
recognizable quarterly rhythm. Priorities are defined quarterly, and
reviews are being introduced following the end of each quarter for all
significantly staffed projects.

== A New Reporting Process ==

It’s come time for us to revisit the model we use for reporting, to
clearly define the purpose/audience for these report, and to iterate
on the monthly format.

Purpose: The purpose of this report is accountability and learning
within the movement. The report is not a storytelling tool. Any
evaluation will be done with these objectives in mind.

Audience: Its audience is chiefly internal, including community
members, WMF staff, and interested donors/funders.

Format: Effective immediately, we are shifting to a quarterly
reporting format. This will impact our reporting, and the October
through December reporting period, in the following ways:

- Instead of three monthly reports for October, November, and
December, we will publish our first quarterly report in February 2015.

- We are reviewing the key organization-wide metrics and will improve
the selection and presentation of numbers at the top level of the
quarterly report.

- We will closely align quarterly reports with quarterly reviews, and
re-use high level findings from the quarterly reviews, while referring
to the slide decks and minutes from the reviews for details.

- We will aim to provide high-level synthesis and lessons learned, as
well as strategy updates, through this format as well.

Many of the more granular updates in the monthly report will no longer
be reported.

As above, the deadline for publication of the first report, covering
October 1 - December 31, is February 15. For this first report, we are
being conservative with regard to the deadline, as we will have our
resources directed at our staff all-hands and developer summit in

Tilman and I will begin creating a draft structure for this new report
in coming weeks, and will do so in public from the get-go. We will
also rethink the “Wikimedia Highlights” alongside other multilingual
movements news formats, likely detaching them from reporting

Out of scope of this effort for now:

- Providing more timely updates on initiatives with high user impact.
We’re continuing to provide updates to Tech News [2] and similar
newsletters, but we’re not currently doing a major overhaul here.

- Replacing the monthly engineering report and its inputs, which also
serve as a project status dashboard. [3]

We are of course discussing how to improve on those mechanisms, and
feedback is welcome.

Let me know if you have any immediate questions or thoughts.



Erik Möller
VP of Product  Strategy, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Chapters and GLAM tooling

2014-10-25 Thread Erik Moeller
On Sat, Oct 25, 2014 at 7:16 AM, MZMcBride wrote:

 Labs is a playground and Galleries, Libraries, Archives, and Museums are
 serious enough to warrant a proper investment of resources, in my view.
 Magnus and many others develop magnificent tools, but my sense is that
 they're largely proofs of concept, not final implementations.

Far from being treated as mere proofs of concept, Magnus' GLAM tools
[1] have been used to measure and report success in the context of
project grant and annual plan proposals and reports, ongoing project
performance measurements, blog posts and press releases, etc. Daniel
Mietchen has, to my knowledge, been the main person doing any
systematic auditing or verification of the reports generated by these
tools, and results can be found in his tool testing reports, the last
one of which is unfortunately more than a year old. [2]

Integration with MediaWiki should IMO not be viewed as a runway that
all useful developments must be pushed towards. Rather, we should seek
to establish clearer criteria by which to decide that functionality
benefits from this level of integration, to such an extent that it
justifies the cost. Functionality that is not integrated in this
manner should, then, not be dismissed as proofs of concept but
rather judged on its own merits.

GWToolset [3] is a good example. It was built as a MediaWiki extension
to manage GLAM batch uploads, but we should not regard this decision
as sacrosanct, or the only correct way to develop this kind of
functionality. The functionality it provides is of highly specialized
interest, and indeed, the number of potential users to-date is 47
according to [4], most of whom have not performed significant uploads
yet.  Its user interface is highly specialized and special permissions
+ detailed instructions are required to use it. At the same time, it
has been used to upload 322,911 files overall, an amazing number even
without going into the quality and value of the individual

So, why does it need to be a MediaWiki extension at all? When
development began in 2012, OAuth support in MediaWiki did not exist,
so it was impossible for an external tool (then running on toolserver)
to manage an upload on the user's behalf without asking for the user's
password, which would have been in violation of policy. But today, we
have other options. It's possible that storage requirements or other
specific desired integration points would make it impossible to create
this as a Tool Labs tool -- but if we created the same tool today, we
should carefully consider that.

Indeed, highly specialized tools for the cultural and education sector
_are_ being developed and hosted inside Tool Labs or externally.
Looking at the current OAuth consumer requests [5], there are
submissions for a metadata editor developed by librarians at the
University of Miami Libraries in Coral Gables, Florida, and an
assignment creation wizard developed by the Wiki Education Foundation.
There's nothing improper about that, as Marc-André pointed out.

As noted before, for tools like the ones used for GLAM reporting to
get better, WMF has its role to play in providing more datasets and
improved infrastructure. But there's nothing inherent in the
development of those tools that forces them to live in production
land, or that requires large development teams to move them forward.
Auditing of numbers, improved scheduling/queuing of database requests,
optimization of API calls and DB queries; all of this can be done by
individual contributors, making this suitable work for even chapters
with limited experience managing technical projects to take on.

On the analytics side, we're well aware that many users have asked for
better access to the pageview data, either through MariaDB, or through
a dedicated API. We have now said for some time that our focus is on
modernizing the infrastructure for log analysis and collection,
because the numbers collected by the old webstatscollector code were
incomplete, and the infrastructure subject to frequent packet loss
issues. In addition, our ability to meet additional requirements on
the basis of simple pageview aggregation code was inherently

To this end, we have put into production use infrastructure to collect
and analyze site traffic using Kafka/Hadoop/Hive. At our scale, this
has been a tremendously complex infrastructure project which has
included custom development such as varnishkafka [6]. While it's taken
longer than we've wanted, this new infrastructure is being used to
generate a public page count dataset as of this month, including
article-level mobile traffic for the first time [7]. Using
Hadoop/Hive, we'll be able to compile many more specialized reports,
and this is only just beginning.

Giving community developers better access to this data needs to be
prioritized relative to other ongoing analytics work, including but
not limited to:

- Continued development and maintenance of the above 

Re: [Wikimedia-l] Chapters and GLAM tooling

2014-10-24 Thread Erik Moeller
Just pinging this thread -- looking through all the proposals for
annual plan grants:

I'm not seeing any developer contract time allocated to GLAM tooling
work yet. At the same time I'm seeing reports of breakage and missing
functionality in important tools running in Labs. To the extent that
this breakage is due to Labs infrastructure or access to data, it's
our job (WMF) to fix it and you should (continue to) poke us to do so
-- but to the extent that it can be addressed in the tools themselves,
I'd love to see chapters take this on directly. It's possible that I'm
missing something. Are there more concrete plans at this point in time
to help support the tools developed by Magnus and others, and create
new reports on an as-needed basis? Having a dedicated staff person in
chapters or an affilicate like Europeana who WMF analytics can partner
with would be really helpful for keeping this moving, in my view.


Erik Möller
VP of Product  Strategy, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Android Nearby Feature (was: Re: Community RfCs about MediaViewer)

2014-10-14 Thread Erik Moeller
On Tue, Aug 5, 2014 at 7:28 PM, Andy Mabbett wrote:
 An answer would be appreciated...

I know you've been in touch w/ the mobile web team since this thread,
but just to close the loop for the record: Nearby (now
re-implemented in native code and with a new UI) is part of today's
stable release of the Android app.

Please join the mobile list for feedback, questions  suggestions.

Erik Möller
VP of Product  Strategy, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

[Wikimedia-l] [Wikimedia Announcements] Announcing Guillaume Paumier as Senior Analyst / SF relo

2014-10-07 Thread Erik Moeller
FYI - belatedly forwarding after internal announcement:

- - -

Hi folks,

Guillaume Paumier has been Technical Communications Manager in the
Engineering Community Team since early 2011. In this role, he's been
instrumental in developing the monthly engineering reports (including
all the underlying infrastructure on, vetting and
writing technical blog posts and social media updates, and most
recently, co-launching the weekly tech newsletter and keeping it

Guillaume's role is changing, and he will shift to my department as
part of the Engineering/Product department division. He will report
directly to me as Senior Analyst, and I will deploy him to projects of
strategic importance that require his expertise (any Guillaume
deployments will not be noted on the deployments calendar). Guillaume
will continue to put some of his time towards the tech newsletters and
reports for the time being (though we're considering to merge the
two), but other communications responsibilities will be handled by
Katherine's team.

What does it mean to be a Senior Analyst? As a long-time Wikimedian
(since 2005), Guillaume understands many of Wikimedia's workflows
deeply. As a self-confessed OCD introvert, he loves documenting,
analyzing; breaking apart things and putting them back together in
novel ways. He's awesome at information architecture, and at really
thinking through all the options to solve a complex product problem.

In other words, when I see a product that benefits from deep community
expertise, I can throw Guillaume at it and he'll help. :)

The first project Guillaume is taking on in this new role is the file
metadata cleanup drive, preparatory to the Structured Data work the
multimedia team will focus on in coming months. You can read more
about it here:

Finally, it's my pleasure to announce that Guillaume is also
relocating (back!) to the San Francisco Bay Area.  Please join me in
congratulating Guillaume in this new role and wishing him a
stress-free move to San Francisco.


Erik Möller
VP of Product  Strategy, Wikimedia Foundation

Please note: all replies sent to this mailing list will be immediately directed 
to Wikimedia-l, the public mailing list of the Wikimedia community. For more 
information about Wikimedia-l:
WikimediaAnnounce-l mailing list
Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Damon Sicore joins WMF as Vice President of Engineering

2014-09-29 Thread Erik Moeller
On Mon, Sep 29, 2014 at 7:10 PM, MZMcBride wrote:


 What's the timeline for re-organizing the current Engineering and Product
 Development group? End of 2014, the first quarter of 2015, sooner, later?

Damon is in charge of the following areas as of today, and handover is underway:
- Platform Engineering
- Features Engineering
- Language Engineering
- Mobile Engineering
- Technical Operations
- Team Practices Group

I'll continue to be responsible for the following groups:
- Product Management
- User Experience
- Analytics
- Community Engagement
- Wikipedia Zero (minus the engineering part, which lives in Mobile Engineering)

These changes will be reflected on the staff page shortly. Needless to
say we are providing support in transitioning approvals, hiring
pipelines, and other day-to-day management responsibilities.

As noted before, Analytics is a bit of an odd fit in either group,
since it includes both engineers and data analysts, and we'll continue
talking about what makes sense here, but it needs to be closely
aligned with product management which is why it's in my group at this

Any growing org structure needs some tweaking over time. There's been
a fair bit of internal discussion already about the best future org
structure for these internal groups in particular:
Platform/Features/Language/Mobile. There are some felt pain points in
the current division of engineering responsibilities through those
groupings (in particular, some of the silo effects that it creates).
Discussions about how to improve the org structure will continue under
Damon's leadership, and it'll be up to him to set the timetable for
any changes he wants to make.


Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Invitation to WMF September 2014 Metrics Activities Meeting: Thursday, October 2, 18:00 UTC

2014-09-29 Thread Erik Moeller
On Sun, Sep 28, 2014 at 11:41 AM, Pine W wrote:
 Thanks Praveena. For future meetings, could you set up a place on Meta
 where people can make requests and suggestions for presentation topics?

Please post any such requests/suggestions on the talk page for the
pending meeting, e.g.:

Re: analytics, this week's meeting will feature an update on the new
vital signs dashboard the team has been working on. The minutes and
slides for the most recent Analytics quarterly review (which took
place last week) will be posted soon and include details on other
recent work, including progress towards better readership metrics on
mobile and desktop.

Erik Möller
VP of Product  Strategy, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] [Wikitech-ambassadors] Invitation to beta-test HHVM

2014-09-18 Thread Erik Moeller
Ori and ...

 Aaron Schulz, Alexandros Kosiaris, Brad Jorsch, Brandon Black, Brett
 Simmers, Bryan Davis, Chad Horohoe, Chris Steipp, Erik Bernhardson,
 Faidon Liambotis, Filippo Giunchedi, Giuseppe Lavagetto, Greg
 Grossmeier, Jack McBarn, Katie Filbert, Kunal Mehta, Mark Bergsma, Max
 Semenik, Niklas Laxström, Rob Lanphier, and Tim Starling.

.. amazing work, everyone. This is a huge milestone and it's wonderful
to see the finish line come closer. Making and keeping our sites fast
is hugely important, and all evidence so far suggests that HHVM will
be one of the biggest gains ever. :)

Please, do help spread the word and give it a spin, as we iron out
remaining issues.


Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] To Flow or not to Flow

2014-09-09 Thread Erik Moeller
On Mon, Sep 8, 2014 at 12:22 AM, David Gerard wrote:
 On 8 September 2014 05:46, John Mark Vandenberg wrote:
 Those of us who presently use talk pages to get the work done. What is
 going to make us *love* Flow, for all its imperfections, and demand to
 have it for ourselves? What's Flow's killer feature for us?

First, on the subject of kiler features, generally - we can make
educated guesses, but with software that's used by communities, you
really need to experiment and iterate. I'm sure we'll try stuff in
Flow that doesn't make sense (and we've already talked here about
aspects of the current design that may have to be changed, like the
limited threading display), and I'm sure things we think are minor
will become more popular than we expect.

Generally, I'm not a big fan of maintaining illusions of certainty.
I've argued against detailed year-long plans to Sue and the Board, as
I'm sure they will attest, until we got the flexibility to set more
malleable goals in engineering. Lila immediately came in with the
expectation in mind that we'd have precision a quarter out, and broad
high level ideas a year out, and need flexibility to change our mind
as we learn. In tech work, you need to be able to double down on
success when you hit it (make that killer feature _the_ feature), and
kill the cruft that you thought was smart but that just doesn't work.

With Echo, we included a bunch of notification types and didn't really
know which ones people would love. We guessed that mentions would
become popular, but their use has exceeded our wildest expectations.
Go to any high traffic talk page and you'll see Echo pings all over
the place. A feature that didn't exist before 2013 and that nobody, as
far as I know, ever asked for (!) before we built it. And yet it's
become indispensable.

When we experimented with mobile contributions, our first hypothesis
was that uploads would be a good start, because mobile isn't
well-suited for long form edit contributions. In fact, mobile editing
became wildly popular very quickly and has generally been embraced by
the community (to the point where people ask us to enable IP editing
on mobile, which we consciously did not do initially to lessen crappy
edits), while the signal to noise ratio on uploads has been so poor
that we're about to retire most upload features until we really can
spend cycles on mitigating those risks.

So, educated guesses and hypotheses.

Flow makes lots of things possible that are otherwise hard/impossible
(much better search, tracking of comments, etc.) but my hypothesis is
that there are three primary killer features that Flow can provide:

1) Fast interactions. The process of responding on a talk page is
ridiculously slow (edit section, find place, indent comment, write
comment, sign comment, preview, save, worry about edit conflict ..).

In my view, the reason people don't value this in Flow such-as-it-is
already is primarily [[loss aversion]]. There's a large set of
concerns that Flow makes existing things impossible (and yes, I'll
respond a bit more to Diego) or harder. Losses are psychologically far
more powerful than gains -- so any cool comment features that Flow
_already has_ (fast and easy replies, no edit conflicts, etc) will not
be perceived to be killer features unless/until the balance of
perceived losses shrinks dramatically from what it is now. And it'll
keep shrinking as we go.

As pointed out, we can _try_ to make this work with sticks, spit and
duct tape on top of wikitext, even in the odd cases of mixed markup
for indentation, comments interrupted in the middle, outdent
templates, etc. -- but it'll almost certainly just have to bail in
some cases, and misidentify comment demarcations in others. I'd like
to test those boundaries a bit more before making confident statements
about how much of fast interactions we can deliver without Flow,
however. Either way, it is IMO a clear killer feature that's badly

2) Centralized conversation spaces. Flow's architecture is already
cross-wiki; its UI is not. As pointed out, there are multiple
cross-wiki discussions as well as mailing list discussions about this
very topic. Wil suggested Pick a conversation space and stick to
it!. Well, wouldn't that be nice - if it worked in our universe.
Except that we know it rarely does. People want to have discussions in
their home wiki, and we use mailing list threads like this for good
reasons as well.

You could participate in the same Flow conversation from en.wp, and meta, without caring one way or another (SUL
finalization being the main blocker to avoid account wonkiness).
When/where that's desirable is something to negotiate -- but for
example, feedback on features that are deployed across wikis is a
perfect case for wanting to have local pages that feed into a single
stream of comments.

If you want to go nuts, you could build a Flow-mailing list or
Flow-NNTP (oldschool!) gateway. If we do 

Re: [Wikimedia-l] Feedback with Android on Commons

2014-09-08 Thread Erik Moeller

The Commons app would need lots of love to continue to be worth advertising
as a mainline app. It's not been updated since October, and code rot sets
in after a while (I can easily reproduce crashes when logging in with an
account  that has pre-existing uploads, which it tries to display for
convenience but quickly chokes on). With the small app team we have, our
focus is mainly on the official Wikipedia apps right now, which are already
quite solid and receiving very positive reviews, esp. the Android app. [1]
The team is discussing whether the Commons app should be sunset (which
would still leave open the option of community maintainership) based on the
numbers, and will be posting an update later this week.



Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] To Flow or not to Flow - it does not flow

2014-09-08 Thread Erik Moeller
On Sat, Sep 6, 2014 at 3:33 PM, Erik Moeller wrote:

 As I wrote to Risker, I think it's worth considering spending some
 development time on turning something like the Teahouse gadget (which
 allows one click insertion of replies on the Teahouse Q/A page) into a
 Beta Feature after some further improvement, to see just how useful it
 could be for the common case. If there's an 80/20 rule and in 20% of
 cases it just gives up and edits the section, that might still be a
 time-saver and convenience. There might even be other relevant gadgets
 already in some languages/projects -- worth a closer look, for sure.

I'm talking about this with the Flow team, but I also want to be
conscious of their focus and energy. One possibility is to contract
this out to an individual dev to test out the boundaries of what can
be done in JavaScript alone -- and make recommendations for any
mediawiki/core changes that could help. Since a JS opt-in script can
be quickly developed by anyone with talent and motivation there's
really no barrier to trying this.

If anyone's reading feels they're qualified to take this on and would
be interested doing it on a contract, drop me a line offlist.
Obviously it's also a great opportunity for volunteer experimentation,
as well. I think at this stage we should consider this a research

There is some pre-existing work on this, beyond the Teahouse gadget.

- Mobile web has a very experimental reply feature on talk pages
right now. It doesn't handle the indentation levels, as far as I can
tell - it just inserts a new top-level comment. You can turn this on
by 1) enabling beta, 2) enabling alpha, 3) logging in, 4) going to a
talk page, 5) going to a section. That's a lot of steps, but since
it's so experimental that's probably for the best :-)

- Gabriel Wicke has done some experimentation with this as well, and
is looking if he can dig up the old code for me.

If others are aware of relevant hacks/gadgets/user srcipts, please let me know.


Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] To Flow or not to Flow - it does not flow

2014-09-08 Thread Erik Moeller
On Mon, Sep 8, 2014 at 6:47 PM, Erik Moeller wrote:

 - Gabriel Wicke has done some experimentation with this as well, and
 is looking if he can dig up the old code for me.

Very old indeed, but if anyone wants to take a look:

Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

2014-09-06 Thread Erik Moeller
On Fri, Sep 5, 2014 at 10:42 PM, Risker wrote:
 The major deficiencies that have long been identified in the current
 discussion system (and that can be addressed by technology) are all able to
 be addressed in MediaWiki software or by extensions. Automatic signatures
 have been done by bots for years; indenting could be added to the editing
 function gadget and moved to an extension; much work has already been done
 on graceful resolution of edit conflicts.  The ability to watchlist an
 individual thread or section of a page is more challenging but, I have been
 told, still possible.

Let's just acknowledge that the limitations of what can reasonably be
layered onto wikitext-based representation of comments have not been
fully explored, rather than jumping to conclusions about what's easy
to address and what's hard. As noted separately, I agree it may be
worth pushing the boundaries a bit more on this, if only to know
exactly where they are, and to achieve short term improvements.

 Automatic signature (something that is currently
 functional on Flow, but is not customizable) turns out to be more of a
 challenge when users are widely known by a signature line that doesn't
 match their username,

I've not talked to them about it explicitly, but I'd guess that the PM
and the UX folks have a negative aversion against custom signatures
because of their free-form nature (including sometimes
layout-exploding ones). Perhaps a middle-ground can be found here,
with some more sanitization applied to prevent some of the
sigs-from-hell occasionally found. Other than that I can't see a good
reason to not just show them when they're set, and it's certainly
technically trivial to do so.

 and there is no method by which users can add an
 explanatory note to their signature such as formerly known as

From the point forward that Flow is in wide use, a user rename would
be automatically reflected in old comments if desired, much as it is
reflected in old edits. But if signatures were supported, as above,
you could still use them for these types of indicators, as well.

 The more efficient indenting has reduced possible
 indents to three levels, without exception;

This seems to be the most religious topic when it comes to Flow. The
database stores all threading information. It'd be trivial to expand
the threading level if that's more popular and usable.

I've heard the argument that this doesn't work on mobile, but we could
just set a different threading level on mobile.

I think it's worth experimenting with flat pages (with quoting) for
certain purposes, and Danny wants to, but it strikes me as most
reasonable to start with something that more closely resembles talk
pages as they are now (which is why we did that with LQT originally).

 Rigid predictable technical
 restrictions on who can edit what has resulted in inability to remove
 posts that are obviously unsuitable (there's no undo or revert
 function), replaced with a hide function that can only be applied by
 certain users that's practically a red flag for people to look-see what the
 problem edit is.

The team has pretty strong arguments why they don't want posts to be
editable (the gist is, they fear that no other discussion system does
this, and it will freak people out -- they see the introduction of a
new system as a good opportunity to reset expectations). I personaly
am not religious about it; when we built LQT we made posts editable
(and made it clear who had edited someone else's posts) to preserve
that normal aspect of wiki-style editing. I think we should keep
talking about this.

I've not seen it named as a dealbreaker for small scale deployments.
The architecture can easily support both models.

 At the core is whether or not there is value in developing a discussion
 system that is radically divorced from any other interface used by the

That's a legitimate question, although it's not as radically
divorced as you would think; ultimately it'll use the VisualEditor
(probably with a simplified toolbar by default) just like Flow does.

As for the claim that the team never looked at current use cases,
having spent hours in rooms with them where they pored over printouts
of hundreds of talk pages, analyzed use cases, categorized them,
prioritized them, etc., I can assure you there's been a lot more of
this kind of thinking than you appreciate. There also have been round
tables and other outreach efforts, and a dedicated community liaison
from the start. Still, I don't think there's been enough talking to
each other -- we're still getting better at doing that, collectively,
and trusting in the value of conversation even when there's a lot of
noise and a lot of heat.

This is an opportunity for me to remind folks that the cost of heat
(accusations, insults, reverts, etc.) is that people withdraw. We
(WMF) have to do our part to prevent things from getting heated, but
I'd ask folks who notice this kind of thing 

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

2014-09-06 Thread Erik Moeller
On Fri, Sep 5, 2014 at 11:13 PM, Erik Moeller wrote:

 That's a legitimate question, although it's not as radically
 divorced as you would think; ultimately it'll use the VisualEditor
 (probably with a simplified toolbar by default) just like Flow does.

.. just like article editing, I mean - you'll have a choice between
VE/wikitext, probably with a toolbar that's optimized for comments
(perhaps advanced tools available when needed).

Moreover, I think the idea that talk pages are actually an intuitive
system once you're familiar with editing articles is both unproven and
contradicted by all user research into article editing and talk pages.
Users discover wikitext incrementally, and they understand it to be
kind of like HTML. They think of it as a document formatting

When they first discover talk pages, they have to learn a whole new
set of conventions -- the notion of signing and indenting your own
comments, the idea that in order to participate in a thread you have
to edit it, etc. That is a system divorced from editing, and it's a
mental model unlike any other discussion system.

The argument would be more supportable if you could layer a decent UI
on top of wikitext-based talk pages, as you suggest. But if you can do
that, you'll end up with a UI that introduces many of the same
conventions that Flow introduces, just with a hard limitation on some
of the additional capabilities and conveniences you can introduce. It
may be, as I acknowledged, still worth doing - even as an interim step
towards Flow.

Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Upload Wizard work (was Re: Next steps regarding WMF-community disputes about deployments)

2014-09-06 Thread Erik Moeller
On Fri, Sep 5, 2014 at 11:35 PM, Yann Forget wrote:

 2014-09-04 12:34 GMT+05:30 Erik Moeller
 On Sun, Aug 31, 2014 at 8:59 AM, Yann Forget wrote:
 the most urgent and important thing is to fix the

 This is indeed underway, and has been for some time, with focus on bug
 fixes and code quality improvements.,n,z

 Recent work on Media Viewer has been primarily UX prototyping and

 I suppose you mean the UploadWizard?

No, I meant that we've done a bunch of work in parallel in August:

- Pau Giner, Abbey Ripstra and Fabrice Florin have primarily focused
on prototyping and validating a bunch of changes to media viewer, with
some help from the dev team. The changes that have tested well are now
being implemented very rapidly.

- The multimedia dev team has spent a fair bit of time doing some
initial UploadWizard refactoring and code cleanup. We've also
contracted Neil Kandalgaonkar, the original UploadWizard developer
(who left WMF a while ago), to help out a bit and provide some history
on the project.

- In addition, the dev team has focused a fair bit on improved
instrumentation (measurement of user actions, success/failures), both
for Media Viewer and Upload Wizard.

Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

2014-09-06 Thread Erik Moeller
On Fri, Sep 5, 2014 at 11:41 PM, Pine W wrote:
 Something that that would be useful is a video demonstration of Flow in

That could be handy, Pine. But sometimes you can't demonstrate all
benefits yet, because they don't even exist in the implementation yet
-- only in the foundations of an architecture. And sometimes you can
show the idea of a benefit, but people will look at the current
implementation and hate some aspect of it, and fail to imagine a
version of it that would be beneficial.

To give an example of the latter, Flow already has the ability to give
thread-level notifications of responses. But the first implementation
of notifications was very spammy (generated too many notifications),
so people who looked at it said I don't see the benefit! It's just
spammy!. Love em or hate em, sites like Facebook spend years tweaking
the algorithm for every one of their features (newsfeed,
notifications, etc.) to get the best results from their perspective.
It takes time to get this right -- and the initial reaction may often
be No, this sucks because, well, it's not quite right yet.

Fundamentally, I'd ask people to relax a bit regarding Flow. Nobody's
planning to push this one out radically. Today we saw some on-wiki
drama because a new test page was turned on. For something like the
en.wp Teahouse, I'd want the hosts to be fully on-board before
converting it over (and the rest of the community to not oppose it).
If that's not doable, we can focus on other use cases first. It's
early days and this one's a long haul -- just like VE. But we
shouldn't shy away from a problem just because it's hard.

Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

2014-09-06 Thread Erik Moeller
On Sat, Sep 6, 2014 at 12:23 AM, Isarra Yos wrote:
 Have the successes and failures of the existing approaches and tools been
 considered? Are things LQT got right present in Flow?

Some, yes (remember Andrew and Brandon have worked on both LQT and
Flow) -- in other cases the team deliberately made a different call,
and they may have gotten it wrong, or not. Let's reason it through.

Flow has LQT-style headers, for example, and thread-level summaries,
both with a much nicer UX than LQT, but adopting some of the same

 Signatures that break the page are currently dealt with by yelling at the
 user to fix their sig and then blocking them if need be. I dunno how a
 structured talkpage would necessarily change that, though having the
 signatures automatically tidied might be useful in general, as it should at
 least help prevent unclosed tags.

Sure, some leeway (and some testing/sanitization) makes sense to me to
see what works.

 Formatting the pages as flat with just ids and links to what the things are
 replying to could be an interesting option experiment with, especially when
 you don't have a lot of space. Like boards. Be like 4chan! Everyone loves


 Why in the world would posts not be editable? I've never used a platform
 where discussion was important in which users couldn't at least edit their
 own posts (along with mods) where the lack of such wasn't often complained
 about (for instance bugzilla and gerrit don't allow it; moodle and tumblr

Sorry, I should have been clearer. By default, Flow lets you edit your
own comments, and lets admins edit all comments, just like typical
forum conventions. It just doesn't let everyone edit everything.

Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] To Flow or not to Flow

2014-09-06 Thread Erik Moeller
On Sat, Sep 6, 2014 at 8:03 AM, Todd Allen wrote:
 One huge thing is that article talk pages are not only for discussions, but
 also for metadata (article assessments, history, Wikiproject data, as
 examples from the English Wikipedia). The top of the talk page also, on
 many pages, serves notices and FAQs to new visitors to the talk page.

Yes, this is supported in Flow through wiki-editable headers. These
are community-editable like a wiki page. LQT simply used the existing
talk page for this purpose and hooked into its history and
permissioning, while Flow manages them separately, and its history
features are still very rudimentary for that reason.

 For reviews like that, it may be necessary to have wikitext act as
 wikitext, another very significant concern. (Your use of Template:Example
 is what's causing the text formatting to break in that section, because it
 does like this: (insert example). You should actually use

There's nothing in Flow's design that makes this impossible. There are
some inconsistencies to work through due to the use of Parsoid's HTML
for comment storage, and some extensions that may just be
fundamentally incompatible with a comment-based approach in their
current form (e.g. page-level translation, etc).

 We need the ability to rapidly archive forum style
 posts or stuff that's become unproductive, and we need -any- editor able to
 do that, not just admins.

Flow has a few features relevant to this right now, all still experimental:

- You can hide a topic from view (collapses it, others can undo)
- You can summarize or close a topic (others can reopen, both
actions update the summary, close also collapses)
- You can edit a topic's title
- You can hide an individual comment (collapses it, others can undo)

In the current permission system (which is easy to change)
the only thing that is lightly restricted is editing other people's

The underlying reasoning here is to try to support patterns that exist
in our community, while discouraging problematic changes. Comments
that solely consist of personal attacks can still be collapsed by
anyone, editing is discouraged except in special circumstances (and
hence restricted to admins); users don't have to monitor their own
comments for inappropriate edits.

Whether that's correct or not, I personally don't have a strong
opinion on. In LQT, we left comments openly editable, and I never
observed a problem with it; I think the arguments on both sides of
this issue are a bit out of proportion.

Back in 2004 I tried a little experiment by creating and adding
it to my signature, to see if a subtle indicator would have more
people actually do anything interesting with my comments. It never
did. A year before I also tried to introduce a policy called Remove
personal attacks on en.wp:

This was hotly debated, and when/where to edit other people's comments
is actually still somewhat ambiguous in policies across wikis. English
Wikipedia acknowledges: There is no official policy regarding when or
whether most personal attacks should be removed, although it has been
a topic of substantial debate. 

Just yesterday, as I was talking with Fram on Danny's talk page about
his .. slight escalation, another user popped in striking out Fram's
comments, then another user reverted that, ... so, there's a fair bit
of potential for conflict in this, which we do see a little bit of
every day.

German Wikipedia more explicitly encourages anyone to remove attacks
except people who are the subject of them, but cautions that users who
are subject of personal attacks should be careful, because it can
exacerbate a conflict. It then proceeds to explain that administrators
are encouraged to completely delete personal attacks using revision

I think the strongest argument to keep comments openly editable, at
least initially, is that it's most consistent with policies as
currently written (most policies I've seen generally discourage
editing other people's comments, but have a few exceptions like the
one above). If, after much debate, communities want to adopt different
policies, then Flow's permissioning could be changed to reflect them.
Keeping the Hide type functionality in place for now would be a good
way to play with alternatives without immediately limiting options.

 We need the ability to have real archives; again, infinite scroll
 with or without search is nowhere near a replacement for that.

100% agreed. But with actual metadata for comments that's structured
and searchable, you can build much better search features -- search by
author, by date range, or even categorize/tag individual threads.
Archives in a well-built discussion system can be much more useful

Re: [Wikimedia-l] To Flow or not to Flow - it does not flow

2014-09-06 Thread Erik Moeller
On Sat, Sep 6, 2014 at 4:15 PM, Dan Garry wrote:
 There is one notable exception to the above, which is talk page header
 templates. One expects updates to a template used as a talk page header to
 update every page the template is currently transcluded on, which is not
 happening presently. {{talk header}} is currently transcluded on over
 250,000 pages, so were these all Flow pages it would be excessively
 laborious to edit all of those headers to force a reparsing of the template
 were it updated. So this functionality, or something similar, should
 probably be included in the Flow MVP [1] if it's deployed on a larger
 scale. I think it's fine for now.

That makes perfect sense -- thanks for pointing it out. Stale headers
would suck indeed.

And now I'm taking a break from wikimedia-l til Monday. The weather's
nice, and the monthly posting limit is starting to loom into view. ;-)
Hope everyone has a nice weekend.

Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

[Wikimedia-l] To Flow or not to Flow

2014-09-05 Thread Erik Moeller
Hi all,

I'm breaking out this discussion about Flow/talk pages (apologies for
repeatedly breaking the megathread, but this is a well-scoped subject
which deserves its own thread).

Fundamentally, there's one key question to answer for talk pages in
Wikimedia projects: Do we want discussions to occur in document mode,
or in a structured comment mode? All else flows from there (pun

== Document mode ==

There are not many examples of document mode discussion systems beyond
wikis. You sometimes see people use collaborative realtime editors as
such, because people want to talk in the same space where they work,
but Google Docs provided alternatives (a pretty powerful
comments/margin system and built-in chat) early on, for example.

The current talk page system is a document mode system. Individual
comments have unclear boundaries (a single transaction can result in
multiple comments, signed or unsigned; indentation levels are
unpredictable and often inconsistent). All the joys and pain points of
working on the same document are present (a heavily trafficked talk
page will see many edit conflicts). You can't easily show comments in
multiple contexts (cross-wiki, via email, as a notification, etc.)
because of the boundary problem.

You could try to make a document mode system work better. On the basis
of wikitext, you can do some very basic things, like the new section
link I added to MediaWiki back in July 2003 [1], when I wrote: This
feature could also be the first stage of a more sophisticated
discussion system, where the next stage would be auto-appending
signatures and providing a 'Reply to this' link after each comment.

But due to the aforementioned unpredictability, even making a reply
link work consistently (and do the right thing) is non-trivial. You
can get some of the way there, and the Wikipedia Teahouse actually has
a gadget, written by Andrew Garrett (more on him below) that does
precisely that.

Note the Join this discussion link. It does give you a pop-up, and
posts the comment for you in the right place, with indentation (it
does not auto-sign, but instead tries to teach users the signature
habit which they'll need to use on other talk pages).

It may be worth doing more research and development on this, to see
just how far we can get without changing the fundamentals, since a
wholly new system may still be years out for wide use. However, there
are inherent limitations due to the lack of a predictable and
consistent structure.

You could go further down the road of a document mode or hybrid
system, but IMO not without introducing fully predictable comment
markers (think comment id=234234Bla ~~~/comment) -- which would
pollute the wikitext, be fragile (e.g. accidental or deliberate
corruption of identifiers), and probably be considered unacceptable in
a system that still supports unlimited wikitext editing for those

== Structured ==

I personally gave up on patchwork on top of talk pages about 10 years
ago. The advantages of having comments clearly identified as such are

- Display comments in arbitrary order, arbitrary threading style
- Search comments across date ranges
- Search comments by author
- Track comments as comments, not as diffs
- Monitor changes at any part of a comment thread
- Display comments independent of a given document (e.g. email,
cross-wiki, etc.)
- Display comment metadata in different formats easily (e.g. timestamps)
- Update author names after a username change without having to update documents
- Enables third parties to build new UIs (think Wikiwand for comments)
more easily
- Ability to tag/categorize individual comments/threads
- and more.

I identified some of these reasons when I wrote the proposal for
LiquidThreads in October 2004 [2]. At that point, the Wikimedia
Foundation had 0 employees, and this was too large an effort to likely
get traction just from ad hoc volunteering. So after some time, I
managed to persuade third parties to fund development, including
Wikicities and WikiEducator, and found a developer to do the initial
work, David McCabe. David did a good initial job but the system had
many known issues and was only deployed at a small scale.

At the same time, I think there were many things about even the
original design that were good (and aren't found in most other forum

- It preserved headers on top of the threaded conversation as
community-editable wiki-like spaces
- It had a full history model for the thread itself, not just comments
- It preserved comments essentially as individual wiki pages, with
their own history
- It had a built-in notion of thread summaries, collaboratively
written, for closing comments

As WMF started to grow, it took on development of LiquidThreads --
with one developer, Andrew Garrett, who did an amazing job cleaning up
the codebase and rethinking many of the assumptions David had made.
LQT got to a point where some 

[Wikimedia-l] Upload Wizard work (was Re: Next steps regarding WMF-community disputes about deployments)

2014-09-04 Thread Erik Moeller
On Sun, Aug 31, 2014 at 8:59 AM, Yann Forget wrote:
 the most urgent and important thing is to fix the

This is indeed underway, and has been for some time, with focus on bug
fixes and code quality improvements.,n,z

Recent work on Media Viewer has been primarily UX prototyping and
validation of the prototype. Based on user research and feedback,
we'll implement only very tightly scoped improvements that have been
validated in the prototype or that require no UX validation (e.g.
attribution and performance improvements).

The best place to follow all the work the team is doing is the
multimedia mailing list:


Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

2014-08-26 Thread Erik Moeller
On Thu, Aug 21, 2014 at 10:35 PM, Erik Moeller wrote:

 If you take a look at the mobile experience in
 a desktop browser, you'll find it not so different from many redesigns
 - large, readable text, narrower measure, deliberately chosen
 typography, minimal clutter, easier access to footnotes, etc.

And the design community is taking notice:
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

2014-08-22 Thread Erik Moeller
On Thu, Aug 21, 2014 at 10:54 PM, rupert THURNER wrote:

 is the conflict not only triggered by a deliverable which was not good
 enough? it did not include the authors in its use cases. the deliverable
 e.g. did include one click more for the authors workflow. which make
 hundreds of million clicks more if you sum it up.


 erik, please can you tell me one good reason what hinders you to tackle the
 source of all this, and rework the mediaviewer use case(s)?

Rupert, I always like a good devil's advocate, especially when it
doesn't sound devil-ish at all. ;-)

Let's start with some facts:

- The MediaViewer rollout was very smooth until the deployments to
German Wikipedia, English Wikipedia and Wikimedia Commons. There could
be many reasons for that -- but it's a fact nonetheless. I do see
little evidence that users in other communities are especially unhappy
about the feature (leaving aside the politics of it now). I would be
very curious what reason people do attribute that difference to,
however (understanding that Commons is very different from the
Wikipedia use case).

- As a user, it's trivial to disable Media Viewer. Not quite as easy
as we want it to be, but literally a scroll-down and click away, which
is more than you can say about most MediaWiki preferences. It's also
trivial to skip on a case-by-case basis -- just open an image in a new

- Even on de.wp, if you read the comments from people supporting the
feature, in the poll leading up to Wikimania (a minority, but not a
tiny one - 72 voters in the poll [1]), you'll notice that the
reader/editor distinction isn't such a clear one. While many users
voted on behalf of readers, others pointed out that they themselves
like the fast access to the picture and switch back and forth as
needed (opening images in the background when they want to skip the
viewer). That was also what we heard from folks at Wikimania, for
example, and the generally low opt-out rates support it.

- The criticism isn't just about that -- it's about a large number of
mostly individually small issues. Generally, the idea that we
effectively munge some of the metadata by displaying a
machine-readable subset below the fold is viewed very negatively,
because 1) it doesn't reflect all the available information, 2) it
makes it harder for users to discover the File: page, and potentially
edit it.

Users who oppose the feature do not always do so strictly for personal
reasons, or many of them would probably be fine to disable it for
themselves; they often have criticisms that go beyond their own needs
and extend into areas like re-use, licensing information, and creating
an environment that draws people into contributing. Editors are not
blind to the needs of readers, they just have a low tolerance for
imperfections and would prefer to see a product that already addresses
all these concerns at the time of release.

We understand all that. We've read virtually every comment (surveys,
feedback page, votes/RFCs, etc.). I'm not normally as familiar with
every product WMF works on but by now I know many of the internals of
the damn thing (though Mark probably thanks the GNU deities daily that
I've not submitted any patches yet).

Change aversion is often [[loss aversion]] - people prefer avoiding
losses to making gains, which is why the positive benefits of a new
feature tend to be overshadowed quickly by any shortcomings, even if
they are (objectively speaking) comparatively small and easily

It's true that we (WMF) should have done more early on to specifically
help with template cleanup -- we made some efforts to add
machine-readable data to key templates and rally community help, but
they were insufficient. This is not strictly an engineering problem -
the CommonsMetadata extension works just fine, the documentation is
clear, etc. It's an outreach effort that should have accompanied the
rollout more systematically. With that said, the needed fixes to
templates are fairly trivial (we just worked with de.wp to implement
one), while immediately resolving issues with license display for
large numbers of files, and help many other applications beyond the

In addition, as previously noted [2], we're testing some pretty
significant changes of the UI, including a much more prominent
integration of the File: page link, identifying it clearly as the
canonical source of metadata.

We're not saying You're wrong, we're right - just that we understand
the issues pretty well, and we think the main concerns can likely be
addressed fairly quickly (and some already have been). In general, we
believe that there needs to be at least some allowance for iterating
on a release, rather than forcing an immediate revert. If we reason
things through together, try things out, look at the results, and
we're wrong, well, let's just turn the thing off completely rather
than making half-assed config changes in one wiki.

Mind you, in responding to the poll on 

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

2014-08-21 Thread Erik Moeller
On Wed, Aug 20, 2014 at 12:32 AM, Pine W wrote:
 I am curious to hear your thoughts about the proposed Technology Committee.
 That idea has some community support and had been discussed at some length
 on the WMF Board Noticeboard.

I think it has merits if it's mostly used as a dispute resolution
body. I think we need to have conflict resolution and escalation
protocols for technology issues. Ideally WMF and a group of community
members (whether in all cases truly representative or not) who are in
conflict about a certain issue or outcome should be able to come to a
consensus _between each other_. But when that's not possible, a group
that is designed to be accountable to both WMF's mission and the
community's consensus may need to be called upon to make a final call
that is binding. In the current governance structure, that could be a
group like the stewards. But it could be something new created for
that purpose, if the community supports it.

This all presupposes that we collectively sign up for this whole
shared power idea. It's a Board creation, a guiding principle, and
all that. But that doesn't mean the community of people who've spent
much of their lives building Wikimedia's projects as volunteers do
believe in it. Maybe we should ask them, as a group, offering the pros
and cons of that approach. It's very different futures -- a WMF that
exists purely to do what communities ask it to, or a WMF that exists -
in part - to look forward, close gaps, and help anticipate where we
want to be 3, 5, 10 years from now. Irrespective of what my own take
might be, both approaches do truly have their merits.

If we sign up collectively for shared power, then today, we lack the
mechanisms to implement that principle effectively, which is why we
have conflicts over power which is not shared.  And a community
elected committee (perhaps with some additional representation of
external expertise) might be one such mechanism, but if we don't have
agreement on the basic idea, no mechanism will work. If we do agree on
the principle, we can try and play with different implementations.


Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

2014-08-20 Thread Erik Moeller
On Tue, Aug 19, 2014 at 2:18 PM, Andy Mabbett wrote:

 Nonetheless, I'm having difficulty understanding how these two statements:

 the Wikimedia Foundation reserves the right to determine the final
 configuration of the MediaViewer feature,

 We’re absolutely not saying that WMF simply wants to be able to
 enforce its decisions

 can be reconciled.

Hi Andy,

I think it's clear that we need to develop a social contract that
works for both parties. It doesn't work for communities if WMF simply
declares an independent decision after a vote or RFC takes place (and
yes, we have done so in this instance, and in others in the past). And
from WMF's point of view (for reasons we have already articulated
several times), it doesn't work to expect that WMF will implement
every vote or RFC as-is without negotiation or discussion, and without
room to take other factors into account.

When we talk about WMF's role, we need to distinguish between
technical processes and outcomes.

In order to ensure consistency (including on issues like release
planning, communications, bug reporting, etc.),  WMF needs to manage
the configuration and deployment _process_ (e.g. we flip the
switches). In order to be able to exercise its leadership role in
technology, it needs to have a say in the _outcome_, even if/when
there are RFCs/votes asking us to disable a feature.

That to me is what the shared power guiding principle means -- we
have clear roles and responsibilities, and we share in the

When we disagree, we need to figure things out together, hear each
other, and reason constructively. We don't have good conventions to do
that right now. The community vote - WMF responds yes/no or
community vote - WMF responds with compromise process is deeply
insufficient and one-sided. It's a win/lose process rather than a
process for working together.

We need to avoid getting to this place to begin with, but we also need
to have better answers when we do, as I'm sure we inevitably will
again from time to time.

This is what we're kicking around on the process ideas page:

Specifically, for something like Media Viewer, a lot of the issues
we've had to work through relate to community-created technology (!)
like custom templates used for certain purposes.

In these situations, sometimes the answer may be Actually, what you
did here with a template is a horrible idea and you probably shouldn't
be doing it that way -- and it's very hard for us to have these
conversations honestly if it's in an oppositional context with a group
of 200 people. And sometimes we need to support use cases that the
community cares very much about, even if our initial reaction is Do
we _really_ have to do this?.

I think it needs to be much more tightly coupled, co-dependent working
relationship through the product's lifecycle so we can work together
honestly and with shared expertise.

That's true for VE, Flow, etc. as well -- we've tried the light
touch community liaison model but I think we need something that
brings us even closer together in day to day working practice. And my
experience with Wikimedia volunteers is that there are almost always
people willing to give their time if they feel it's actually valued in
the process. Not tens of hours a week of course (that's why we have
paid staff), but enough to stay informed and participate.

I could imagine having a process where, for any given project, there's
a nomination and lightweight election process that lets people
participate in associated communtiy task forces, which have weekly
check-ins with the product team and actually meaningfully influence
the roadmap. Is this something that people think could work? Has it
worked well in other contexts?

I think the inter-dependent relationship on technology is really
important to appreciate here -- it's something that's very unique to
us (because of the countless templates, tools, customizations, etc.
created by community members that interact with software we build).
You can't have it both ways -- a crazy amount of customizability by
the users themselves _and_ a very traditional relationship with
software development (ship a finished product to us and then we'll
talk -- meanwhile let me add some parameters to this custom template
that I expect your product will support from day 1).



Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

2014-08-20 Thread Erik Moeller
On Tue, Aug 19, 2014 at 11:48 PM, Erik Moeller wrote:


I meant to say - the one example where we've tried targeted task
forces that I can think of was this one, as part of the strategy
process years ago. IIRC some of the task forces were pretty
productive, though the integration of their work in the final end
product was inconsistent. If product-related task forces actually were
part of the process of influencing the backlog, examining
data/findings, adding potential requirements, etc., that might be a
compelling way to work together.

Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

[Wikimedia-l] Next steps regarding WMF-community disputes about deployments

2014-08-19 Thread Erik Moeller
Hi folks,

This is a response to Martin's note here:

.. and also a more general update on the next steps regarding disputes
about deployments. As you may have seen, Lila has also posted an
update to her talk page, here:

I want to use this opportunity to respond to Martin's and other
people's criticisms, and to talk about next steps from WMF’s
perspective following discussions with Lila and the team. I’m also
sending a copy of this note to all the stewards, to better involve
them in the process going forward.

I am -- genuinely -- sorry that this escalation occurred. We would
have preferred to avoid it.

I would like to recap how we find ourselves in this situation: As
early as July, we stated that the Wikimedia Foundation reserves the
right to determine the final configuration of the MediaViewer feature,
and we explicitly included MediaWiki: namespace hacks in that
statement. [1] When an admin implemented a hack to disable
MediaViewer, another local admin reverted the edit. The original admin
reinstated it. We then reverted it with a clear warning that we may
limit editability of the page. [2] The original admin reinstated the
hack. This is when we protected the page.

Because all admins have equal access to the MediaWiki: namespace,
short of desysopping, there are few mechanisms to actually prevent
edit wars about the user experience for millions of readers.
Desysopping actions could have gotten just as messy -- and we felt
that waiting for a better hack to come along (the likeliest eventual
outcome of doing nothing) or disabling the feature ourselves would not
be any better, either from a process or outcome standpoint.

Our processes clearly need to be improved to avoid these situations in
the future. We recognize that simply rejecting a community request
rather than resolving a conflict together is not the right answer.
We’ve been listening to feedback, and we’ve come to the following

- We intend to undertake a review of our present processes immediately
and propose a new approach that allows for feedback at more critical
and relevant junctures in the next 90 days. This will be a transparent
process that includes your voices.

- As the WMF, we need to improve the process for managing changes that
impact all users. That includes the MediaWiki: namespace. For WMF to
fulfill its role of leading consistent improvements to the user
experience across Wikimedia projects, we need to be able to review
code and manage deployments. This can be done in partnership with
trusted volunteers, but WMF needs to be able to make an ultimate
determination after receiving community feedback regarding production
changes that impact all users.

- We are prepared to unprotect MediaWiki:Common.js on German Wikipedia
and enter constructive, open-ended conversations about the way
forward, provided we can mutually agree to do so on the basis of the
current consistent configuration -- for now. We would like to request
a moratorium on any attempts to disable the feature during this
conflict resolution process. The goal would be to make a final,
cross-wiki determination regarding this specific feature, in
partnership with the community, within at most 90 days.

With regard to the German Wikipedia situation, we’d like to know if
stewards want to at all be involved in this process: In a situation
like this, it can be helpful to have a third party support the
conversation. Stewards are accountable to valid community consensus
within the bounds of the Foundation's goals [3], which seems to be
precisely the intersection of concerns at issue here. We would like to
suggest an IRC meeting with stewards ASAP to talk about the specific
question of stewards’ involvement, if any. If stewards prefer not to
be involved, we understand, but it's probably a good idea to have a
sync-up conversation regardless.

I hope we can move forward in good faith from here, and find better
ways to work together. As Lila has expressed, we believe there is a
need for a clear understanding of our role. It is as follows:

Managing software development, site configuration and deployment is a
core WMF responsibility. The community leads in the development of
content; the Wikimedia Foundation leads in the development of

Because these processes are deeply interdependent, we need to develop
better protocols for timely feedback and resolution of disagreements.
At the same time Lila’s and the Board’s statements make it very clear
that the WMF will not accept RfCs or votes as the sole determining
factor in global software deployments.

This means that technology and UX changes should not be decided by
vote or poll and then disabled at-will: where we disagree, we need to
talk to each other (and yes, that means a more judicious application
of RESOLVED WONTFIX on our end, as well!).  We need to ensure a

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

2014-08-14 Thread Erik Moeller
On Thu, Aug 14, 2014 at 5:41 AM, MZMcBride wrote:
 Is there anything that the German Wikipedia could do to convince you to
 disable MediaViewer there? Some percentage of active users showing up to
 say so? Some percentage of users (logged-in or otherwise) disabling the
 feature? (Presumably we can get stats of some kind.)

We are very open to continuing the discussion about how the feature
should be configured, how it should be improved, and how it should be
integrated in the site experience. Ideally we'd like to minimize
inconsistencies between wikis (because for readers who speak more than
one language, it's just a single site), so changes that help alleviate
conflict or disagreement should ideally also be of the kind that in
general are welcomed and wanted.

On the subject of opt-out numbers, you can see them here:

As you can see, the recent drama has contributed to a significant
increase in opt-out events. Pre-vote, about 17% of very active (100
edit/month) users had disabled MMV. This is about the same number of
people who ultimately voted no, BTW, about 200. Post-vote it was 20%.
Since then it has climbed to 23%. In contrast, about 30% of that same
user group still use Monobook.

I think those numbers can and should reasonably inform the default for
logged in users, for sure. I don't think they should be used to
determine the default for readers.

In general, though, let's talk. The overarching principle we're not
going to budge on is that this process is really not acceptable:

1) The UI changes
2) A subset of users is upset and organizes a poll/vote
3) The poll/vote closes with a request to undo said UI Change and a
request is filed
4) WMF offers compromise or says no
5) A local hack is used to undo said UI change

That's no way to develop software, and that's no way to work together.
If you want a WMF that slavishly implements RFCs or votes to disable
features upon request, you'll need to petition to replace more than
just one person. In fact, you should petition to reduce the staff
dramatically, find an administrative ED who has no opinion on what to
do, and exclusively focus on platform-level improvements and requests
that clearly have community backing.

This is not the org we want to be. I am hopeful and optimistic that
there are enough admins and regular editors who believe in a vision of
improving the user experience iteratively, and working together
through conflict, that we can in future entirely rely on local admins
to prevent the kind of JS hacks we've seen here, working towards a
proper code review and deployment mechanism that further alleviates
the risk of escalations. Mind you, we made it very clear in this case
ahead of time that JS hacks were unacceptable, we attempted a revert
and a very explicit warning.

None of us love drama. We've been punting on this issue for a long
time, living with ambiguity that we knew was going to bite us sooner
or later. When DaB. removed the link to Beta Features on de.wp in
November, calling it clutter, we ignored it and hoped that another
sensible admin would step in and restore it, because we didn't want to
trigger precisely this kind of conflict over minutiae. (It was only
restored a couple of days ago.) In other cases we've made simple
reverts to MediaWiki: edits and hoped they would stick. Can you
imagine how frustrating this is for developers and UX designers who
are paid using donor funds to improve the user experience?

We need rules of engagement for these types of changes, and they need
to acknowlege that WMF is a partner in them. The problem with the
sequence above is that there's no venue for negotiating compromises,
evaluating options, and establishing final agreements about what
should happen. That puts WMF in a position where we get to say yes,
WONTFIX or here's a random compromise, hope you like it. We need
better ways to discuss and negotiate when we disagree.

Please give us some time to outline some compromise options consistent
with the above. However, please don't expect us to endorse the idea of
If WMF doesn't do what we want, we'll just enforce it by means of a
local hack. That is simply not workable, and no Wikimedia Foundation
that at all resembles the one we have today will accept it.

Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

2014-08-13 Thread Erik Moeller
On Wed, Aug 13, 2014 at 10:12 PM, Pete Forsyth wrote:
 In favor of the Media Viewer software is a bunch of inquiry and analysis
 Restoring the default state of the software to the state that worked for
 the last decade is a clear precondition for healthier discussion of a
 positive path forward.

Dear Pete,

You speak as if there is no cost to disabling and re-enabling an
interface. That is not the case.

As you say, millions of readers use the site. And just like editors,
introducing a new, very different viewing experience - like MV - takes
some time to adjust to. We saw this in survey responses improving over
time where they were initially negative, and we also saw it in some
comments of the type I am getting used to it now and I like it. (We
also got plenty of I love this, this is great type comments.) To the
extent that there are discoverability issues in the current UI, they
are just that: discoverability issues. That doesn't mean if the same
user keeps using the same inteface, they will never click a button -
it means it's harder to figure out than it needs to be.

Some of this was already fixed in production. For example, adding a
label to the Use this file button more than doubled its usage. This
is how this stuff works: You instrument, you change, you learn. Other
changes are underway. Turning off the UI completely means readers who
have gotten used to it or who have always enjoyed it will have to
re-learn the old UI, then re-learn the new UI when some (undetermined)
set of conditions are met. That's jarring, confusing, and avoidable.

This is why on all major sites, you see a gradual ramp-up of a new
feature, and continued improvement once it's widely used. Often
there's an opt-in and then an opt-out to ease users into the change.
But once a change is launched, it very rarely gets rolled back unless
it's just clearly not doing what it's supposed to. Yes, we can all
agree that we need to continually raise the bar for how we build
software (without getting into analysis paralysis) -- but that doesn't
mean that reverting (here or in other cases) once there's an ad hoc
vote (or two, or three) is the right thing to do.

No other significantly sized organization follows the development
methodology you're proposing WMF should follow. Certainly, WMF is an
unusual organization, and we have every desire to take concerns
seriously, engage with people, scrutinize data honestly, and work
iteratively to make things better for everyone. What we can't and
won't accept is the idea that admin-reverts of features are an OK way
to try to enforce the outcome of an ad hoc poll or vote.

We can - and should, and do - talk to figure things out. We can - and
should, and do - work out compromises. (And we did indeed agree to
implement a compromise solution for Commons.) But the idea that WMF
always must slavishly execute the result of a poll or vote is neither
rational nor sustainable, nor has it ever been practice --- much less
controversially so in situations where WMF's decisions cannot be
overriden by admins employing JavaScript hacks.

If we're being honest, at the end of the day, a lot of this is about
establishing clear governing principles for the MediaWiki: namespace.
The fact that WMF doesn't implement every vote and indeed has in the
past even been somewhat capricious at times when it did not
(especially when such decisions were made just by a single dev
applying their own best judgment) is not in question. From a
communications perspective, we handled WP:ACTRIAL much more poorly
than we did this (we responded way too late), for example. But you
can't implement WP:ACTRIAL in JavaScript.

But there is no governing principle - documented clearly - that says
you can't disable a feature using the MW: namespace. WMF is saying it
now, and people perceive that (understandably) as a power grab. Fair
enough - it is the explicit extension of existing authority into a
novel domain. Such a change is always contentious and controversial,
but I don't think it was avoidable. If we are to work together
effectively, we need to define areas of competency and responsibility

Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

2014-08-12 Thread Erik Moeller
On Tue, Aug 12, 2014 at 10:19 AM, Craig Franklin wrote:

 I'll be writing a longer post on the Meta RFC later, but can you confirm
 whether the idea is to superprotect key interface pages like
 [[Mediawiki:common.js]] on a permanent basis, or will this feature only be
 used to lock pages temporarily in the case of wheel warring or other
 circumstances like what happened on de.wp?

Dear Craig,

Thank you for the question. Definitely the latter. In general, as I
mentioned in my original note, we intend to bring on-wiki
functionality that directly relates to the UI and code (i.e. chiefly
the MediaWiki: namespace, which is a highly unusual software feature
to begin with) in closer alignment with off-wiki software development,
review and deployment practices, including permission levels (e.g.
actually make it easier for anyone to submit changes, but gate changes
that impact all users).

Lila and I will post more thoughts on the larger issues within the
coming days. We deeply regret the disruptive impact this discussion is
having on Wikimedia's mission and our work together. At the same time,
working through these questions has long been overdue, and my hope is
that we can come out of this with greater clarity regarding how we
partner on issues that are often likely to be contentious, which
includes user experience changes.



Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you

2014-08-12 Thread Erik Moeller
On Tue, Aug 12, 2014 at 4:57 PM, Magnus Manske wrote:

 It's probably fine for modern viewing, although it's hard to guess that
 you get to the file page via the little Commons icon for people who (in all
 likelihood) have never seen that icon, or visited Commons.

Dear Magnus,

Thanks as always for your thoughtful comments. It was great to see you
at Wikimania again, too. :)

Indeed, the icon to the File: page is currently very opaque. We're
preparing for a round of possible changes to the viewing experience,
potentially including
- moving caption above the fold so readers don't have to hunt for it
- moving disable action above-the-fold
- potentially eliminating the below-the-fold panel entirely
- emphasizing the File: page more prominently as the canonical source
of metadata
- separating out download/use actions more clearly

These changes will need to be carefully tested/validated. If you want
to take a look at an early early (!) prototype (!!), see , but please
note that anything but the basic view experience is placeholder right
now (as is the Details icon etc.), and the caption-above-the-fold is
not implemented yet. We've looked at some of this with folks at
Wikimania, and the community feedback there was very positive. But
like I said, give us a bit more time on this.

In general, Giles made a good point at the multimedia roundtable at
Wikimania: Historically, product development at WMF was so slow that
calling for an immediate rollback of a new thing that doesn't work
quite perfectly yet for everyone was a bit more appropriate. Nowadays
we really can push out a new release in a few weeks, and the constant
turning on/off is not helpful for anyone, especially for a feature
like this that can easily be disabled by anyone who doesn't like it.

In answer to your query regarding how we communicated about this,
please note that we posted the following at the beginning of the poll:

Translation: The Wikimedia Foundation reserves the right to make a
final decision about the standard configuration of software features
in Wikimedia projects (see [[m:Limits to configuration changes]]). For
the avoidance of doubt: This includes hacks implemented via the
MediaWiki: namespace. Of course want to find a solution that is
acceptable for readers and editors. We are open to the idea that the
default setting for logged in users and logged out users should be

- - -

I don't think we could have been any clearer that a MediaWiki: disable
hack would not be acceptable -- we said so from the start. We did
indeed agree to implement a different default configuration for logged
in users for Wikimedia Commons, given the unique nature of the
project. We would strongly advise against doing the same for logged in
users on Wikipedia projects, and decided not to do so in response to
the vote on de.wp. While settling on a compromise like this may be
tempting in the short term to de-escalate matters, let's only do it if
it's truly the right thing to do, not for political reasons alone.


Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

2014-08-10 Thread Erik Moeller
Hi folks,

Admins are currently given broad leeway to customize the user
experience for all users, including addition of site-wide JS, CSS,
etc. These are important capabilities of the wiki that have been used
for many clearly beneficial purposes. In the long run, we will want to
apply a code review process to these changes as with any other
deployed code, but for now the system works as it is and we have no
intent to remove this capability.

However, we've clarified in a number of venues that use of the
MediaWiki: namespace to disable site features is unacceptable. If such
a conflict arises, we're prepared to revoke permissions if required.
This protection level provides an additional path to manage these
situations by preventing edits to the relevant pages (we're happy to
help apply any urgent edits) until a particular situation has calmed

Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] let's elect people to serve on the wikimedia engineering community team! (brainstorming)

2014-08-08 Thread Erik Moeller
On Fri, Aug 8, 2014 at 2:47 AM, MZMcBride wrote:

 Yep. At least one of the on-wiki comments by a liaison made me do a
 double-take as it had the tone of your call is very important to us,
 please stay on the line and a representative will be with you shortly.

Sure, sometimes in a liaison role all you're able to say is we'll get
back to you. But that doesn't really characterize the day-to-day work
that Rachel's team is doing in supporting the development of products.
Part of the reason we brought this group closer together with
development teams is precisely so that there can be meaningful
interactions. I see this kind of thread all the time:

Some part of the software changed, a user points out an inconsistency
or issue that results, a CL responds, tracks the issue and talks with
the PM about it as appropriate. This applies just as much to
early-stage features like Flow. There are also regular What would you
like to see kind of threads which are used for idea generation and

 But the Wikimedia Foundation took the lesson to
 be that it simply needed to move a bit more slowly, not more smartly.

Not really. If you take MediaViewer, here are some of the things that
changed in addition to the pace of deployment:

- clearly established opt-in phase via Beta Features (which was
created post-VE as a way to advertise new features)
- built-in clicktracking and performance metrics from fairly early on
- built-in user surveys
- iterative, frequent testing of design prototypes
- community liaison support from the beginning of development, working
in partnership with the PM

That's not to say that there isn't plenty of room for improvement,
including but not limited to:

- stronger success/failure metrics for any new feature
- truly continuous qualitative and quantitative validation throughout
the development lifecycle
- staged rollouts for large wikis (%-of-audience based or otherwise)
- improved microsurvey system consistently used for measuring user satisfaction

I don't think we'll ever get to a place whether we'll always have
consensus about whether a feature should exist, but it should be
possible to get closer to consensus about how to measure whether it
does what it was built to do.

 They say MediaViewer may one day be as feature-ful as the file
 description pages we've had for a long time (editing capability, oh my!).
 It makes little sense to create hobbled file description pages in
 JavaScript rather than addressing the actual issues that file description
 pages have, but this point seems to have gotten completely lost somewhere.

Not at all. The summary view you get in MV is just that: a summary. As
you know, robust metadata support for Wikimedia Commons and locally
hosted files is on the joint roadmap between the multimedia and
Wikidata teams.

MV is first and foremost what it says on the tin: a media viewer. It
gives you access to the image in a form nicely sized for your browser
window, without leaving the page you're on, and pre-loads
next/previous images for quicker access. Whether it should show
advanced metadata at all or just refer back to the File: page is

Indeed, we're currently planning to user-test prototypes with readers
that eliminate the metadata panel except for extended captions and
which have a much more prominent Details link to the File: page.
Early responses from community members we've spoken to about this have
also been positive. This would alleviate issues with perceived munging
of important templates/bits of data by more clearly giving each
feature (File: page, lightbox) its purpose - we can then revisit
advanced metadata integration later. We're not committing to that path
yet, but we're exploring it as part of normal iterative improvement of
the feature.

Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

[Wikimedia-l] [Wikimedia Announcements] Announcing Arthur Richards as Team Practices Manager

2014-07-24 Thread Erik Moeller
Hi folks,

It’s my great pleasure to announce Arthur Richards as Team Practices
Manager for WMF. Arthur will lead a group of ScrumMasters and coaches
to scale up our ability to support teams in developing robust
processes for software delivery. In this new role, Arthur will report
to the VP of Engineering (currently, me).

Arthur’s first engagement in this role will be with the MediaWiki core
team in October. He’s also still transitioning responsibilities for
the mobile web team to Kristen Lans, who just joined WMF as
ScrumMaster. I am very excited about the work ahead. Please join me in
congratulating Arthur and wishing him success in this new role. :-)

What follows is some more background about this new group and about
Arthur’s leadership in case you’re interested (long):

Arthur joined WMF in June 2010 [1] to support fundraising tech. In the
context of team process pains, this team was the first one to adopt an
agile development process (specifically, Scrum), and Arthur was in the
middle of it all. He took this experience with him when he joined the
mobile development team under Tomasz Finc in 2012. The mobile team,
too, would soon adopt Scrum, and Arthur took on the role of
ScrumMaster later that year to be the process owner for the team.

What does that actually mean? It means facilitating the rituals that
are part of an agile team’s work (e.g. the daily stand-ups, the sprint
planning meetings, retrospectives, etc.) and continually facilitating
the team’s discovery of improving the way they work. Say it turns out
week after week that the team is introducing preventable regressions
-- in a situation like this, the ScrumMaster will work with the team
to better understand what’s going on and work towards a solution
(e.g. collaboration with QA, improved test coverage, etc.).

In my experience, every team benefits from process improvement, and
the highest performing ones view this as a continuous part of the
team’s work. Arthur embodies this and I've long viewed the mobile web
team as the canonical example in our org that illustrates the benefits
of agile development done right.

Throughout his experience as ScrumMaster, Arthur has always made a
point of emphasizing the spirit of agile (continued iteration and
improvement, problem solving from the bottom up) rather than sticking
dogmatically to a specific methodology. He’s also led the development
of new processes in the organization that reduce siloed development
and improve coordination, e.g. the Scrum of Scrums.

Through most of this time we relied on external consultants to get
other teams up to speed on agile development practices. While this has
worked reasonably well, the ever-changing personal relationships (a
new consultant for every project) and the lack of institutional memory
has meant that it was hard to customize and scale the process to our

When we spun up the Flow team last year, we had to make a decision:
Will we continue to rely on external consultants, or will we start
building internal capacity for this? We decided to experiment with the
latter, and Arthur Richards and Tomasz Finc led a one-time agile
workshop with the team which was universally well-received and didn't
suffer from some of the false starts of consultant engagements.

So, in the budget planning cycle this year Tomasz and Arthur made a
pitch to formalize this function in the organization: the Team
Practices Group [2]. Given his experience, Arthur is perfectly
positioned to lead this group. He’s demonstrated level-headedness,
patience, and openness that you want from a coach, guiding teams
gently and always focusing on improvements that will be carried
forward by the team as a whole.

After consulting with multiple teams who were hungry for more support
(e.g. a full-time ScrumMaster, or just agile process support), we
decided that Arthur would initially bring on two full-time staffers.

It’s already become clear that this won’t be sufficient. For example,
Analytics is expressing a strong need for a full-time ScrumMaster to
support the growing team so that developers can focus on development.
Whether this is always the right answer remains to be seen. Arthur
will work with teams to find a good balance between custom tailored
solutions and process consistency for the org.

Ultimately, this new group’s function will be similar to what in
traditional organizational models would be a Project Management
Office - except that, instead of having a group of Project Managers
assign work, we want to facilitate self-organizing and increasingly
fluid teams coming up with a process that works for them.

We draw lots of inspiration from other orgs (e.g. Spotify’s seminal
Scaling Agile paper [3]) but also need to account for the unique
requirements of our org (transparency, commitment to open source,

Working with Arthur is a privilege and a pleasure, and I’m thrilled
that he’s agreed to take on this new role. If you're interested in
being part of the ongoing conversation 

Re: [Wikimedia-l] Community RfCs about MediaViewer

2014-07-11 Thread Erik Moeller
On Thu, Jul 10, 2014 at 11:02 PM, John Mark Vandenberg wrote:
 Or .. sometimes the licensing and attribution information isnt

In the common case, Media Viewer provides more prominent and
appropriate attribution and license information than the File: page.
The author name, license, license URL, and source URL are all
immediately accessible below the image, whereas on the File: page
there are sometimes screenfuls of metadata between the image and this
crucial information.

This is actually a pretty remarkable accomplishment given that this
information comes from a huge number of different templates that vary
across wikis. Media Viewer makes use of standardized CSS classes to
extract metadata, and the team has actively worked with the community
to broaden their use:

Ultimately we'll want to use proper structured data for this, but
these changes lay the groundwork, and there's already an API (used by
Media Viewer but open to anyone) that exposes this information.

Where no license is detected, Media Viewer still falls back to a View
license link. The more problematic cases are where actual errors
occur and important information is not extracted, and there will
certainly inevitably be some cases where this happens, but this can
only be worked on over time. The expectation that an unbounded problem
like this is completely solved prior to deployment of a feature is
unreasonable -- it's similar to TemplateData, in that the positive
feedback loop into Media Viewer should actually help encourage more
and consistent use of machine-readable data.

 sometimes you get resolutions which are silly (especially
 svgs at launch, but also slideshows on a file page include a very
 large license logo)

Can you give a specific, current example?

 it takes extra clicks to get to the full-size version,

It takes exactly one click using the View original file button.


Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] [Wikitech-ambassadors] Deprecating print-on-demand functionality

2014-07-11 Thread Erik Moeller
On Fri, Jul 11, 2014 at 8:45 AM, Luca Martinelli wrote:
 so the Book Creator will still be active, maybe under another name,
 maybe with another engine, but still active?

Same name and functionality, just the Order a printed book feature
will disappear.

Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at:

  1   2   3   >