Re: [Wikimedia-l] Women in red

2017-10-16 Thread Ori Livneh
Gnangarra admitted to deliberately using a provocative tone to get
attention ("I chose my tone intentionally to draw attention to the
competition"). Acting surprised that people were aggrieved is disingenuous.

On the topic of sexism: the underrepresentation in the Wikimedia community
of every demographic that is not white men is such a stain on the moral
character of the projects and a threat to their long-term survival. The
ways in which this lack of diversity is reinforced and perpetuated by
behavioral norms are by now so well-documented that ignorance and lack of
malice are not excusable. In my opinion, if you are not making a conscious,
deliberate effort to make this community kinder and more welcoming, you are
part of the problem. All the more so when the topic under discussion is an
initiative to engage women editors and improve the breadth of coverage of
topics relating to women.

On Mon, Oct 16, 2017 at 6:19 AM, Vi to  wrote:

> +1 to your email Yaroslav.
> I'd just underline Gnangarra's original email wasn't sexist, it's so unfair
> to vilify criticism towards contests as sexism.
> Vito
> 2017-10-16 9:33 GMT+02:00 Yaroslav Blanter :
> > My (rejected) message below anyway.
> > [CUT because of boring filter rule]
> > Cheers
> > Yaroslav
> > >
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > wiki/Mailing_lists/Guidelines and
> > wiki/Wikimedia-l
> > New messages to:
> > Unsubscribe:,
> > 
> >
> ___
> Wikimedia-l mailing list, guidelines at:
> i/Mailing_lists/Guidelines and
> New messages to:
> Unsubscribe:,
Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] Why we changed

2016-02-22 Thread Ori Livneh
On Mon, Feb 22, 2016 at 1:26 AM, Tim Starling 

> On 22/02/16 18:45, Erik Moeller wrote:
> > 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
> > hypothesis:
> >
> >
> 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.

Erik is supposing the impact was felt by highly-active editors, a
hypothesis which was not tested by this experiment. Few users become active
editors; few active editors become very active; and few very active editors
become very active in their first week as registered users, which is all
that the experiment considered -- the activity of new users during their
first week.
Wikimedia-l mailing list, guidelines at:
New messages to:

Re: [Wikimedia-l] An Open Letter to Wikimedia Foundation BoT

2016-02-18 Thread Ori Livneh
On Thu, Feb 18, 2016 at 4:47 AM, Dariusz Jemielniak 

> There is way too much blaming/bashing/sour expectations
> working both ways - we almost forget how unique we are, irrespective of
> many slips and avoidable failures we make (and WMF  is definitely leading
> here, too! ;)

No, we're not. My peers in the Technology department work incredibly hard
to provide value for readers and editors, and we have very good results to
show for it. Less than two years ago it took an average of six seconds to
save an edit to an article; it is about one second now. (MediaWiki
deployments are currently halted over a 200-300ms regression!). Page load
times improved by 30-40% in the past year, which earned us plaudits in the
press and in professional circles. The analytics team figured out how to
count unique devices without compromising user anonimity and privacy and
rolled out a robust public API for page view data. The research team is in
the process of collecting feedback from readers and compiling the first
comprehensive picture of what brings readers to the projects. The TechOps
team made Wikipedia one of the first major internet properties to go
HTTPS-only, slashed latency for users in many parts of the world by
provisioning a cache pop on the Pacific Coast of the United States, and is
currently gearing up for a comprehensive test of our failover capabilities,
which is to happen this Spring.

That's just the activity happening immediately around me in the org, and
says nothing of engineering accomplishments like the Android app being
featured on the Play store in 93 countries and having a higher user rating
than Facebook Messenger, Twitter, Netflix, Snapchat, Google Photos, etc. Or
the 56,669 articles that have been created using the Content Translation

This is happening in spite of -- not thanks to -- dysfunction at the top.
If you don't believe me, all you have to do is wait: an exodus of people
from Engineering won't be long now. Our initial astonishment at the Board's
unwillingness to acknowledge and address this dysfunction is wearing off.
The slips and failures are not generalized and diffuse. They are local and
specific, and their location has been indicated to you repeatedly.
Wikimedia-l mailing list, guidelines at:
New messages to:

[Wikimedia-l] Update from the Wikimedia Performance Team

2015-11-05 Thread Ori Livneh

This is the first monthly report from the Wikimedia Performance Team.
The purpose
of these reports is to showcase our work, track our progress, and spark

## Who we are ##

As the Wikimedia Foundation’s Performance Team, we want to create
value for readers
and editors by making it possible to retrieve and render content at the
speed of thought, from anywhere in the world, on the broadest range of
devices and connection profiles.

