As part of T113210 [1], which is a broader discussion on track for the
developer summit, I am hosting two IRC office hours back to back [2] on
December 21st from 20:00 UTC to 22:00 UTC.
The previous office hour [3] focused on ways to reconnect to the shared
hosting community. This time two very different topics will be discussed.
*The open questions in the descriptions below are by no means meant to be
exhaustive, nor are they expected to be fully answered by the end of those
office hours. They are just examples to clarify the context of the titles.*
*Shared hosting technical alternatives*
During the last office hour on the topic of non-technical mediawiki
installs, people seemed very eager to discuss new technical solutions that
could offer a viable alternative to shared hosting.
Could new technologies like containers allow for performance/cost ratios
comparable to shared hosting? If not, how big would the penalty be? How
much maintenance would we have to do to keep deployment on such platforms
up to date?
Shared hosting has always suffered from the fact that it's not used at the
WMF and therefore only maintained on a volunteer basis. How would things be
different with new tech?
*Shared hosting support definition*
Shared hosting usage is already a reality and we should do a better job
accounting for it. Currently mediawiki contributors have no visibility in
what should be supported and to what degree. Our browser support is graded
and very clear, meanwhile our server-side support is not:
https://www.mediawiki.org/wiki/Compatibility
Should we model our server-side compatibility guidelines on the graded
system we have for browsers? If so, what would that look like? How could we
break down "shared hosting support" into more discreet server-side
capabilities?
[1] https://phabricator.wikimedia.org/T113210
[2] https://meta.wikimedia.org/wiki/IRC_office_hours#Upcoming_office_hours
[3]
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.20…
I see that there's an active workboard in Phabricator at
https://phabricator.wikimedia.org/project/board/225/ for CAPTCHA issues.
Returning to a subject that has been discussed several times before: the
last I heard is that our current CAPTCHAs do block some spambots, but they
also present problems for humans and aren't especially difficult for more
sophisticated spambots to solve. Can someone share a general update on
what's happening with regard to improving usability for humans and
increasing the difficulty for bots? I'm particularly concerned about the
former issue, since CAPTCHAs might be filtering out some good-faith human
editors.
Thanks,
Pine
Hi everyone,
I'm happy to announce that the Community Tech team's Community Wishlist
Survey has concluded, and we're able to announce the top 10 wishes!
634 people participated in the survey, where they proposed, discussed and
voted on 107 ideas. There was a two-week period in November to submit and
endorse proposals, followed by two weeks of voting. The top 10 proposals
with the most support votes now become the Community Tech team's backlog of
projects to evaluate and address.
And here's the top 10:
#1. Migrate dead links to the Wayback Machine (111 support votes)
#2. Improved diff compare screen (104)
#3. Central global repository for templates, gadgets and Lua modules (87)
#4. Cross-wiki watchlist (84)
#4. Numerical sorting in categories (84)
#6. Allow categories in Commons in all languages (78)
#7. Pageview Stats tool (70)
#8. Global cross-wiki user talk page (66)
#9. Improve the "copy and paste detection" bot (63)
#10. Add a user watchlist (62)
You can see the whole list here, with links to all the proposals and
Phabricator tickets:
https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
So what happens now?
Over the next couple weeks, Community Tech will do a preliminary assessment
on the top 10, and start figuring out what's involved. We need to have a
clear definition of the problem and proposed solution, and begin to
understand the technical, design and community challenges for each one.
Some wishes in the top 10 seem relatively straightforward, and we'll be
able to dig in and start working on them in the new year. Some wishes are
going to need a lot of investigation and discussion with other developers,
product teams, designers and community members. There may be some that are
just too big or too hard to do at all.
Our analysis will look at the following factors:
* SUPPORT: Overall support for the proposal, including the discussions on
the survey page. This will take the neutral and oppose votes into account.
Some of these ideas also have a rich history of discussions on-wiki and in
bug tickets. For some wishes, we'll need more community discussion to help
define the problem and agree on proposed solutions.
* FEASIBILITY: How much work is involved, including existing blockers and
dependencies.
* IMPACT: Evaluating how many projects and contributors will benefit,
whether it's a long-lasting solution or a temporary fix, and the
improvement in contributors' overall productivity and happiness.
* RISK: Potential drawbacks, conflicts with other developers' work, and
negative effects on any group of contributors.
Our plan for 2016 is to complete as many of the top 10 wishes as we can.
For the wishes in the top 10 that we can't complete, we're responsible for
investigating them fully and reporting back on the analysis.
So there's going to be a series of checkpoints through the year, where
we'll present the current status of the top 10 wishes. The first will be at
the Wikimedia Developer Summit in the first week of January. We're planning
to talk about the preliminary assessment there, and then share it more
widely.
If you're eager to follow the whole process as we go along, we'll be
documenting and keeping notes in two places:
On Meta: 2015 Community Wishlist Survey/Top 10:
https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Top_10
On Phabricator: Community Wishlist Survey board:
https://phabricator.wikimedia.org/tag/community-wishlist-survey/
Finally: What about the other 97 proposals?
There were a lot of good and important proposals that didn't happen to get
quite as many support votes, and I'm sure everybody has at least one that
they were rooting for. Again, the whole list is here:
https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
We're going to talk with the other Wikimedia product teams, to see if they
can take on some of the ideas the the community has expressed interest in.
We're also going to work with the Developer Relations team to see if some
of these could be taken on by volunteer developers.
It's also possible that Community Tech could take on a small-scale,
well-defined proposal below the top 10, if it doesn't interfere with our
commitments to the top 10 wishes.
So there's lots of work to be done, and hooray, we have a whole year to do
it. If this process turns out to be a success, then we plan to do another
survey at the end of 2016, to give more people a chance to participate, and
bring more great ideas.
For everybody who proposed, endorsed, discussed, debated and voted in the
survey, as well as everyone who said nice things to us recently: thank you
very much for coming out and supporting live feature development. We're
excited about the work ahead of us.
We'd also like to thank Wikimedia Deutschland's Technischer Communitybedarf
team -- they came up with this whole survey process, and they've been
working successfully on lots of community wishes since their first survey
in 2013.
You can watch this page for further Community Tech announcements:
https://meta.wikimedia.org/wiki/Community_Tech/News
Thanks!
Danny Horn
Product Manager, WMF Community Tech
Hi all,
Tomorrow we will be issuing a security release for all branches
of MediaWiki 1.23 and beyond.
The new releases will be:
1.23.12
1.24.5
1.25.4
1.26.1
Fixes will be available in the affected release branches and master.
Tarballs will be uploaded for the indicated point releases as well.
This release encompasses 6 fixes for core only, no bundled extensions
are impacted.
Have a great day,
Chad H. & Chris S.
_______________________________________________
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-12-16
= 2015-12-16 =
== Reading ==
=== Web ===
* Read more feature live on all language Wikipedias as desktop beta feature
/ mobile beta. Please try it out!
* Lead image beta experiment now using WikidataPageBanner
* TechOps involvement requested: potential cache issue, unclear that it's
actually MobileFrontend - https://phabricator.wikimedia.org/T121594
=== Mobile Content Service ===
* 55% of Android Beta App users use the RB based service for link previews
(page summary) + page content
=== Android ===
* 2.1.136-2015-12-09 published.
** New Wikipedia Maps.
** Final release of 2015.
=== iOS ===
* Marching to TestFlight beta testing (with org.wikimedia.wikipedia bundle
ID to ensure database upgrade coverage) soonish. Got an iOS device?
Download the Wikipedia app and let Josh Minor know if yu're interested
=== Reading Infrastructure ===
* Security: ping re SessionManager security review: Is it done, or else
what else do we need to do?
* Security: If you could squeeze in a look at
https://gerrit.wikimedia.org/r/#/c/259066 and related patches (it's another
thing needed for AuthManager that isn't "in" AuthManager itself), we'd
appreciate it.
* DBA: https://phabricator.wikimedia.org/T121335 (which I think he already
knows about)
== Community Tech ==
* Community Wishlist Survey is complete -
https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
** We will be doing analysis on the top 10 proposals and pinging other
teams as needed
* Progress on PageAssessments extension - now uses parser ExtensionData and
JobQueue for better scalability
* Still working on Gadgets 2.0 - you can play with a test instance at
http://commtech.wmflabs.org/wiki/Special:GadgetManager
== Editing ==
=== Language ===
* Deployment of cxserver service-runner rewrite is delayed to Thursday
=== Collaboration ===
* Cross-wiki Echo notification work is mostly done.
* Also planning some UX changes to how Echo notifications work in general
* We finished populating the Flow artificial primary keys.
* Flow Nuke integration almost done
== Fundraising Tech ==
* Investigating potential CN bug limiting banners on mobile
* Updating donation forms and fraud prevention for backup credit card
processor
* Fixes for CiviCRM
* Internal dashboard updates
== Research ==
- ORES:
- 2 new models (etwiki, ukwiki) last week with some *substantial*
improvements to the wikidata models (0.97 AUC)
- 3 hours of downtime this morning. See incident report:
https://wikitech.wikimedia.org/wiki/Incident_documentation/20151216-ores
== Technology ==
=== Services ===
- Page summary end point live & pre-generated:
https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_summary_t…
- EventBus incl. MediaWiki event production ready for deploy; hardware
might not be ready in time before freeze.
- mediawiki-docker-compose prototyping:
https://phabricator.wikimedia.org/T92826#1866757
- includes a combined service running RESTBase, Parsoid & in the future
mathoid & others: https://github.com/gwicke/mediawiki-node-services
- moved to service::node module
- upgraded to Cassandra 2.1.12; improved performance significantly
- Ops dependencies:
- Node 4.2 upgrade: https://phabricator.wikimedia.org/T107762
=== Analytics ===
* Event Logging has been having trouble as we switch to TokuDB because
space filled up, no data loss yet but we've been backfilling from time to
time. We send notices to Analytics-l but if your numbers look weird,
either ask us or rerun your report
* pageview API: blogpost, clients in python, JS, R, dev summit session,
all's well that ends well
* Wikistats reports are being slowly transitioned to Hadoop, we're on track
this quarter and planning to be hopefully done in two more quarters
* We're consolidating all our Phabricator work from Analytics-Backlog and
Analytics-Engineering to just simply Analytics.
=== Security ===
Reviews: Thumber almost completed, PageAssessment starting monday for
CommTech
Security release Thursday
Not yet blocked, but will need parsing team review of T119158 soon
Password policy updates
=== Release Engineering ===
* *Blocking*: (none)
* *Blocked by*: (none)
* *Updates*:
** Scap3 refactoring and tech debt cleanup
*** https://phabricator.wikimedia.org/project/view/1449/
*** Working on common Puppet setup of scap for all services
** Started migrating Jenkins to jessie
** Brief experiment with Appium support in MW-Selenium
*** Sorta works but need a real test case (any interest from iOS or Android
teams?)
*** dr0ptp4kt just pinged bgerstle and niedzielski on #wikimedia-mobile
** Experimenting with JS-based end-to-end test framework
** Gitblit redirection work in progress
*** https://phabricator.wikimedia.org/project/board/46/
=== Technical Operations ===
* Blocking: none
* Blocked on: none
* Updates:
* udp2log decommisioning in favor of kafka complete (kudos to Andrew
Otto)
* Migration of unmaintained OpenDJ LDAP to OpenLDAP
* restbase to service::node done
* cxserver to service::node NOT done.
== Discovery ==
* New Suggestion API goes live as beta feature tomorrow,
https://www.mediawiki.org/wiki/Extension:CirrusSearch/CompletionSuggester
* Working on language detection, PHP port of TextCat
https://github.com/smalyshev/textcat - comments welcome
* Need ops help on https://phabricator.wikimedia.org/T120281
** Akosaris is helping with it
=== Maps/Graphs ===
* Akosiaris is helping with OSM
* Vega 2.0 is stable, I manually updated many graphs to Vega 2.0, and
marked others as Vega 1 so that we can switch default to 2
* SECURITY: Need Kartographer review, Vega protocols
No one asked for 10 more wishes? :)
Thanks Danny and the Community Tech team. This is a great model for working
with our Communities.
-Toby
On Wed, Dec 16, 2015 at 12:18 PM, Nirzar Pangarkar <npangarkar(a)wikimedia.org
> wrote:
> It's really cool to see community wish list coming together!
>
> > We're going to talk with the other Wikimedia product teams, to see if
> they can take on some of the ideas the the community has expressed interest
> in.
>
> +1
>
> On Thu, Dec 17, 2015 at 1:42 AM, Danny Horn <dhorn(a)wikimedia.org> wrote:
>
>> Hi everyone,
>>
>> I'm happy to announce that the Community Tech team's Community Wishlist
>> Survey has concluded, and we're able to announce the top 10 wishes!
>>
>> 634 people participated in the survey, where they proposed, discussed and
>> voted on 107 ideas. There was a two-week period in November to submit and
>> endorse proposals, followed by two weeks of voting. The top 10 proposals
>> with the most support votes now become the Community Tech team's backlog of
>> projects to evaluate and address.
>>
>> And here's the top 10:
>>
>> #1. Migrate dead links to the Wayback Machine (111 support votes)
>> #2. Improved diff compare screen (104)
>> #3. Central global repository for templates, gadgets and Lua modules (87)
>> #4. Cross-wiki watchlist (84)
>> #4. Numerical sorting in categories (84)
>> #6. Allow categories in Commons in all languages (78)
>> #7. Pageview Stats tool (70)
>> #8. Global cross-wiki user talk page (66)
>> #9. Improve the "copy and paste detection" bot (63)
>> #10. Add a user watchlist (62)
>>
>> You can see the whole list here, with links to all the proposals and
>> Phabricator tickets:
>> https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
>>
>> So what happens now?
>>
>> Over the next couple weeks, Community Tech will do a preliminary
>> assessment on the top 10, and start figuring out what's involved. We need
>> to have a clear definition of the problem and proposed solution, and begin
>> to understand the technical, design and community challenges for each one.
>>
>> Some wishes in the top 10 seem relatively straightforward, and we'll be
>> able to dig in and start working on them in the new year. Some wishes are
>> going to need a lot of investigation and discussion with other developers,
>> product teams, designers and community members. There may be some that are
>> just too big or too hard to do at all.
>>
>> Our analysis will look at the following factors:
>>
>> * SUPPORT: Overall support for the proposal, including the discussions on
>> the survey page. This will take the neutral and oppose votes into account.
>> Some of these ideas also have a rich history of discussions on-wiki and in
>> bug tickets. For some wishes, we'll need more community discussion to help
>> define the problem and agree on proposed solutions.
>>
>> * FEASIBILITY: How much work is involved, including existing blockers and
>> dependencies.
>>
>> * IMPACT: Evaluating how many projects and contributors will benefit,
>> whether it's a long-lasting solution or a temporary fix, and the
>> improvement in contributors' overall productivity and happiness.
>>
>> * RISK: Potential drawbacks, conflicts with other developers' work, and
>> negative effects on any group of contributors.
>>
>> Our plan for 2016 is to complete as many of the top 10 wishes as we can.
>> For the wishes in the top 10 that we can't complete, we're responsible for
>> investigating them fully and reporting back on the analysis.
>>
>> So there's going to be a series of checkpoints through the year, where
>> we'll present the current status of the top 10 wishes. The first will be at
>> the Wikimedia Developer Summit in the first week of January. We're planning
>> to talk about the preliminary assessment there, and then share it more
>> widely.
>>
>> If you're eager to follow the whole process as we go along, we'll be
>> documenting and keeping notes in two places:
>>
>> On Meta: 2015 Community Wishlist Survey/Top 10:
>> https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Top_10
>>
>> On Phabricator: Community Wishlist Survey board:
>> https://phabricator.wikimedia.org/tag/community-wishlist-survey/
>>
>> Finally: What about the other 97 proposals?
>>
>> There were a lot of good and important proposals that didn't happen to
>> get quite as many support votes, and I'm sure everybody has at least one
>> that they were rooting for. Again, the whole list is here:
>>
>> https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
>>
>> We're going to talk with the other Wikimedia product teams, to see if
>> they can take on some of the ideas the the community has expressed interest
>> in. We're also going to work with the Developer Relations team to see if
>> some of these could be taken on by volunteer developers.
>>
>> It's also possible that Community Tech could take on a small-scale,
>> well-defined proposal below the top 10, if it doesn't interfere with our
>> commitments to the top 10 wishes.
>>
>> So there's lots of work to be done, and hooray, we have a whole year to
>> do it. If this process turns out to be a success, then we plan to do
>> another survey at the end of 2016, to give more people a chance to
>> participate, and bring more great ideas.
>>
>> For everybody who proposed, endorsed, discussed, debated and voted in the
>> survey, as well as everyone who said nice things to us recently: thank you
>> very much for coming out and supporting live feature development. We're
>> excited about the work ahead of us.
>>
>> We'd also like to thank Wikimedia Deutschland's Technischer
>> Communitybedarf team -- they came up with this whole survey process, and
>> they've been working successfully on lots of community wishes since their
>> first survey in 2013.
>>
>> You can watch this page for further Community Tech announcements:
>> https://meta.wikimedia.org/wiki/Community_Tech/News
>>
>> Thanks!
>>
>> Danny Horn
>> Product Manager, WMF Community Tech
>>
>> _______________________________________________
>> Wmfall mailing list
>> Wmfall(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wmfall
>>
>>
>
> _______________________________________________
> Wmfall mailing list
> Wmfall(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wmfall
>
>
The <graph> tag has just been upgraded to Vega 2.0, adding interactivity
support. See live examples here
<https://www.mediawiki.org/wiki/Extension:Graph/Demo>.
Vega 1.0 is still available, but it is obsolete. Please migrate all your
graphs to the new system so we can turn 1.0 off. See how to migrate:
https://github.com/vega/vega/wiki/Upgrading-to-2.0
Unless the graph definition contains a "version" value, the default is
still 1. After I tag all existing graphs, I will switch the default to
version 2.
See Vega main page for more: http://vega.github.io/vega/
Hi everyone,
Quim and I met earlier, and we agreed to a main room schedule for WikiDev '16:
<https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016/2016-01-04>
<https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016/2016-01-05>
That maybe is overstating it a bit; we mainly decided on two things:
1. Each of the working groups/areas defined in T119018 should have a
session in the main room (Robertson 1, which seats 200). Discussion
of how we should use the focused time in each area should happen in
the working area Phab tasks.
2. We scheduled a couple of main room sessions
Things we scheduled for the main room:
* Next Generation Content Loading and Routing (Adam Baso and Gabriel Wicke)
* How should Wikimedia software support non-Wikimedia deployments of
its software? (Gilles Dubuc)
We still have many open slots in the schedule to fill, but we now have
a little better idea of what those things will be competing against.
Barring a radical change the discussion or in our planning process
this week, what Quim and I plan to do is start filling in the slots in
the competing rooms (Robertson 2 and Robertson 3) from the must have
list (T119593). We'll also be prodding the working areas to decide on
their plan for their Robertson 1 time at WikiDev.
Here's the list of working areas, and the current owner assigned to each:
T119022: Content format - Tim Starling
T119029: Content access and APIs - Gabriel Wicke
T119030: Collaboration - Quim Gil
T119032: Software engineering - Daniel Kinzler
T119162: User interface presentation - Volker Eckl
The agenda bashing session is planned for Wednesday, 2015-12-16, 22:00
UTC (2pm PST) on #wikimedia-office, during what is normally our RFC
meeting.
This email is largely a repeat of a couple of comments I made on Phab:
<https://phabricator.wikimedia.org/T116024#1880035>
For many people (myself included), it's probably easier to read and
respond on Phab, but replies here are welcome as well.
Rob
The MediaWiki Stakeholders' User Group wants to improve MediaWiki and advocates the needs of MediaWiki users outside Wikimedia Foundation-supported projects.
But who is using MediaWiki? In an effort to answer this question the MediaWiki Stakeholders’ Group organized a survey during the summer of 2015 and asked people using MediaWiki to respond. The result is a sampling of over 100 responses from people using MediaWiki around the world. The results were interesting. Folks from all sorts of communities and industries use MediaWiki - from organizations like NASA, The UK LGBT Archive, Society of Exploration Geophysicists, and more.
Combined with some statistics we were able to obtain with help from individuals at the WMF, and the results of the survey we have completed our MediaWiki Usage Report for 2015 . This report provides insight into the various ways MediaWiki is being used - How people upgrade, what extensions are their "must have's", what they enjoy about the software, their concerns, and more. We encourage those using MediaWiki to have a look and provide any feedback or thoughts.
If you'd like to know more about the MediaWiki Stakeholders' Group, or to get involved, join us for one of our regular hangouts or leave a note on our talk page . MediaWiki Wishlist
Combined with existing collaboration around request features and responses from one particular survey question, "What would you like to see most improved in MediaWiki the software?" we created a prioritized 'wishlist' of MediaWiki features . Our next project is figuring out how to implement these requests. See Also
* A raw download of the survey results (anonymized of course) can be found on MediaWiki.org
* If you were at our session at Wikimania 2015, this might sound familiar. There we shared preliminary results from the survey while we were still collecting responses.
Hi all,
here is the usual look at our most important readership metrics. This time
examining, among other things, pageview changes in various countries, such
as the effect of a brief block in China and of the sudden popularity of a
Greek expression derived from Latin. The Android has been seeing a
prolonged decrease in downloads, which fortunately were offset recently by
a more positive development.
With this issue we are changing the scope of this report from a timespan of
one week to two weeks (a fortnight
<https://en.wikipedia.org/wiki/FFF_system>) or four weeks, see further
remarks below. Most of the metrics here are now being updated weekly on the new
Product page <https://www.mediawiki.org/wiki/Wikimedia_Product#Reading>.
Before we go to the usual data, a note (for those who haven’t seen it yet)
that Wikistats <https://stats.wikimedia.org/> has now been upgraded to the
new pageview definition, see the announcement
<http://infodisiac.com/blog/2015/12/wikistats-upgraded-to-new-page-view-defi…>
by Erik Zachte.
(All numbers below are averages for November 23-December 6, 2015 unless
otherwise noted.)
Pageviews
Total: 527 million/day (-2.4% from the previous fortnight)
Context (April 2015-December 2015):
(see also the Vital Signs dashboard
<https://vital-signs.wmflabs.org/#projects=all/metrics=Pageviews>)
A notable weekly drop of -2.2% in the week until November 29, followed by
another -0.2% in the week until December 6.
Desktop: 56.6% (week until Nov 22: 57.2%)
Mobile web: 42.2% (week until Nov 22: 41.6%)
Apps: 1.2% (week until Nov 22: 1.2%)
Context (April 2015-December 2015):
<https://commons.wikimedia.org/wiki/File:Wikimedia_daily_pageviews,_mobile_p…>
Global North ratio: 77.6% of total pageviews (week until Nov 22: 77.3%)
Context (April 2015-December 2015):
<https://commons.wikimedia.org/wiki/File:Percentage_of_Wikimedia_pageviews_f…>
Out of curiosity about the -2.2% drop, I ran a query for the week until
November 29 to find the countries with the largest changes from the
previous week (as in some
<https://lists.wikimedia.org/pipermail/mobile-l/2015-November/009919.html>
previous reports; restricted to those with >1 millions views/day in the
week until Nov 29):
Greece +21.6% 2.3 m/day
South Africa -21.6% 1.2 m/day
Ireland -20.6% 2.3 m/day
Colombia -15.7% 3.3 m/day
Venezuela -10.9% 2.3 m/day
Argentina -8.3% 4.9 m/day
Philippines -8.3% 3.5 m/day
New Zealand -7.3% 1.3 m/day
Vietnam -7.1% 2.1 m/day
Taiwan -6.9% 6.2 m/day
For the top three, I looked at how pageviews developed on a daily basis
during the last three month including the week after this large change
(until Dec 6):
In Greece, the +21.6% rise was the result of an isolated spike from
November 23-25. This can be traced to a single page on the Greek Wiktionary
which on most days before and after only saw a single-digit number of
pageviews, but on these three days received more than 2.8 million: τάλε
κουάλε
<https://el.wiktionary.org/wiki/%CF%84%CE%AC%CE%BB%CE%B5_%CE%BA%CE%BF%CF%85%…>.
It’s about an expression that apparently comes from Latin via Italian
(“tale quale”) <https://en.wiktionary.org/wiki/tale_e_quale> and means
something like “exactly the same” or “spitting image”. From the form of the
spike, it was likely not the result of actual human interest, rather an
undetected bot trying to learn exactly the same about exactly the same.
In Ireland, the -20.6% drop marked the end of a plateau whose start had
actually shown up in the report for the week until November 1
<https://lists.wikimedia.org/pipermail/mobile-l/2015-November/009919.html>
already, where the country was the top changer with a 40.2% rise.
For South Africa, the -20.6% drop does not form part of a clear pattern.
Turning to the week until December 6, there were user reports
<https://zh.wikipedia.org/wiki/Wikipedia:%E4%BA%92%E5%8A%A9%E5%AE%A2%E6%A0%8…>
starting around December 4 that Wikimedia projects were being blocked in
China on desktop more widely than before (the Chinese Wikipedia has been
blocked since May 2015). However, as can be seen in the chart below, the
block appears to have been short-lived. It has also been mentioned in
various media reports (English-language examples: China Digital Times
<http://chinadigitaltimes.net/2015/12/minitrue-weekend-block-of-wikipedia/>,
TIME
<http://time.com/4142305/xi-jinping-china-censorship-world-internet-conferen…>).
New app installations
Android: 30.6k/day (-28.9% from the previous fortnight)
Daily installs per device, from Google Play
Context (last two months):
Instead of recovering to the level from before the App Store feature from
Nov 5-12, installation numbers dropped further until early December. It now
appears that this is connected to a sharp decrease in Google search
referrals to the app’s store page. We’re looking further into it. The good
news though is that the app is currently featured among the Best Apps of
2015
<https://lists.wikimedia.org/pipermail/mobile-l/2015-December/009995.html>
in various countries, with a clear effect on download numbers from December
3 on. (We’ll do a full assessment of the impact of this promotion in early
January after it ends.)
iOS: 4.44k/day (-4.6% from the previous fortnight)
Download numbers from App Annie
Context (last three months):
[image:
Wikipedia_iOS_app_daily_downloads%2C_Sep_8%2C_2015_~_Dec_6%2C_2015_(App_Annie).png]
<https://commons.wikimedia.org/wiki/File:Day-7_retention_of_Wikipedia_iOS_ap…>
There was a 5.4% drop between the week until November 22 and the week until
November 29. But this is still higher than in the first week of November,
say.
App user retention
Android: 14.8% (previous fortnight: 15.0%)
(Ratio of app installs opened again 7 days after installation, average of
daily percentages for installs from the previous week. 1:100 sample)
Context (last three months):
(NB: In order to have the chart show any potential causal connections more
clearly, I’ve changed the x-axis to the installation date instead of the
date on which the survival is measured, and added annotations.)
iOS: N/A
(Ratio of app installs opened again 7 days after installation, average of
daily ratios for installs from the previous week. From iTunes Connect,
opt-in only = ca. 20-30% of all users)
Unfortunately I encountered data quality issues with this metric (again
<https://lists.wikimedia.org/pipermail/mobile-l/2015-November/009942.html>).
We are in contact with Apple about this. I will leave the metric out of
these reports until this is resolved or we have a suitable substitute (we
could conceivably track this ourselves via EventLogging, like on
Android).Unique
app users
Android: 1.158 million / day (-3.8% from the previous week)
Context (last two months):
By now it looks like the App Store feature from Nov 5-12 indeed raised
active users numbers a bit, although they have since been steadily
decreasing, possibly for other reasons (see above).
iOS: 284k / day (+1.0% from the previous fortnight)
Context (last two months):
The week until November 29 saw an increase of 3.5% compared to the previous
week. And in the chart, a little bump can be discerned from November 26 on,
which could be related to Thanksgiving in the US (as we know, mobile use
tends to be higher on weekends and presumably also holidays).
Schedule of this report
As mentioned last time
<https://lists.wikimedia.org/pipermail/mobile-l/2015-November/009942.html>,
we have been rethinking the schedule of this report. New issues will now
cover either two weeks or four weeks each (keeping it to a multiple of
seven days, considering that most of these metrics show a strong weekly
seasonality and comparisons are hence best taking that period into
account). The main purpose remains the same as laid out earlier
<https://lists.wikimedia.org/pipermail/mobile-l/2015-September/009773.html>:
to raise awareness about how these metrics are developing, call out the
impact of any unusual events in the preceding week, and facilitate thinking
about core metrics in general. Having iterated the selection and
presentation of these metrics on a weekly basis since launching this report
in September, they have now stabilized a bit. Also, it now appears that the
newsworthy items uncovered by examining the development of these metrics
can also be covered on a less frequent than weekly schedule. On the other
hand, most of these metrics are now also updated weekly as part of the
Reading team’s section on the new Wikimedia Product page on mediawiki.org
<https://www.mediawiki.org/wiki/Wikimedia_Product>. Feedback and discussion
continue to be welcome.
----
For reference, the queries and source links used are listed below (access
is needed for each). Unless otherwise noted, all content of this report is
authored on behalf of the Wikimedia Foundation and released under the CC
BY-SA 3.0 <https://creativecommons.org/licenses/by-sa/3.0/> license. Most
of the above charts are available on Commons
<https://commons.wikimedia.org/w/index.php?title=Special:ListFiles&offset=20…>,
where I’m also uploading PDF versions of previous issues of this report.
hive (wmf)> SELECT SUM(view_count)/14000000 AS avg_daily_views_millions
FROM wmf.projectview_hourly WHERE agent_type = 'user' AND
CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-11-23"
AND "2015-12-06";
hive (wmf)> SELECT year, month, day,
CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date,
sum(IF(access_method <> 'desktop', view_count, null)) AS mobileviews,
SUM(view_count) AS allviews FROM wmf.projectview_hourly WHERE year=2015 AND
agent_type = 'user' GROUP BY year, month, day ORDER BY year, month, day
LIMIT 1000;
hive (wmf)> SELECT access_method, SUM(view_count)/14 FROM
wmf.projectview_hourly WHERE agent_type = 'user' AND
CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-11-23"
AND "2015-12-06" GROUP BY access_method;
hive (wmf)> SELECT SUM(IF (FIND_IN_SET(country_code,
'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US')
> 0, view_count, 0))/SUM(view_count) FROM wmf.projectview_hourly WHERE
agent_type = 'user' AND
CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-11-23"
AND "2015-12-06";
hive (wmf)> SELECT year, month, day,
CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")), SUM(view_count) AS
all, SUM(IF (FIND_IN_SET(country_code,
'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US')
> 0, view_count, 0)) AS Global_North_views FROM wmf.projectview_hourly
WHERE year = 2015 AND agent_type='user' GROUP BY year, month, day ORDER BY
year, month, day LIMIT 1000;
SELECT country_code, changeratio, ROUND(milliondailyviewsthisweek,1) AS
milliondailyviewsthisweek FROM
(SELECT country_code, ROUND(100*SUM(IF(day>22 AND day<30, view_count,
null))/SUM(IF(day>15 AND day < 23, view_count, null))-100,1) AS
changeratio, SUM(IF(day>22 AND day<30, view_count, null))/7000000 AS
milliondailyviewsthisweek
FROM wmf.projectview_hourly
WHERE
year = 2015
AND month = 11
AND agent_type = "user"
GROUP BY country_code)
AS countrylist
WHERE milliondailyviewsthisweek > 1 GROUP BY country_code, changeratio,
milliondailyviewsthisweek ORDER BY ABS(changeratio) DESC LIMIT 10;
https://console.developers.google.com/storage/browser/pubsite_prod_rev_0281…
(“overview”)
https://www.appannie.com/dashboard/252257/item/324715238/downloads/?breakdo…
(select “Total”)
SELECT LEFT(timestamp, 8) AS date, SUM(IF(event_appInstallAgeDays = 0, 1,
0)) AS day0_active, SUM(IF(event_appInstallAgeDays = 7, 1, 0)) AS
day7_active FROM log.MobileWikiAppDailyStats_12637385 WHERE userAgent LIKE
'%-r-%' AND userAgent NOT LIKE '%Googlebot%' GROUP BY date ORDER BY DATE;
(with the retention rate calculated as day7_active seven days later divided
by day0_active from the install date)
https://analytics.itunes.apple.com/#/retention?app=324715238
hive (wmf)> SELECT SUM(IF(platform = 'Android',unique_count,0))/7 AS
avg_Android_DAU_last_week, SUM(IF(platform = 'iOS',unique_count,0))/7 AS
avg_iOS_DAU_last_week FROM wmf.mobile_apps_uniques_daily WHERE
CONCAT(year,LPAD(month,2,"0"),LPAD(day,2,"0")) BETWEEN 20151123 AND
20151206;
hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0"))
as date, unique_count AS Android_DAU FROM wmf.mobile_apps_uniques_daily
WHERE platform = 'Android';
hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0"))
as date, unique_count AS iOS_DAU FROM wmf.mobile_apps_uniques_daily WHERE
platform = 'iOS';
--
Tilman Bayer
Senior Analyst
Wikimedia Foundation
IRC (Freenode): HaeB
.png){kind=link}
.png){kind=link}
.png){kind=link}