Dear all,
The next WMF metrics and activities meeting will take place on Thursday,
November 6, 2014 at 7 PM UTC (11 AM PST). The IRC channel is
#wikimedia-office on irc.freenode.net and the meeting will be broadcast as
a live YouTube stream.
The current structure of the meeting is:
* Welcoming recent hires
* Update and Q&A with the Executive Director, if available
* Review of key metrics including the monthly report card, but also
specialized reports and analytic
* Review of financials
* Brief presentations on recent projects, with a focus on highest priority
initiatives
Please review
https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings for further
information about how to participate.
We’ll post the video recording publicly after the meeting.
Thank you,
Praveena
--
Praveena Maharaj
Executive Assistant to the VP of Product & Strategy and the VP of
Engineering
Wikimedia Foundation \\
www.wikimediafoundation.org
On Wed Oct 29 2014 at 10:56:42 Denny Vrandečić <vrandecic(a)google.com> wrote:
> There’s a small tool on WMF labs that you can use to verify the links (it
> displays the articles side by side from a language pair you select, and
> then you can confirm or contradict the merge):
>
> https://tools.wmflabs.org/yichengtry
>
This is really fun, and so useful too. Thank you so much, Denny, Jiang
Bian, Si Li, and Yicheng Huang – "Denny and the Googlers" is a new band
name if ever there was one.
Dear all,
As you know, over the last few months I’ve been learning about the work of
the organizations we fund through the many grantmaking programs here at
WMF. I’ve been particularly focusing on the impact evaluations that have
been done on WMF grants with the first round of Impact Reports. [1] I
expect I will learn more from you all in the coming months, and I will be
creating opportunities to do so.
The Funds Dissemination Committee (FDC) Advisory Group met this past May to
review the first years of the FDC’s grantmaking through the Annual Plan
Grants program. I want to thank them for their thoughtful recommendations. [2]
With the Board of Trustees, I’ve carefully reviewed the Advisory Group
recommendations, in order to understand our successes and our challenges.
I would like to outline my current view of our capabilities and our
opportunities, and I am now publishing my response to these recommendations
on Meta. [3] Please post questions and comments on the Talk page of that
document. [4]
I would like to offer some time for any feedback or questions you may have
on my response. To that end, I’ll be holding a virtual meeting on Monday
Nov 3 at 17:00 UTC, and I invite you to watch the streaming video and join
the conversation. [5] You can ask questions via IRC on #wikimedia-office
directly or message FDC support staff, Katy Love (klove(a)wikimedia.org or on
IRC at Katy.Love) with questions or comments; she will voice them in the
Hangout.
I look forward to speaking with you soon.
Lila Tretikov
Executive Director, WMF
Hi.
Splitting this out from the GLAMs/Chapters thread, I continue to regularly
wonder whether we need stricter guidelines and guidance in the area of
experimenting on Wikimedians.
Erik mentioned trying to further implement A/B testing in software
development, but to me that quickly raises consent and trust issues. My
view is that Wikimedians should be treated as colleagues, not customers.
Of course the stark reality is that A/B testing on users (typically
readers, not editors) during the annual Wikimedia Foundation fundraiser
has been a major component of the Wikimedia Foundation's growth.
Worth repeating, from <https://meta.wikimedia.org/wiki/Experiments>:
---
Current practices in Web analytics reflect their commercial origins. For
better or worse, the greatest motor behind the use of Web analytics has
been the profit interests of online retailers and social networks, for
whom the user is a commodity. These profit interests have profoundly
shaped the discourse of Web analytics, setting both the tenor and the tone
of debate (consider the values implicit in "funnels," a term of art).
A thoughtless application of Web analytics to Wikimedia wikis would import
a moral outlook that is incompatible with (and, indeed, rightfully
offensive to) its community. It also wouldn't work well, because neither
Wikimedia wikis nor their editing communities are for sale. It is
therefore crucial that technical efforts be accompanied by a process of
reflection, the goal of which should be to articulate criteria for Web
analytics that express and promote the broader ambitions of the Wikimedia
movement and the moral commitments that underlie it.
---
I think this about sums it up better than I ever could.
MZMcBride
Forwarding to Wikimedia-l to five context to James' reply. Sorry for
cross-posting.
---------- Forwarded message ---------
From: Denny Vrandečić <vrandecic(a)google.com>
Date: Wed Oct 29 2014 at 10:56:48 AM
Subject: [Wikidata-l] Birthday gift: Missing Wikipedia links (was Re:
Wikidata turns two!)
To: Discussion list for the Wikidata project. <
wikidata-l(a)lists.wikimedia.org>, Wikimedia Mailing List <
wikimedia-l(a)lists.wikimedia.org>
Folks,
as you know, many Googlers are huge fans of Wikipedia. So here’s a little
gift for Wikidata’s second birthday.
Some of my smart colleagues at Google have run a few heuristics and
algorithms in order to discover Wikipedia articles in different languages
about the same topic which are missing language links between the articles.
The results contain more than 35,000 missing links with a high confidence
according to these algorithms. We estimate a precision of about 92+% (i.e.
we assume that less than 8% of those are wrong, based on our evaluation).
The dataset covers 60 Wikipedia language editions.
Here are the missing links, available for download from the WMF labs
servers:
https://tools.wmflabs.org/yichengtry/merge_candidate.20141028.csv
The data is published under CC-0.
What can you do with the data? Since it is CC-0, you can do anything you
want, obviously, but here are a few suggestions:
There’s a small tool on WMF labs that you can use to verify the links (it
displays the articles side by side from a language pair you select, and
then you can confirm or contradict the merge):
https://tools.wmflabs.org/yichengtry
The tool does not do the change in Wikidata itself, though (we thought it
would be too invasive if we did that). Instead, the results of the human
evaluation are saved on WMF labs. You are welcome to take the tool and
extend it with the possibility to upload the change directly on Wikidata,
if you so wish, or, once the data is verified, to upload the results.
Also, Magnus Manske is already busy uploading the data to the Wikidata
game, so you can very soon also play the merge game on the data directly.
He is also creating the missing items on Wikidata. Thanks Magnus for a very
pleasant cooperation!
I want to call out to my colleagues at Google who created the dataset -
Jiang Bian and Si Li - and to Yicheng Huang, the intern who developed the
tool on labs.
I hope that this small data release can help a little with further
improving the quality of Wikidata and Wikipedia! Thank you all, you are
awesome!
Cheers,
Denny
On Wed Oct 29 2014 at 10:52:05 AM Lydia Pintscher <
lydia.pintscher(a)wikimedia.de> wrote:
Hey folks :)
Today Wikidata is turning two. It amazes me what we've achieved in
just 2 years. We've built an incredible project that is set out to
change the world. Thank you everyone who has been a part of this so
far.
We've put together some notes and opinions. And there are presents as
well! Check them out and leave your birthday wishes:
https://www.wikidata.org/wiki/Wikidata:Second_Birthday
Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
_______________________________________________
Wikidata-l mailing list
Wikidata-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
_______________________________________________
Wikidata-l mailing list
Wikidata-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Hey folks :)
Today Wikidata is turning two. It amazes me what we've achieved in
just 2 years. We've built an incredible project that is set out to
change the world. Thank you everyone who has been a part of this so
far.
We've put together some notes and opinions. And there are presents as
well! Check them out and leave your birthday wishes:
https://www.wikidata.org/wiki/Wikidata:Second_Birthday
Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
http://nyti.ms/1rHy4fK
Wikipedia Is Emerging as Trusted Internet Source for Information on Ebola
Noam Cohen
October 26, 2014
The New York Times
Neat! (And a bit terrifying.)
MZMcBride
Hi Peter,
On Tue, Oct 28, 2014 at 8:40 AM, Peter Krautzberger
<peter.krautzberger(a)mathjax.org> wrote:
>> While I can understand that the SVG images were orginally optimized of
>> inline use, I do not see any principal reason why inline SVG's are
>> better.
>
> a) all rendering issues have been due to SVGs not being linine
That's what I do not understand. Do you need to produce different SVG
images for inline and external images? That does not sound intuitive
for me. Or are ther problems in the way browsers render svg-images.
This would indicate that there are browsers with limited MathML and
SVG support.
> b) accessibility of the SVG output: only inline SVG can be styled by
> client-side CSS. A very important accessibility use case are User Style
> Sheets since many users "just" need visual enhancements.
I'm convinced that content MathML is needed for good accessibility.
See the ntcir-11 challange regarding $f_xy=f_yx$ or
$\langle\frac1x\rangle\ge\frac1{\langle x \rangle}$
http://ntcir11-wmc.nii.ac.jp/index.php/NTCIR-11-Math-Wikipedia-Task#Content…
.
> c) improve page performance by reducing http requests. A math page seems to
> easily gather 100 and more equations, all of which cause separate http
> requests. @physikerwelt do you have data on how much equations are actually
> used across pages? In particular, beyond simple <math> \mathbb{N} <\math>
> situations.
I see your point. However this is a general problem with images. So we
need a general solution, if the number of requests is a problem. I had
the impression that squid could handle quite a few requests per second
http://wiki.squid-cache.org/KnowledgeBase/Benchmarks#Squid_trunk_revno_13251
I'm not sure which cachig system is currently used in production but I
guess the number of requests is not an issue at the moment.
Yes, I have numbers about the cross page use of formulae. I'll send an
updated report on enwiki in the following weeks. (Latests on 15'th of
Jan.)
Best
Moritz
>
> As I said, I did not mean to open up that debate -- that's simply not my
> call.
>
> P.
>
> On Mon, Oct 27, 2014 at 5:05 PM, Physikerwelt <wiki(a)physikerwelt.de> wrote:
>>
>> Hi,
>>
>> On Mon, Oct 27, 2014 at 4:52 PM, Gabriel Wicke <gwicke(a)wikimedia.org>
>> wrote:
>> > Peter,
>> >
>> > On 10/27/2014 03:08 AM, Peter Krautzberger wrote:
>> >> Gabriel wrote:
>> >>
>> >>> It would also be nice to reduce the size of the SVG fall-back images,
>> >> which are
>> >>> currently about 50% larger than the (low-resolution) PNGs.
>> >>
>> >> I think this only holds for smaller equations. For more complex
>> >> equations it
>> >> seem to me that minified+zip'ed SVGs are the same size (or smaller)
>> >> than the
>> >> PNG.
>> >>
>> >> @physikerwelt do you have data on that by any chance?
>> Yes. I'm currenty in the process of summarizing the data. Recently
>> LaTeXML added SVG output. This provides even a better basis for
>> comparision.
>> >
>> > we aren't minifying yet. I did some tests last night (see
>> > https://bugzilla.wikimedia.org/show_bug.cgi?id=72547), which suggest
>> > that we
>> > can reduce the size of small SVG formulas by about 25-30% with
>> > minification.
>> > This looks pretty straightforward to add to mathoid.
>> Yes we should defintly do that. I do not see any reason for not doing
>> that.
>> >
>> >> As for further optimizations, you could drop the paths entirely and
>> >> point
>> >> the <use> elements to external files, i.e., use global svg data like
>> >> webfonts. This then raises a different question of balancing: is it
>> >> worth
>> >> loading such "fonts"/spritemaps when there's only a few equations in
>> >> the page?
>> >
>> > For most page views this would likely increase the size, unless those
>> > maps
>> > only had the glyphs needed in a certain page. Which would then reduce
>> > the
>> > caching between pages.
>>
>> I would like to keep it simple. I think this would additional
>> complexity and make debugging much harder.
>> >
>> >> Just for the record since we've rejected it for other reasons, inline
>> >> SVGs
>> >> would also reduce the number of http requests and would resolve the
>> >> clipping
>> >> and baseline problems we've seen in the past.
>> >
>> > It's a trade-off between making everybody download both MathML *and* SVG
>> > (which is larger), or only doing so where MathML is not supported. There
>> > is
>> > also a complexity trade-off between simple stand-alone fall-back images,
>> > and
>> > the maintenance of a global per-page glyph table. Overall, the size of
>> > math
>> > fallbacks is moderate compared to a page with photos, and it looks like
>> > we
>> > can get the size close to that of low-resolution PNG images with
>> > minification. To me, this seems to be a good compromise for now, and we
>> > can
>> > always re-evaluate later.
>> >
>> > Gabriel
>> >
>> We could benchmark a solution that replaces MathML with inline SVG via
>> Javascript as well. However, this would not reduce the number of HTTP
>> requests and would not help people without javascript.
>> While I can understand that the SVG images were orginally optimized of
>> inline use, I do not see any principal reason why inline SVG's are
>> better.
>> Peter, can you explain that?
>>
>> Best
>> Moritz
>
>