We are five engineers: Aaron Schulz, Gilles Dubuc, Peter Hedenskog,
Timo Tijhof,
and me. Each of us was born in a different country and has a different mother
tongue. We work out of San Francisco, London, Stockholm, and Montpellier.

## What we are working on ##

* Availability. Although Wikimedia Foundation currently operates six data
centers, MediaWiki is only running on one (in Ashburn, Virginia). If you
are an editor in Jakarta, Indonesia, content has to travel over 15,000
kilometers to get from our servers to you (or vice versa). To run MediaWiki
concurrently from multiple places across the globe, our code needs to be
more resilient to failure modes that can occur when different subsystems
are geographically remote from one another.

* Performance testing infrastructure. WebPageTest provides a stable
reference for a set of browsers, devices, and connection types from
different points in the world. It collects very detailed telemetry that we
use to find regressions and pinpoint where problems are coming from. This
is addition to the more basic Navigation Timing metrics we gather from real
users in production.

* Media stack. We're currently working on overhauling our thumbnail
infrastructure to achieve multiple goals. Improving future-proof
maintainability by taking thumbnail code out of MediaWiki-Core and using a
service instead to perform thumbnail operations. Saving on expensive
storage by no longer storing multiple copies of all thumbnails on disk
forever. Enabling far-future expires for images, to greatly improve their
client cacheability. And finally switching to the best performing
underlying software to generate thumbnails faster.

* ResourceLoader. ResourceLoader is the MediaWiki subsystem that is
responsible for loading JavaScript and CSS. Whereas much of MediaWiki's
code executes only sparingly (in reaction to editors modifying content)
ResourceLoader code runs over half a billion times a day on hundreds of
millions of devices. Its contribution to how users experience our sites is
very large. Our current focus is on improving ResourceLoader's cache
efficiency by packaging and delivering JavaScript and CSS code in a way
that allows it to be reused across page views without needing to be
repeatedly downloaded.

## How are we doing? ##

In future reports, we will spend less time on introductions and more time
reporting on how particular performance metrics have trended since the
previous report and why. In the meantime, we invite you to check out our


## Feedback? ##

Please let us know what you think about these reports and whether we have
picked the right lists to send it to. (We're going to make sure this
information is available on too.)

Until next time,
Aaron, Gilles, Peter, Timo & Ori
Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Update from the Wikimedia Performance Team

2015-11-05 Thread Ori Livneh
On Thu, Nov 5, 2015 at 12:17 PM, Brad Jorsch (Anomie) <
> wrote:

> On Thu, Nov 5, 2015 at 2:13 PM, Ori Livneh <> wrote:
> > Improving future-proof maintainability by taking thumbnail code out of
> > MediaWiki-Core and using a service instead to perform thumbnail
> operations.
> How does that affect third-party use of MediaWiki where people aren't able
> to (or just aren't wanting to) install bespoke services?

It doesn't. There is no plan to strip MediaWiki of its existing
capabilities or to make it depend on this service. And since the intention
is to improve existing quality of service (as opposed to providing new
functionality), I don't expect the feature-set to diverge.
Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] What's cool?

2015-06-07 Thread Ori Livneh
On Thu, Jun 4, 2015 at 2:41 PM, phoebe ayers wrote:

 I need a break from thinking about things going wrong. And so per Milos'
 observation that discussion here is falling off, I thought I'd start an
 open discussion thread about things going right.

 What's a cool thing you just discovered or are involved in that is
 happening in the Wikimedia world?

Six months ago, the average time it took to save a page was 6.1 seconds.
It's now 1.4 seconds. The performance team is in the process figuring out
our goals for the next quarter and we think we can get to sub-second page
saves by September.
Wikimedia-l mailing list, guidelines at:

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

2015-04-22 Thread Ori Livneh
On Tue, Apr 21, 2015 at 11:34 PM, Keegan Peterzell

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


Congratulations, and hats off to you, Kunal, and the rest of the team for
pulling this off. The layers of legacy code and complex social conundrums
you have had to negotiate in order to see this project through were
terrifyingly large, and it's pretty incredible that you have been able to
see it through with minimal disruption to users. Kudos and thank you.
Wikimedia-l mailing list, guidelines at:

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

2014-11-29 Thread Ori Livneh
On Fri, Nov 28, 2014 at 5:55 PM, MZMcBride wrote:

 The banners may be effective, but they're not aligned with Wikimedia's

I wouldn't come out quite as strongly against these banners, but I share
the underlying sentiment.

I agree that the urgency and alarm of the copy is not commensurate with my
(admittedly limited) understanding of our financial situation. Could we run
a survey that places the banner copy alongside a concise statement of the
Foundation's financials, and which asks the respondent to indicate whether
they regard the copy as misleading.

Quantitative assessments of fundraising strategy ought to consider impact
on all assets, tangible or not. This includes the Foundation's goodwill and
reputation, which are (by common wisdom) easy to squander and hard to
repair. It is critical that we be maximally deliberate on this matter.

In addition to the survey suggested above, I want to also propose that we:

(a) solicit input from a neutral reputation management consultancy, and
(b) create a forum for staffers to talk openly about this matter, without
fear of reprisal

All that being said, since this is a tough thread, and since it is
Thanksgiving weekend here in the US, it is a good opportunity to express
how much I appreciate the work of the fundraising team. Banners are never
going to be popular and it must be tough as hell to do this work while
fielding rants and grumbles from everybody and their cousin. I consider it
a stroke of cosmic luck that I get paid to work on Wikipedia and its sister
projects, and I am grateful to you for making that possible.
Wikimedia-l mailing list, guidelines at:

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

2014-09-19 Thread Ori Livneh
On Fri, Sep 19, 2014 at 12:22 AM, Anders Wennersten wrote:

 I experienced no improved answer time, but all time stamps in Wikipedia
 for me become wrong making it impossible to use the feature. I would call
 this problem a thing that should have been found in an alpha text...

Hi Anders,

Thanks for trying it out. Could you clarify what you mean? I don't see
anything wrong, but I'm not very observant. If you're comparing the
logged-in and logged-out views, did you remember to take into account the
timezone offset preference (if set)?
Wikimedia-l mailing list, guidelines at:

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

2014-09-19 Thread Ori Livneh
On Fri, Sep 19, 2014 at 2:27 AM, James Alexander

 Bug filed at:

Yep! Good catch. Thanks James, Anders.
I have a patch up at
Wikimedia-l mailing list, guidelines at:

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

2014-09-19 Thread Ori Livneh
On Fri, Sep 19, 2014 at 3:14 AM, Anders Wennersten

 Thanks!, glad you could sort this out and file a bug

 But really, I understand from this that this feature was released as a
 Beta feature without it ever been tried out on any other project then enwp,
 which for me indicate a proper process for Alpha test before release to
 beta as been missing...

Sorry, I don't agree! I think the process worked very well just now. You're
not giving yourself enough credit, I'm afraid :)
Wikimedia-l mailing list, guidelines at:

[Wikimedia-l] Invitation to beta-test HHVM

2014-09-18 Thread Ori Livneh
(apologies for cross-posting)

I'm happy to announce that HHVM is available on all Wikimedia wikis for
intrepid beta testers. HHVM, you'll recall, is an alternative runtime for
PHP that provides substantial performance improvements over the standard
PHP interpreter. Simply put: HHVM is software that runs on Wikimedia's
servers to make your reading and editing experience faster.

You can read more about HHVM here:

* How do I enable HHVM?

You can enable HHVM by opting in to the beta feature. This short animated
gif will show you how:

Enabling the beta feature will set a special cookie in your browser. Our
servers are configured to route requests bearing this cookie to a pool of
servers that are running HHVM.

* How do I know that it's working?

Opting-in to the beta feature does not change the user interface in any
way. If you like, you can copy the following code snippet to the global.js
subpage of your user page on MetaWiki:

If you copy this script to your global.js, the personal bar will be
annotated with the name of the PHP runtime used to generate the page and
the backend response time. It looks like this:

Edits made by users with HHVM enabled will be tagged with 'HHVM'. The tag
is there as a precaution, to help us clean up if we discover that HHVM is
mangling edits somehow. We don't expect this to happen.

* What sort of performance changes should I expect?

We expect HHVM to have a substantial impact on the time it takes to load,
preview, and save pages.

At the moment, API requests are not being handled by HHVM. Because
VisualEditor uses the API to save articles, opting in to the HHVM beta
feature will not impact the performance of VisualEditor. We hope to have
HHVM handling API requests next week.

* What sort of issues might I encounter?

Most of the bugs that we have encountered so far resulted from minute
differences in how PHP5 and HHVM handle various edge-cases. These bugs
typically cause a MediaWiki error page to be shown.

If you encounter an error, please report it on Bugzilla and tag with it the
'HHVM' keyword.

We're not done yet, but this is an important milestone. The roll-out of
HHVM as a beta feature caps many months of hard work from many developers,
both salaried and volunteer, from the Wikimedia Foundation, Wikimedia
Deutschland, and the broader Wikimedia movement.  I want to take this
opportunity to express my appreciation to the following individuals, listed
in alphabetical order:

Aaron Schulz, Alexandros Kosiaris, Brad Jorsch, Brandon Black, Brett
Simmers, Bryan Davis, Chad Horohoe, Chris Steipp, Erik Bernhardson, Erik
Möller, 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.

More good things to come! :)
Wikimedia-l mailing list, guidelines at: