[WikimediaMobile] Cross Post to mobile-l: Service Decommission Notice: Mobile Content Service - July 2023

[Adam Baso]

-- Forwarded message -
From: Adam Baso 
Date: Wed, Mar 22, 2023 at 4:45 AM
Subject: Service Decommission Notice: Mobile Content Service - July 2023
To: Wikimedia developers 


TL;DR: The legacy Mobile Content Service is going away in July 2023. Please
switch to Parsoid or another API before then to ensure service continuity.

Hello World,

I'm writing about a service decommission we hope to complete mid-July 2023.
The service to be decommissioned is the legacy Mobile Content Service
("MCS"), which is maintained by the Wikimedia Foundation's Content
Transform Team. We will be marking this service as deprecated soon.

We hope that with this notice, people will have ample time to update their
systems for use of other endpoints such as Parsoid [1] (n.b., MCS uses
Parsoid HTML).

The MCS endpoints are the ones with the relative URL path pattern
/page/mobile-sections* on the Wikipedias. For examples of the URLs see the
"Mobile" section on the online Swagger (OpenAPI) specification
documentation with matching URLs here:

https://en.wikipedia.org/api/rest_v1/#/Mobile

== History ==

The Mobile Content Service ("MCS") is the historical aggregate service that
originally provided support for the article reading experience on the
Wikipedia for Android native app, as well as some other experiences. We
have noticed that there are other users of the service. We are not able to
determine all of the users, as it's hard to tell with confidence from the
web logs.

The Wikimedia Foundation had already  transitioned the Wikipedia for
Android and iOS apps to the newer Page Content Service ("PCS") several
years ago. PCS has some similarities with MCS in terms of its mobility
focus, but it also has different request-response signatures in practice.
PCS, as with MCS, is intended to primarily satisfy Wikimedia
Foundation-maintained user experiences only, and so this is classified with
the "unstable" moniker.

== Looking ahead ==

Generally, as noted in the lead, we recommend that folks who use MCS (or
PCS, for that matter) switch over to Parsoid for accessing Wikipedia
article content programmatically for the most predictable service.

The HTML produced by Parsoid has a versioned specification [2] and because
Parsoid is accessed regularly by a number of components across the globe
tends to have fairly well cached responses. However, please note that
Parsoid may be subject to stricter rate limits that can apply under certain
traffic patterns.

At this point, I do also want to note that in order to keep up with
contemporary HTML standards, particularly those favoring accessibility and
machine readability enhancements, Parsoid HTML will undergo change as we
further converge parsing stacks [3]. Generally, you should expect iteration
on the Parsoid HTML spec, and of course as you may have come to appreciate
that the shape of HTML in practice can vary nontrivially wiki-by-wiki as
practices across wikis vary.

You may also want to consider Wikimedia Enterprise API options, which range
from no cost to higher volume access paid options.

https://meta.wikimedia.org/wiki/Wikimedia_Enterprise#Access

== Forking okay, but not recommended ==

Because MCS acts as a service aggregate and makes multiple backend API
calls, caveats can apply for those subresources - possibility of API
changes, deprecation, and the like. We do not recommend a plain fork of MCS
code because of the subresource fetch behavior. This said, of course you
are welcome to fork in a way compatible with MCS's license.


== Help spread the word ==

Although we are aware of the top two remaining consumers of MCS, we also
are not sure who else is accessing MCS and anticipate that some downstream
tech may break when MCS is turned off. As we are cross-posting this
message, we hope most people who have come to rely upon MCS will see this
message. Please feel free to forward this message to contacts if you know
they are using MCS.

== Help ==

Although we intend to decommission MCS in July 2023, we would like to share
resources if you need some help. We plan to hold office hours in case you
would like to meet with us to discuss this or other Content Transform Team
matters. We will host these events on Google Meet. We will provide notice
of these office hours on the wikitech-l mailing list in the coming weeks
and months.

Additionally, if you would like to discuss your MCS transition plans,
please visit the Content Transform Team talk page:

https://www.mediawiki.org/wiki/Talk:Content_Transform_Team

Finally, some Content Transform Team members will also be at the Wikimedia
Hackathon [4] if you would like some in-person support.


Thank you.

Adam Baso (he/him/his/Adam), on behalf of the Content Transform Team
Director of Engineering
Wikimedia Foundation


[1] https://www.mediawiki.org/wiki/Parsoid

[2] https://www.mediawiki.org/wiki/Specs/HTML

[3] https://www.mediawiki.org/wiki/Parsoid/Parser_Unifi

[WikimediaMobile] Fwd: Wikimedia Foundation Readers Roadmap Review - 27 August 2018

[Adam Baso]

Cross-post.

-- Forwarded message -
From: Adam Baso 
Date: Tue, Aug 28, 2018 at 9:31 AM
Subject: Re: Wikimedia Foundation Readers Roadmap Review - 27 August 2018
To: 


And here are the MP3 and WebM on Commons of the Readers Roadmap Review from
yesterday.

http://commons.wikimedia.org/wiki/File:Readers_Roadmap_Review_-_2018-08-27.mp3

https://commons.wikimedia.org/wiki/File:Wikimedia_Foundation_Readers_Roadmap_Review_-_27_August_2018.webm

On Mon, Aug 27, 2018 at 4:19 PM Adam Baso  wrote:

> Hello -
>
> We recorded a roadmap review this morning for the Wikimedia Foundation's
> Readers team. This covers material about efforts on the web, native apps,
> multimedia, infrastructure, and parsing. Enjoy!
>
> YouTube*
> https://www.youtube.com/watch?v=MZeL0rBDJ3s=20
>
> PDF
>
> https://commons.wikimedia.org/wiki/File:Wikimedia_Foundation_Readers_Roadmap_Review_-_2018-08-27.pdf
>
> As a reminder, you can find our department (Audiences) annual plan on Meta:
>
>
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2018-2019/Audiences
> .
>
> Thanks!
>
> Adam Baso
> Engineering Director
> Wikimedia Foundation - Readers
>
> * I'm converting the video for WebM VP9 on Commons as well.
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: Wikimedia Foundation Readers Roadmap Review - 27 August 2018

[Adam Baso]

Cross-post.

-- Forwarded message -
From: Adam Baso 
Date: Mon, Aug 27, 2018 at 4:19 PM
Subject: Wikimedia Foundation Readers Roadmap Review - 27 August 2018
To: 


Hello -

We recorded a roadmap review this morning for the Wikimedia Foundation's
Readers team. This covers material about efforts on the web, native apps,
multimedia, infrastructure, and parsing. Enjoy!

YouTube*
https://www.youtube.com/watch?v=MZeL0rBDJ3s=20

PDF
https://commons.wikimedia.org/wiki/File:Wikimedia_Foundation_Readers_Roadmap_Review_-_2018-08-27.pdf

As a reminder, you can find our department (Audiences) annual plan on Meta:

https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2018-2019/Audiences
.

Thanks!

Adam Baso
Engineering Director
Wikimedia Foundation - Readers

* I'm converting the video for WebM VP9 on Commons as well.
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Mediawiki-api-announce] BREAKING CHANGE: Some missing parameter error codes are changing

[Adam Baso]

Cross post. mediawiki-api-announce is highly recommended if you write code
consuming the Action API.

-- Forwarded message -
From: Brad Jorsch (Anomie) 
Date: Wed, Jul 25, 2018 at 8:43 AM
Subject: [Mediawiki-api-announce] BREAKING CHANGE: Some missing parameter
error codes are changing
To: 


It was noticed[1] that the error messages for "missing parameter" errors
were not including the module prefix, for example a query to
action=query=search could complain that the "search" parameter must be
set when the actual parameter name is "srsearch". This extends to the error
code, which in this example is "nosearch" rather than "nosrsearch".

This is now fixed, and should be deployed to Wikimedia sites with MediaWiki
1.32.0-wmf.15 and later. See
https://www.mediawiki.org/wiki/MediaWiki_1.32/Roadmap for a schedule.

If your client is checking for specific missing parameter error codes, it
may need to be updated for the changed codes.

[1]: https://phabricator.wikimedia.org/T200155

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] User banned (was: https://lists.wikimedia.org/pipermail/mobile-l/attachments/20180510/08ed9de7/attachment-0001.html)

[Adam Baso]

I've banned the email address below. There's a sustained signup bot
targeting lists ( see
https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)=840688686#Possible_spambots_targeting_Wikimedia_mailing_lists
). It's unclear if this email address was a recent signup from that signup
bot, but the email smells of malice.

This list is intentionally open for signup without the approver of a list
administrator. I don't want us to have to approve every single member
signing up.

For what it's worth, the anti-junk capabilities of the mailman software, as
well as most recipients' email providers, should generally suppress junk
email even if the source account was setup under the signup bots, although
there's no way to guarantee perfect protection. As always, treat
attachments with suspicion and double check links before clicking.

Happy Friday.
-Adam





On Fri, May 11, 2018 at 7:22 AM Tina Southall 
wrote:

>
> https://lists.wikimedia.org/pipermail/mobile-l/attachments/20180510/08ed9de7/attachment-0001.html
> --
> null
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Design] Your feedback matters: Final reminder for the Wikimedia survey

[Adam Baso]

Last call.

-- Forwarded message --
From: Edward Galvez 
Date: Fri, Apr 20, 2018 at 12:42 PM
Subject: [Design] Your feedback matters: Final reminder for the Wikimedia
survey
To: "A mailing list for the Analytics Team at WMF and everybody who has an
interest in Wikipedia and analytics." ,
des...@lists.wikimedia.org, engineer...@lists.wikimedia.org,
lab...@lists.wikimedia.org, Research into Wikimedia content and communities
, Wikimedia developers <
wikitec...@lists.wikimedia.org>


Hi everyone,

This is our last reminder for you to complete the Wikimedia Communities &
Contributors survey.
* To those of you who have taken the survey - thank you so much! We really
appreciate your responses.  *

*This survey is closing in less than three days on Sunday 22 April 2018.*

*If you are volunteer developer, and have contributed code to any pieces of
MediaWiki, gadgets, or tools, please complete the survey. The opinions you
share will affect the work of the Wikimedia Foundation. *






*Follow this link to take the
survey: https://wikimedia.qualtrics.com/jfe/form/SV_5ABs6WwrDHzAeLr?aud=DEV
If you
have already seen a similar message on Phabricator, Mediawiki.org,
Discourse, or other platforms for volunteer developers, please don't take
the survey twice.  It is available in various languages and will take about
20 minutes to complete.You can find more information about
this survey on the project page
 and
see how your feedback helps the Wikimedia Foundation support contributors
like you. This survey is hosted by a third-party service and governed
by this privacy statement
.
Please visit our frequently asked questions page

to
find more information about this survey. Feel free to email me directly
with any questions you may have.Thank you!Edward Galvez from the Community
Engagement departmentWikimedia Foundation*

-- 
Edward Galvez
Evaluation Strategist, Surveys
Learning & Evaluation
Community Engagement
Wikimedia Foundation

___
Design mailing list
des...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Engineering] Reminder: Share you feedback in this Wikimedia survey

[Adam Baso]

Cross post. Reminder.

-- Forwarded message --
From: Edward Galvez 
Date: Thu, Apr 12, 2018 at 3:43 PM
Subject: [Engineering] Reminder: Share you feedback in this Wikimedia survey
To: "A mailing list for the Analytics Team at WMF and everybody who has an
interest in Wikipedia and analytics." ,
des...@lists.wikimedia.org, engineer...@lists.wikimedia.org,
lab...@lists.wikimedia.org, Research into Wikimedia content and communities
, Wikimedia developers <
wikitec...@lists.wikimedia.org>


Hi everyone,

This is a friendly reminder about the Wikimedia Communities and
Contributors Survey.
*We have only heard from 50 Wikimedia volunteer developers. The survey will
close Sunday 22 April 2018.*

If you are volunteer developer, and have contributed code to any pieces of
MediaWiki, gadgets, or tools, please complete the survey. The opinions you
share will affect the work of the Wikimedia Foundation.

*Follow this link to take the survey:* https://wikimedia.qual
trics.com/jfe/form/SV_5ABs6WwrDHzAeLr?aud=DEV

If you have already seen a similar message on Phabricator, Mediawiki.org,
Discourse, or other platforms for volunteer developers, please don't take
the survey twice.
It is available in various languages and will take between 20 and 40
minutes to complete.

You can find more information about this survey on the project page
 and
see how your feedback helps the Wikimedia Foundation support contributors
like you. This survey is hosted by a third-party service and governed by this
privacy statement
.
Please visit our frequently asked questions page

 to find more information about this survey.

Feel free to email me directly with any questions you may have.

Thank you!
Edward Galvez from the Community Engagement department
Wikimedia Foundation



___
Engineering mailing list
engineer...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/engineering
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: Wikimedia contributors survey is here: share your feedback

[Adam Baso]

Cross-post. Please see below.

Thanks!
-Adam

P.S. MWStake will be contacted under separate cover from Cindy.

-- Forwarded message --
From: Edward Galvez 
Date: Wed, Apr 4, 2018 at 5:37 PM
Subject: Wikimedia contributors survey is here: share your feedback


Hi everyone,

The Wikimedia Foundation is asking for your feedback in a survey. We want
to know how well we are supporting your work on and off wiki, and how we
can change or improve things in the future. The opinions you share will
affect the current and future work of the Wikimedia Foundation.

If you are volunteer developer, and have contributed code to any pieces of
MediaWiki, gadgets, or tools, please complete the survey. It is available
in various languages and will take between 20 and 40 minutes to complete.

*Follow this link to the Survey:* https://wikimedia.qualtrics.
com/jfe/form/SV_5ABs6WwrDHzAeLr?aud=DEV

If you have already seen a similar message on Phabricator, Mediawiki.org,
Discourse, or other platforms for volunteer developers, please don't take
the survey twice.

You can find more information about this survey on the project page

and see how your feedback helps the Wikimedia Foundation support
contributors like you. This survey is hosted by a third-party service and
governed by this privacy statement
.
Please visit our frequently asked questions page

to find more information about this survey.

Feel free to email me directly with any questions you may have.

Thank you!
Edward Galvez


-- 
Edward Galvez
Evaluation Strategist, Surveys
Learning & Evaluation
Community Engagement
Wikimedia Foundation
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Wikipedia for Android app flows diagram

[Adam Baso]

Hi mobile-l and wikitech-ambassadors friends!

Rita shared with colleagues a cool diagram of the Wikipedia for Android app
flows, and we thought you may be interested to see it as well. Here you go:

https://commons.wikimedia.org/wiki/File:Wikipedia_Android_app_workflow_-_Feb_2018.pdf

-Adam

-- Forwarded message --
From: Rita Ho 
Date: Fri, Mar 2, 2018 at 9:05 AM
Subject: Friday freebie - updated Android app diagram


Hi folks,

I recently updated the diagram of the Android app, which gives an overview
of all the major flows in the app (including somewhat 'hidden' editing and
article interaction features).

Thought I'd share with the wider team as it enables a quick glance of the
current state of the app for those who don't have it readily available on a
device.
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: Intro to Performance talk from Readers Monthly December 2017

[Adam Baso]

Cross-post.

-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Fri, Feb 2, 2018 at 6:45 AM
Subject: Intro to Performance talk from Readers Monthly December 2017
To: Wikimedia developers <wikitec...@lists.wikimedia.org>


Hello! I'll keep this speedy. Ian Marlier from the Wikimedia Foundation's
Performance team presented an Intro to Performance last month at the
Readers monthly meeting. Check it out!

*YouTube:* https://www.youtube.com/watch?v=TCOOh7eJ08k
*WebM:* https://commons.wikimedia.org/wiki/File:Intro_to_Performance.webm
*PDF:* https://commons.wikimedia.org/wiki/File:Intro_to_Performance.pdf

-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Input requested] Knowledge as a Service at the Wikimedia Developer Summit 2018

[Adam Baso]

Cross-post.

-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Thu, Jan 18, 2018 at 6:38 AM
Subject: [Input requested] Knowledge as a Service at the Wikimedia
Developer Summit 2018
To: Wikimedia developers <wikitec...@lists.wikimedia.org>


Howdy Wikitechnorati,

(And thank you for patience with me cross-posting if you're on other lists.)

I'm writing to invite your input on the following Phabricator task ahead of
next week's Wikimedia Developer Summit 2018 [1] session.

Knowledge as a Service
https://phabricator.wikimedia.org/T183315

The purpose [2] of the Wikimedia Developer Summit 2018 sessions is to
provide guidance for Phase 2 of the Movement Strategic Direction [3] on
buildout of technology capabilities. We'd really love your thoughts to help
set context for our session next week, as Knowledge as a Service is a
primary consideration in the Movement Strategic Direction.

What is Knowledge as a Service? Its essence is about information
architecture approaches and the necessary software that will ultimately
allow content consumption and creation to radiate to new and different
types of interfaces and devices in addition to browser-based approaches. As
you review position papers from attendees [4] you'll notice that the way
they (myself included) think about best solving this is through a heavy
emphasis on technology that makes it easier to better structure information
and its metadata for re-use, remixing, and querying.

What might this mean? Does it mean we should build Wikimedia software in an
API- and metadata-first manner following industry standards compatible with
content structuration? Does it mean weaving our existing structured and
semi-structured data technologies together? How do we build technology that
can ensure successful collaboration between communities on increasingly
structured and interdependent information sources? And how can we ensure
the tech will bolster growth of multilingual and multimedia content
creation and consumption?

I've copied some of the essential material from the Movement Strategic
Direction concerning Knowledge as a Service so you have it here. We would
appreciate your input and hope you will subscribe to the Phabricator task
to contribute and follow along as we explore this topic.

https://phabricator.wikimedia.org/T183315

The following content is copied from https://meta.wikimedia.org/
wiki/Strategy/Wikimedia_movement/2017/Direction :


Knowledge as a service: To serve our users, we will become a platform that
serves open knowledge to the world across interfaces and communities. We
will build tools for allies and partners to organize and exchange free
knowledge beyond Wikimedia. Our infrastructure will enable us and others to
collect and use different forms of free, trusted knowledge.

...

As technology spreads through every aspect of our lives, Wikimedia's
infrastructure needs to be able to communicate easily with other connected
systems.

...

As a platform, we need to transform our structures to support new formats,
new interfaces, and new types of knowledge. We have a strategic opportunity
to go further and offer this platform as a service to other institutions,
beyond Wikimedia. In a world that is becoming more and more connected,
building the infrastructure for knowledge gives others a vested interest in
our success. It is how we ensure our place in the larger network of
knowledge, and become an essential part of it. As a service to users, we
need to build the platform for knowledge or, in jargon, provide knowledge
as a service.

...

Knowledge as a service: A platform that serves open knowledge to the world
across interfaces and communities
Our openness will ensure that our decisions are fair, that we are
accountable to one another, and that we act in the public interest. Our
systems will follow the evolution of technology. We will transform our
platform to work across digital formats, devices, and interfaces. The
distributed structure of our network will help us adapt to local contexts.

...


We will build tools for allies and partners to organize and exchange free
knowledge beyond Wikimedia.
We will continue to build the infrastructure for free knowledge for our
communities. We will go further by offering it as a service to others in
the network of knowledge. We will continue to build the partnerships that
enable us to develop knowledge we can't create ourselves.

...

Our infrastructure will enable us and others to collect and use different
forms of free, trusted knowledge.
We will build the technical infrastructures that enable us to collect free
knowledge in all forms and languages. We will use our position as a leader
in the ecosystem of knowledge to advance our ideals of freedom and
fairness. We will build the technical structures and the social agreements
that enable us to trust the new knowledge we compile. We will focus on
highly structured information to facilitate its exchange and reuse

Re: [WikimediaMobile] Wikipedia for iOS named an Editor's Choice

[Adam Baso]

Congratulations!

On Fri, Oct 27, 2017 at 5:23 PM Joshua Minor  wrote:

> Hello mobile Wikimedians,
>
> Today Apple named the official Wikipedia app an Editor's Choice. This is
> the highest level of recognition for an app by Apple, and gets us a special
> badge and placements in the App Store. In their email to me about the
> change they explained that they wanted to recognize the great improvements
> to the app on iOS and particularly our work on accessibility over the last
> couple years.
>
> This is great recognition for the team's and volunteer contributor's work,
> but more importantly, puts Wikipedia in its rightful place as a first class
> citizen on the App Store. Its an honor to build an app for something as
> beloved and awesome as Wikimedia, and we're so gratified to see our efforts
> to make the Wikipedia app beautiful, and usefu,l to iOS users acknowledged
> like this.
>
>
> [image: Inline image 1]
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Analytics] Archiving some eventlogging tables to hadoop

[Adam Baso]

Cross post in case you’re not on the list or ticket already.

-- Forwarded message -
From: Nuria Ruiz 
Date: Tue, Oct 3, 2017 at 7:26 PM
Subject: [Analytics] Archiving some eventlogging tables to hadoop
To: A mailing list for the Analytics Team at WMF and everybody who has an
interest in Wikipedia and analytics. 


Team:

Our mysql backend for eventlogging is having issues due to disk space. We
need to free space on near term so we will be archiving some tables to
hadoop.

Please see: https://phabricator.wikimedia.org/T168303 and:
https://wikitech.wikimedia.org/wiki/Analytics/Systems/EventLogging#Hadoop._Archived_Data

Thanks,

Nuria
___
Analytics mailing list
analyt...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: CREDIT showcase - replacing with smaller demos

[Adam Baso]

Cross post.

-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Wed, Aug 30, 2017 at 11:29 AM
Subject: CREDIT showcase - replacing with smaller demos
To: Wikimedia developers <wikitec...@lists.wikimedia.org>


Hello -

I'm writing today to let you know that we're cancelling the recurring
CREDIT showcase (https://www.mediawiki.org/wiki/CREDIT_showcase). Turnout
has been relatively low for a while, and it requires a fair amount of setup
each month.

Going forward, we'll return to the previous approach, which was having
individual teams sharing demo videos on their own. Please be on the lookout
for such demos along the way on wikitech-l.

In closing, I'd like to thank everyone who's participated in CREDIT in the
past. I've appreciated all of the hard work that goes into planning these
events and the neat things you've all shared along the way.

Thank you.
-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Wikimedia-l] Global preferences: request for feedback

[Adam Baso]

Cross post.


-- Forwarded message --
From: Danny Horn 
Date: Wed, Aug 23, 2017 at 1:58 PM
Subject: [Wikimedia-l] Global preferences: request for feedback
To: Wikimedia Mailing List 


Hi everyone,

The Community Tech team is currently working on Global preferences, the #4
wish from the 2016 Community Wishlist Survey, and we've got a question for
folks who are interested in using the feature.

We're adapting an extension developed by Legoktm, updating the code and
making some changes to the interface. There'll be a new special page,
Special:GlobalPreferences, where you'll be able to set a preference on all
wikis at once. There's more description and screenshots on the project
page:

https://meta.wikimedia.org/wiki/Community_Tech/Global_preferences

Our question is about how people might use local overrides for the global
preferences -- setting a preference as global, but making an exception for
one or more wikis. If that sounds like the kind of thing you would have an
opinion about :), then please check out this section:

https://meta.wikimedia.org/wiki/Community_Tech/Global_
preferences#For_discussion:_Local_overrides

and leave some feedback on the talk page. Of course, you can also feel free
to post any questions, suggestions or comments about the feature. Thanks!

Danny Horn
Senior Product Manager
WMF Community Tech
___
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
wiki/Wikimedia-l
New messages to: wikimedi...@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Wikidata] wbEntity config variable to be deprecated

[Adam Baso]

Cross post.

-- Forwarded message --
From: Léa Lacroix 
Date: Tue, Jul 18, 2017 at 4:31 AM
Subject: [Wikidata] wbEntity config variable to be deprecated
To: "Discussion list for the Wikidata project." <
wikid...@lists.wikimedia.org>


Hello,

This is an important message for *people who develop gadgets or user
scripts* for Wikidata’s frontend.

We plan to deprecate the wbEntity javascript config variable in the next
months. The variable is currently used on every page load, even if when it
is not useful (for example on mobile). With that change, we will increase
the load speed of the entity pages. After that the expression mw.config.get(
'wbEntity' ); will not work any more. All code that uses this config
variable should be migrated towards using the Mediawiki hook
wikibase.entityPage.entityLoaded.

When a user opens an entity page (item or property), as soon as the JSON
representation of the entity stored on the current entity page is loaded,
the Mediawiki hook wikibase.entityPage.entityLoaded is triggered. Listener
callbacks should expect the entity as a native JavaScript object (the
parsed JSON serialization) passed as the first (and only) argument.

Note: The entity object is completely frozen (read-only) to avoid the case
when one of the clients accidentally changes it and breaks other clients.

Here are a few examples on how you can use it:

 // Basic usagemw.hook( 'wikibase.entityPage.entityLoaded' ).add(
function ( entity ) {
  'use strict';
  // Your code goes here
  console.log( entity );} );
// Convert to jQuery promisevar entityPromise = $.Deferred( function (
deferred ) {
  mw.hook( 'wikibase.entityPage.entityLoaded' ).add( function ( entity ) {
 deferred.resolve( entity );
  } );} ).promise();
// Convert to native promisevar entityPromise = new Promise( function
( resolve ) {
  mw.hook( 'wikibase.entityPage.entityLoaded' ).add( function ( entity ) {
 resolve( entity );
  } );} );

See also: the related ticket , the
code of wikibase.entityPage.entityLoaded

.
If you have any question or need support with migrating specific gadgets,
feel free to write to me.
Thanks,

-- 
Léa Lacroix
Project Manager Community Communication 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/029/42207.

___
Wikidata mailing list
wikid...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Offline-l] [INFO] Few good news about mwoffliner

[Adam Baso]

Cross post.


-- Forwarded message --
From: Emmanuel Engelhart 
Date: Tue, Jun 27, 2017 at 3:26 PM
Subject: [Offline-l] [INFO] Few good news about mwoffliner
To: Using Wikimedia projects and MediaWiki offline <
offlin...@lists.wikimedia.org>
Cc: "kiwix-develo...@lists.sourceforge.net" <
kiwix-develo...@lists.sourceforge.net>


Hi

We rarely write here specifically about mwoffliner, even if this tool is
time to time named by-the-way in threads. But these last months we have
done many interesting improvements to this important tool and I thought
it might be valuable to report quickly about them.

As a reminder, mwoffliner is a script which is thought to build a ZIM
file from any (recent) online Mediawiki. It scraps a snapshot of the
online wiki (HTML/JS/pictures/...) on your local disk.

Here is the list of recent improvements:

* We have introduce Parsoid as a local dependence, which means that even
if a Mediawiki does not have Parsoid/Visual Editor installed, mwoffliner
should have a chance now to build the ZIM file of it by running Parsoid
locally.

* We have introduced the Parsoid mobile layout suppport which allows to
build ZIM file with a similar layout as Wikipedia Mobile version. This
is pretty much in beta and we plan first to use it only for Wikipedia.org.

* We have introduced the support of audio/video which means that now,
like the pictures, they are mirrored too. Our first tests show that for
Wikipedia it tends to multiply the size of the ZIM file by a factor
four. As a consequence we won't use it directly everywhere. That said
the feature is there and we will step-by-step introduce video in the ZIM
files we are generating with mwoffliner.

* We have published mwoffliner (and mwmatrixoffliner) to the npmjs
repository: https://www.npmjs.com/package/mwoffliner. Now everybody can
install it easily (but you still need to take care about the dependences).

* We have made the script a bit more modular: you can call it like any
other program but now you can also use it as a library in your own
Javascript/Node.js scripts.

* We have moved the git repository to the openZIM organization on
Github: https://github.com/openzim/mwoffliner. By moving all our scraper
to the openZIM organization we hope to bring a bit of clarity between
Kiwix and openZIM respective duties. Have a look to all other scrapers
we have migrated to openZIM: https://github.com/openzim

mwoffliner is not a tool for everybody but it is really important to
continue to improve it to provide quality ZIM files of Wikipedia,
Wiktionary, ... So if you have Javascript skills please come to help us
to prepare the next big steps forward
https://github.com/openzim/mwoffliner/issues

Regards
Emmanuel

--
Kiwix - Wikipedia Offline & more
* Web: http://www.kiwix.org
* Twitter: https://twitter.com/KiwixOffline
* more: http://www.kiwix.org/wiki/Communication


___
Offline-l mailing list
offlin...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/offline-l


signature.asc
Description: PGP signature
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Analytics] Ongoing Network maintenance will affect all analytics websites

[Adam Baso]

FYI

-- Forwarded message -
From: Luca Toscano 
Date: Thu, Apr 27, 2017 at 11:30 AM
Subject: [Analytics] Ongoing Network maintenance will affect all analytics
websites
To: A mailing list for the Analytics Team at WMF and everybody who has an
interest in Wikipedia and analytics. 


Tracking task: T148506

Should last approximately 10/15 mins from now and it will affect all the
Analytics websites (Yarn, Hue, Pivot, etc..).

Please reach out to me (elukey) on IRC if you have further questions.

Luca
___
Analytics mailing list
analyt...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [MediaWiki-l] Where are the Web fonts loaded?

[Adam Baso]

Forwarding to mobile-l for those not on mediawiki-l with an interest in
this problem space.

-Adam

Forwarded conversation
Subject: [MediaWiki-l] Where are the Web fonts loaded?


From: Emmanuel Engelhart 
Date: Wed, Apr 19, 2017 at 1:56 AM
To: MediaWiki announcements and site admin list <
mediawik...@lists.wikimedia.org>


Hi

A few Wikipedias - like the Wikipedia in Farsi - (should) have support
for Web fonts. This is done to insure that the display of the article is
done correctly. Unfortunately I have difficulties to find them, where
are they defined/loaded?

Kind regards
Emmanuel

--
Kiwix - Wikipedia Offline & more
* Web: http://www.kiwix.org
* Twitter: https://twitter.com/KiwixOffline
* more: http://www.kiwix.org/wiki/Communication

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

--
From: Amir E. Aharoni 
Date: Wed, Apr 19, 2017 at 2:21 AM
To: MediaWiki announcements and site admin list <
mediawik...@lists.wikimedia.org>


They can be enabled by clicking the gear icon near the Languages list, then
clicking "Fonts", and checking "Download fonts when needed".

This was on by default for some time in 2013, but it turned out to cause
severe performance problems and was made opt-in.

By 2017 the issues are quite different given the technology landscape:
modern operating systems supports fonts better, and some of the webfonts
specifications in web standards changed as well. The whole feature should
be redone, although unfortunately this is not currently on the top of the
Language team's priority list.

That said, I'm ALWAYS willing to hear about _problems_ in different
languages. AFAIK, the issue with Persian is that the text is usually
readable, but not as elegant as it should be, although I'm very interested
in hearing more details. For some other languages, especially of South and
South East Asia, fonts are not installed in operating systems at all, so
they are completely unreadable, although this is getting better in the
latest versions of desktop Linux, Android, Windows, Mac, and iOS.

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬

--
From: Emmanuel Engelhart 
Date: Sun, Apr 23, 2017 at 8:56 AM
To: MediaWiki announcements and site admin list <
mediawik...@lists.wikimedia.org>


Hi Amir

On 19.04.2017 09:21, Amir E. Aharoni wrote:
> They can be enabled by clicking the gear icon near the Languages list,
then
> clicking "Fonts", and checking "Download fonts when needed".

Thank you, I found it... I read in the past about that option but was
not able to find it on my screen... I was searching in the usuable user
preferences where - to my taste - this option should be proposed.

> This was on by default for some time in 2013, but it turned out to cause
> severe performance problems and was made opt-in.
>
> By 2017 the issues are quite different given the technology landscape:
> modern operating systems supports fonts better, and some of the webfonts
> specifications in web standards changed as well. The whole feature should
> be redone, although unfortunately this is not currently on the top of the
> Language team's priority list.
>
> That said, I'm ALWAYS willing to hear about _problems_ in different
> languages. AFAIK, the issue with Persian is that the text is usually
> readable, but not as elegant as it should be, although I'm very interested
> in hearing more details. For some other languages, especially of South and
> South East Asia, fonts are not installed in operating systems at all, so
> they are completely unreadable, although this is getting better in the
> latest versions of desktop Linux, Android, Windows, Mac, and iOS.

I'm interested by that feature in an offline context. Many users have
been complaining for a longer time because of problems with the display
of Wikipedia content in certain languages (I guess the similar one like
with online Wikipedia).

As we were not able to create ZIM files with a correct management of the
js/css (offline mockup of the resources loader), my answer was always
the same: we need first to mockup offline the behaviour of the resource
loader to be able then to load web fonts correctly.

We are now so far: we pretty much load the correct js/css resources...
So I had a look to that problem again - more accurately. I have
discovered that in fact our scrapper does not load any web fonts... and
here I'm.

I don't think we will have big performance issues as everything is
anyway offline (please correct me if my guess is wrong), but I need
somehow to tell our scrapper (so the Wikipedia API) to deal with web
fonts... how should I do that?

Regards

___
MediaWiki-l mailing list
To unsubscribe, go to:

[WikimediaMobile] Fwd: March 2017 CREDIT showcase video and notes posted

[Adam Baso]

Cross post in case you don't follow wikitech-l.

-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Tue, Mar 21, 2017 at 3:36 PM
Subject: March 2017 CREDIT showcase video and notes posted
To: Wikimedia developers <wikitec...@lists.wikimedia.org>


Hello! The CREDIT showcase video and notes from earlier this month have
been posted. Enjoy!

https://www.mediawiki.org/wiki/CREDIT_showcase/2017-03-01

Here's what was covered:

* Stephen Niedzielski, localized Android app independent of system language
* Gergő Tisza, Developer Wishlist
* Gergő Tisza, PsySH (much of the credit is due to Antoine Musso who could
not participate)
* Jan Drewniak - 'Explore Similar' feature for search results

-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Wikimedia-l] Reminder: Wikimania '17 Conference Submission Deadline March 30th

[Adam Baso]

Cross posting to mobile-l.

-Adam


-- Forwarded message --
From: Ellie Young 
Date: Sun, Mar 12, 2017 at 5:49 PM
Subject: [Wikimedia-l] Reminder: Wikimania '17 Conference Submission
Deadline March 30th
To: Wikimedia Mailing List , "Wikimania
general list (open subscription)" 


All,

A reminder that the deadline for submissions for Wikimania '17   is in two
weeks - March 30!
Please spread the word

The Wikimania Montréal Call for Submissions  can be found in French here:
https://wikimania2017.wikimedia.org/wiki/Submissions/fr

and in English here:
https://wikimania2017.wikimedia.org/wiki/Submissions/en

On behalf of the Wikimania program committee,

Ellie Young
-

Que vous soyez un membre de la communauté de l’un des projets Wikimédia
(tels que Wikipédia, Wikibooks, Wikidata, Wikisource, Wikinews, Wikimedia
Commons, Wiktionnaire, MediaWiki ou autres), un créateur de contenu libre
ou un consommateur, nous recevrons avec plaisir votre proposition pour une
session lors de Wikimania 2017.

*dates importantes*

Appel aux propositions ouvert : 2 février 2017
Date limite de soumission des présentations (conférence, panneau, table
ronde et atelier) : 30 mars 2017
Date limite de soumission des brefs exposés, affiches et réunions d’oiseaux
de la même plume : 15 mai 2017.
Notification d’acceptation des présentations : 20 avril 2017
Notification d’acceptation des brefs exposés, affiches et réunions
d’oiseaux de la même plume : 10 juin 2017

*Types de soumissions & Comment soumettre: *
https://wikimania2017.wikimedia.org/wiki/Submissions/fr

*Des questions ?* Merci de contacter le Comité du programme par
wikimania-program(à)wikimedia.org.



Whether you are a community member of one of the Wikimedia projects (such
as Wikipedia, Wikibooks, Wikidata, Wikisource, Wikinews, Wikimedia Commons,
Wiktionary, MediaWiki or others), or a fellow open content creator or
consumer, we welcome your proposal for a session at Wikimania 2017.

*Important dates*

Call for proposals opens: February 2, 2017
Deadline for submitting presentation (lecture, panel, roundtable and
workshop) submissions: March 30, 2017
Deadline for submitting lightning talks, poster, and birds of a feather
submissions: May 15, 2017
Notification of acceptance for presentations: April 20, 2017
Notification of acceptance for lightning talks, poster and birds of a
feather submissions: June 10, 2017

*Submission types & how to submit:*
https://wikimania2017.wikimedia.org/wiki/Submissions/en


*Any questions?* Please contact the Programme Committee at
wikimania-program at wikimedia.org

--
Ellie Young
Events Manager
Wikimedia Foundation
eyo...@wikimedia.org
___
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
wiki/Wikimedia-l
New messages to: wikimedi...@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] CREDIT showcase Wednesday 1-March-2017

[Adam Baso]

Reminder, this starts in about 30 minutes.

On Thu, Feb 23, 2017 at 7:06 AM, Adam Baso <ab...@wikimedia.org> wrote:

> Cross-post in case you don't follow wikitech-l closely.
>
> -- Forwarded message --
> From: Adam Baso <ab...@wikimedia.org>
> Date: Thu, Feb 23, 2017 at 7:05 AM
> Subject: CREDIT showcase Wednesday 1-March-2017
> To: Wikimedia developers <wikitec...@lists.wikimedia.org>
>
>
> Hi!
>
> I'd like to welcome you to join us at the CREDIT showcase next week,
> Wednesday, 1-March-2017 at 1900 UTC / 1100 Pacific Time. We'd like to see
> your demos, whether they're rough works in progress or polished production
> material, or even just a telling of something you've been studying
> recently. For more information on the upcoming event, as well as recordings
> of previous events, please visit the following page:
>
> https://www.mediawiki.org/wiki/CREDIT_showcase
>
> And if you'd like to share the news about the upcoming CREDIT showcase,
> here's some suggested verbiage. Thanks! -Adam
>
> *Hi *
>
> *I hope all is well with you! I wanted to let you know about CREDIT, a
> monthly demo series that we’re running to showcase open source tech
> projects from Wikimedia’s Community, Reading, Editing, Discovery,
> Infrastructure and Technology teams. *
>
> *CREDIT is open to the public, and we welcome questions and discussion.
> The next CREDIT will be held on March 1st at 11am PT / 2pm ET / 19:00 UTC. *
>
> *There’s more info on MediaWiki
> <https://www.mediawiki.org/wiki/CREDIT_showcase>, and on Etherpad
> <https://etherpad.wikimedia.org/p/CREDIT>, which is where we take notes and
> ask questions. You can also ask questions on IRC in the Freenode chatroom
> #wikimedia-office (web-based access here
> <https://webchat.freenode.net/?channels=%23wikimedia-office>). Links to
> video will become available at these locations shortly before the event.*
>
> *Please feel free to pass this information along to any interested folks.
> Our projects tend to focus on areas that might be of interest to folks
> working across the open source tech community: language detection,
> numerical sort, large data visualizations, maps, and all sorts of other
> things.*
>
> *If you have any questions, please let me know! Thanks, and I hope to see
> you at CREDIT.*
>
> *YOURNAME*
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: CREDIT showcase Wednesday 1-March-2017

[Adam Baso]

Cross-post in case you don't follow wikitech-l closely.

-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Thu, Feb 23, 2017 at 7:05 AM
Subject: CREDIT showcase Wednesday 1-March-2017
To: Wikimedia developers <wikitec...@lists.wikimedia.org>


Hi!

I'd like to welcome you to join us at the CREDIT showcase next week,
Wednesday, 1-March-2017 at 1900 UTC / 1100 Pacific Time. We'd like to see
your demos, whether they're rough works in progress or polished production
material, or even just a telling of something you've been studying
recently. For more information on the upcoming event, as well as recordings
of previous events, please visit the following page:

https://www.mediawiki.org/wiki/CREDIT_showcase

And if you'd like to share the news about the upcoming CREDIT showcase,
here's some suggested verbiage. Thanks! -Adam

*Hi *

*I hope all is well with you! I wanted to let you know about CREDIT, a
monthly demo series that we’re running to showcase open source tech
projects from Wikimedia’s Community, Reading, Editing, Discovery,
Infrastructure and Technology teams. *

*CREDIT is open to the public, and we welcome questions and discussion. The
next CREDIT will be held on March 1st at 11am PT / 2pm ET / 19:00 UTC. *

*There’s more info on MediaWiki
<https://www.mediawiki.org/wiki/CREDIT_showcase>, and on Etherpad
<https://etherpad.wikimedia.org/p/CREDIT>, which is where we take notes and
ask questions. You can also ask questions on IRC in the Freenode chatroom
#wikimedia-office (web-based access here
<https://webchat.freenode.net/?channels=%23wikimedia-office>). Links to
video will become available at these locations shortly before the event.*

*Please feel free to pass this information along to any interested folks.
Our projects tend to focus on areas that might be of interest to folks
working across the open source tech community: language detection,
numerical sort, large data visualizations, maps, and all sorts of other
things.*

*If you have any questions, please let me know! Thanks, and I hope to see
you at CREDIT.*

*YOURNAME*
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] CREDIT video posted, another reminder about the CREDIT survey

[Adam Baso]

Hi there, the CREDIT showcase video from yesterday is available on YouTube
and Commons. Also, another call for your responses on our short CREDIT
survey.

https://www.youtube.com/watch?v=JxjSQ0TGXsw
https://commons.wikimedia.org/wiki/File:CREDIT_-_January_2017.webm

Topics: responsive CSS on desktop, randomizing your locale during Wikipedia
for Android development, on-wiki translatable training modules, and offline
ZIM file integration for the Wikipedia for Android app

After you've finished watching, I encourage you to take our CREDIT survey.
We'd appreciate your feedback. Here is a link to the survey (which is
hosted on a third-party service), and, for information about privacy and
data handling, the survey privacy statement.

https://docs.google.com/a/wikimedia.org/forms/d/e/
1FAIpQLSedAtyPfcEhT6OVd26Y-3v_jm3yM3ShvMqgAWBUPxb24u_Y9g/viewform

https://wikimediafoundation.org/wiki/CREDIT_Feedback_
Survey_Privacy_Statement.

This email is being sent to several mailing lists in order to reach
multiple audiences. As always, please follow the list link at the very
bottom of this email in case you want to manage your list subscription
options such as digest, unsubscribe, and so on.

Thanks to everyone for their demos and support of CREDIT!

-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] CREDIT next week, and a survey

[Adam Baso]

Reminder: this is in about 25 minutes.

On Fri, Jan 27, 2017 at 12:34 PM, Adam Baso <ab...@wikimedia.org> wrote:

> (Another) cross post.
>
> Hi everybody!
>
> As a reminder the CREDIT Showcase is next week on Wednesday,
> 1-February-2017 (see https://www.mediawiki.org/wiki/CREDIT_showcase for
> details). Also, as I mentioned previously we're conducting a survey about
> CREDIT. We'd appreciate your feedback! Here is a link to the survey (which
> is hosted on a third-party service), and, for information about privacy and
> data handling, the survey privacy statement.
>
> https://docs.google.com/a/wikimedia.org/forms/d/e/
> 1FAIpQLSedAtyPfcEhT6OVd26Y-3v_jm3yM3ShvMqgAWBUPxb24u_Y9g/viewform
>
> https://wikimediafoundation.org/wiki/CREDIT_Feedback_
> Survey_Privacy_Statement.
>
> This email is being sent to several mailing lists in order to reach
> multiple audiences. As always, please follow the list link at the very
> bottom of this email in case you want to manage your list subscription
> options such as digest, unsubscribe, and so on.
>
> And, as usual, if you'd like to share the news about the upcoming CREDIT,
> here's some suggested verbiage.
>
> *Hi *
>
> *I hope all is well with you! I wanted to let you know about CREDIT, a
> monthly demo series that we’re running to showcase open source tech
> projects from Wikimedia’s Community, Reading, Editing, Discovery,
> Infrastructure and Technology teams. *
>
> *CREDIT is open to the public, and we welcome questions and discussion.
> The next CREDIT will be held on February 1st at 11am PT / 2pm ET / 19:00
> UTC. *
>
> *There’s more info on MediaWiki
> <https://www.mediawiki.org/wiki/CREDIT_showcase>, and on Etherpad
> <https://etherpad.wikimedia.org/p/CREDIT>, which is where we take notes and
> ask questions. You can also ask questions on IRC in the Freenode chatroom
> #wikimedia-office (web-based access here
> <https://webchat.freenode.net/?channels=%23wikimedia-office>). Links to
> video will become available at these locations shortly before the event.*
>
> *Please feel free to pass this information along to any interested folks.
> Our projects tend to focus on areas that might be of interest to folks
> working across the open source tech community: language detection,
> numerical sort, large data visualizations, maps, and all sorts of other
> things.*
>
> *If you have any questions, please let me know! Thanks, and I hope to see
> you at CREDIT.*
>
> *YOURNAME*
>
>
> Thanks!
>
> Adam Baso
> Director of Engineering, Reading
> Wikimedia Foundation
> ab...@wikimedia.org
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] CREDIT next week, and a survey

[Adam Baso]

(Another) cross post.

Hi everybody!

As a reminder the CREDIT Showcase is next week on Wednesday,
1-February-2017 (see https://www.mediawiki.org/wiki/CREDIT_showcase for
details). Also, as I mentioned previously we're conducting a survey about
CREDIT. We'd appreciate your feedback! Here is a link to the survey (which
is hosted on a third-party service), and, for information about privacy and
data handling, the survey privacy statement.

https://docs.google.com/a/wikimedia.org/forms/d/e/1FAIpQLSedAtyPfcEhT6OVd26Y-3v_jm3yM3ShvMqgAWBUPxb24u_Y9g/viewform

https://wikimediafoundation.org/wiki/CREDIT_Feedback_Survey_Privacy_Statement
.

This email is being sent to several mailing lists in order to reach
multiple audiences. As always, please follow the list link at the very
bottom of this email in case you want to manage your list subscription
options such as digest, unsubscribe, and so on.

And, as usual, if you'd like to share the news about the upcoming CREDIT,
here's some suggested verbiage.

*Hi *

*I hope all is well with you! I wanted to let you know about CREDIT, a
monthly demo series that we’re running to showcase open source tech
projects from Wikimedia’s Community, Reading, Editing, Discovery,
Infrastructure and Technology teams. *

*CREDIT is open to the public, and we welcome questions and discussion. The
next CREDIT will be held on February 1st at 11am PT / 2pm ET / 19:00 UTC. *

*There’s more info on MediaWiki
<https://www.mediawiki.org/wiki/CREDIT_showcase>, and on Etherpad
<https://etherpad.wikimedia.org/p/CREDIT>, which is where we take notes and
ask questions. You can also ask questions on IRC in the Freenode chatroom
#wikimedia-office (web-based access here
<https://webchat.freenode.net/?channels=%23wikimedia-office>). Links to
video will become available at these locations shortly before the event.*

*Please feel free to pass this information along to any interested folks.
Our projects tend to focus on areas that might be of interest to folks
working across the open source tech community: language detection,
numerical sort, large data visualizations, maps, and all sorts of other
things.*

*If you have any questions, please let me know! Thanks, and I hope to see
you at CREDIT.*

*YOURNAME*


Thanks!

Adam Baso
Director of Engineering, Reading
Wikimedia Foundation
ab...@wikimedia.org
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: CREDIT in 37 minutes

[Adam Baso]

Cross posting recorded video links and demo names.

-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Wed, Dec 7, 2016 at 5:03 PM
Subject: Re: CREDIT in 37 minutes
To: Wikimedia developers <wikitec...@lists.wikimedia.org>


And the videos. Enjoy!

YouTube: https://www.youtube.com/watch?v=W_sf-kHAQkg
WebM on Commons: https://commons.wikimedia.org/wiki/File:CREDIT_-_December_
2016.webm

* David Chan: Multi-user editing in VisualEditor
* Ed Sanders: VisualEditor source mode
* Erik Bernhardson, Phan (static analysis) integration for mediawiki core
* Stephen Niedzielski, Automated unit testing of Android views across
locale, accessibility, theme, screen and other configurations
* Erik Bernhardson, Search Click Models

On Wed, Dec 7, 2016 at 12:23 PM, Adam Baso <ab...@wikimedia.org> wrote:

> Reminder, starting soon!
>
> On Wed, Nov 30, 2016 at 2:33 PM, Adam Baso <ab...@wikimedia.org> wrote:
>
>> Hello all -
>>
>> The next CREDIT showcase is a week from today - Wednesday,
>> 7-December-2016 at 1900 UTC (1100 San Francisco).
>>
>> https://www.mediawiki.org/wiki/CREDIT_showcase
>>
>> If you have a demo, please add it here:
>>
>> https://etherpad.wikimedia.org/p/CREDIT
>>
>> Last month there were demos on offline, IFTTT, and File properties search
>> & new WDQS visualizations.
>>
>> https://www.youtube.com/watch?v=NmfqtP3pr2Y=47
>>
>> We welcome demos from Wikimedia community members and staff alike - from
>> polished features to something you just got working last night. Hope to see
>> you soon!
>>
>> If you would like to invite anyone to CREDIT, feel free to use this
>> template.
>>
>> *Hi *
>>
>> *I hope all is well with you! I wanted to let you know about CREDIT, a
>> monthly demo series that we’re running to showcase open source tech
>> projects from Wikimedia’s Community, Reading, Editing, Discovery,
>> Infrastructure and Technology teams. *
>>
>> *CREDIT is open to the public, and we welcome questions and discussion.
>> The next CREDIT will be held on December 7th at 11am PT / 2pm ET / 19:00
>> UTC. *
>>
>> *There’s more info on MediaWiki
>> <https://www.mediawiki.org/wiki/CREDIT_showcase>, and on Etherpad
>> <https://etherpad.wikimedia.org/p/CREDIT>, which is where we take notes and
>> ask questions. You can also ask questions on IRC in the Freenode chatroom
>> #wikimedia-office (web-based access here
>> <https://webchat.freenode.net/?channels=%23wikimedia-office>). Links to
>> video will become available at these locations shortly before the event.*
>>
>> *Please feel free to pass this information along to any interested folks.
>> Our projects tend to focus on areas that might be of interest to folks
>> working across the open source tech community: language detection,
>> numerical sort, large data visualizations, maps, and all sorts of other
>> things.*
>>
>> *If you have any questions, please let me know! Thanks, and I hope to see
>> you at CREDIT.*
>>
>>
>> *-YOURNAME*
>>
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: CREDIT in 37 minutes

[Adam Baso]

Cross post, CREDIT in about 36 minutes. Hope to see your demos and works in
progress!

-Adam


-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Wed, Dec 7, 2016 at 12:23 PM
Subject: CREDIT in 37 minutes
To: Wikimedia developers <wikitec...@lists.wikimedia.org>


Reminder, starting soon!

On Wed, Nov 30, 2016 at 2:33 PM, Adam Baso <ab...@wikimedia.org> wrote:

> Hello all -
>
> The next CREDIT showcase is a week from today - Wednesday,
> 7-December-2016 at 1900 UTC (1100 San Francisco).
>
> https://www.mediawiki.org/wiki/CREDIT_showcase
>
> If you have a demo, please add it here:
>
> https://etherpad.wikimedia.org/p/CREDIT
>
> Last month there were demos on offline, IFTTT, and File properties search
> & new WDQS visualizations.
>
> https://www.youtube.com/watch?v=NmfqtP3pr2Y=47
>
> We welcome demos from Wikimedia community members and staff alike - from
> polished features to something you just got working last night. Hope to see
> you soon!
>
> If you would like to invite anyone to CREDIT, feel free to use this
> template.
>
> *Hi *
>
> *I hope all is well with you! I wanted to let you know about CREDIT, a
> monthly demo series that we’re running to showcase open source tech
> projects from Wikimedia’s Community, Reading, Editing, Discovery,
> Infrastructure and Technology teams. *
>
> *CREDIT is open to the public, and we welcome questions and discussion.
> The next CREDIT will be held on December 7th at 11am PT / 2pm ET / 19:00
> UTC. *
>
> *There’s more info on MediaWiki
> <https://www.mediawiki.org/wiki/CREDIT_showcase>, and on Etherpad
> <https://etherpad.wikimedia.org/p/CREDIT>, which is where we take notes and
> ask questions. You can also ask questions on IRC in the Freenode chatroom
> #wikimedia-office (web-based access here
> <https://webchat.freenode.net/?channels=%23wikimedia-office>). Links to
> video will become available at these locations shortly before the event.*
>
> *Please feel free to pass this information along to any interested folks.
> Our projects tend to focus on areas that might be of interest to folks
> working across the open source tech community: language detection,
> numerical sort, large data visualizations, maps, and all sorts of other
> things.*
>
> *If you have any questions, please let me know! Thanks, and I hope to see
> you at CREDIT.*
>
>
> *-YOURNAME*
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: December 2016 CREDIT Showcase in a week

[Adam Baso]

Cross post in case you don't follow wikitech-l. See you soon!

-Adam


-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Wed, Nov 30, 2016 at 2:33 PM
Subject: December 2016 CREDIT Showcase in a week
To: Wikimedia developers <wikitec...@lists.wikimedia.org>


Hello all -

The next CREDIT showcase is a week from today - Wednesday, 7-December-2016
at 1900 UTC (1100 San Francisco).

https://www.mediawiki.org/wiki/CREDIT_showcase

If you have a demo, please add it here:

https://etherpad.wikimedia.org/p/CREDIT

Last month there were demos on offline, IFTTT, and File properties search &
new WDQS visualizations.

https://www.youtube.com/watch?v=NmfqtP3pr2Y=47

We welcome demos from Wikimedia community members and staff alike - from
polished features to something you just got working last night. Hope to see
you soon!

If you would like to invite anyone to CREDIT, feel free to use this
template.

*Hi *

*I hope all is well with you! I wanted to let you know about CREDIT, a
monthly demo series that we’re running to showcase open source tech
projects from Wikimedia’s Community, Reading, Editing, Discovery,
Infrastructure and Technology teams. *

*CREDIT is open to the public, and we welcome questions and discussion. The
next CREDIT will be held on December 7th at 11am PT / 2pm ET / 19:00 UTC. *

*There’s more info on MediaWiki
<https://www.mediawiki.org/wiki/CREDIT_showcase>, and on Etherpad
<https://etherpad.wikimedia.org/p/CREDIT>, which is where we take notes and
ask questions. You can also ask questions on IRC in the Freenode chatroom
#wikimedia-office (web-based access here
<https://webchat.freenode.net/?channels=%23wikimedia-office>). Links to
video will become available at these locations shortly before the event.*

*Please feel free to pass this information along to any interested folks.
Our projects tend to focus on areas that might be of interest to folks
working across the open source tech community: language detection,
numerical sort, large data visualizations, maps, and all sorts of other
things.*

*If you have any questions, please let me know! Thanks, and I hope to see
you at CREDIT.*


*-YOURNAME*
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: CREDIT in 35 minutes (was: CREDIT Showcase in two days - 2-Nov-2016 - call for demos)

[Adam Baso]

Link to video now available.

-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Wed, Nov 2, 2016 at 1:40 PM
Subject: Re: CREDIT in 35 minutes (was: CREDIT Showcase in two days -
2-Nov-2016 - call for demos)
To: Wikimedia developers <wikitec...@lists.wikimedia.org>


In case you missed it, here's the video.

https://www.youtube.com/watch?v=NmfqtP3pr2Y=47

Today presenters covered Wikipedia offline (including a Progressive Web App
<https://en.m.wikipedia.org/wiki/Progressive_web_app> version) prototypes,
IFTTT <https://en.m.wikipedia.org/wiki/IFTTT> automated testing, file
property searches, and Wikidata visualizations you can copy and paste into
articles. More details on the Etherpad
<https://etherpad.wikimedia.org/p/CREDIT>.

-Adam







On Wed, Nov 2, 2016 at 12:26 PM, Adam Baso <ab...@wikimedia.org> wrote:

> Reminder, CREDIT will be starting in about 35 minutes.
>
> On Mon, Oct 31, 2016 at 10:55 AM, Adam Baso <ab...@wikimedia.org> wrote:
>
>> Hi!
>>
>> The next CREDIT showcase is in two days - Wednesday, 2-November-2016 at
>> 1800 UTC (1100 San Francisco).
>>
>> https://www.mediawiki.org/wiki/CREDIT_showcase
>>
>> Got a demo? Add it here:
>>
>> https://etherpad.wikimedia.org/p/CREDIT
>>
>> Last month (WebM
>> <https://commons.wikimedia.org/wiki/File:CREDIT_-_October_2016.webm>,
>> YouTube
>> <https://www.youtube.com/watch?v=PCn-oeHQnpU=youtu.be=6>) we
>> saw great demos of a Raspberry Pi based network conditioner, Wikidata
>> credits for maps, extended OCR support for Indic Wikisource projects, an
>> intro to EventBus and ChangePropagation, data visualizations on maps, and
>> an alternative table of contents approach.
>>
>> We're excited to see what's next! Whether you've just launched a new
>> feature or are just getting started with an idea, we welcome demos from
>> Wikimedia community members and staff alike.
>>
>> See you soon. And if you would like to invite anyone to CREDIT, feel
>> free to use this template.
>>
>> *Hi *
>>
>> *I hope all is well with you! I wanted to let you know about CREDIT, a
>> monthly demo series that we’re running to showcase open source tech
>> projects from Wikimedia Community, Reading, Editing, Discovery,
>> Infrastructure and Technology.*
>>
>> *CREDIT is open to the public, and we welcome questions and discussion.
>> The next CREDIT will be held on November 2nd at 11am PT / 2pm ET / 18:00
>> UTC. *
>>
>> *Here’s a link to the YouTube live stream
>> <https://www.youtube.com/watch?v=NmfqtP3pr2Y>, which will be available
>> shortly before the event starts. There’s more info on MediaWiki.org
>> <https://www.mediawiki.org/wiki/CREDIT_showcase>, and on Etherpad
>> <https://etherpad.wikimedia.org/p/CREDIT>, which is where we take notes and
>> ask questions. You can also ask questions on IRC in the Freenode chatroom
>> #wikimedia-office (web-based access here
>> <https://webchat.freenode.net/?channels=%23wikimedia-office>). *
>>
>> *Please feel free to pass this information along to any interested folks.
>> Our projects tend to focus on areas that might be of interest to folks
>> working across the open source tech community: language detection,
>> numerical sort, large data visualizations, maps, and all sorts of other
>> things.*
>>
>> *Thanks, and I hope to see you at CREDIT.*
>>
>>
>>-
>>
>>*YOURNAME*
>>
>>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: CREDIT Showcase in two days - 2-Nov-2016 - call for demos

[Adam Baso]

Cross post to mobile-l and wikitech-ambassadors in case you don't follow
wikitech-l directly. See you at CREDIT!

-Adam


-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Mon, Oct 31, 2016 at 10:55 AM
Subject: CREDIT Showcase in two days - 2-Nov-2016 - call for demos
To: Wikimedia developers <wikitec...@lists.wikimedia.org>


Hi!

The next CREDIT showcase is in two days - Wednesday, 2-November-2016 at
1800 UTC (1100 San Francisco).

https://www.mediawiki.org/wiki/CREDIT_showcase

Got a demo? Add it here:

https://etherpad.wikimedia.org/p/CREDIT

Last month (WebM
<https://commons.wikimedia.org/wiki/File:CREDIT_-_October_2016.webm>,
YouTube <https://www.youtube.com/watch?v=PCn-oeHQnpU=youtu.be=6>)
we saw great demos of a Raspberry Pi based network conditioner, Wikidata
credits for maps, extended OCR support for Indic Wikisource projects, an
intro to EventBus and ChangePropagation, data visualizations on maps, and
an alternative table of contents approach.

We're excited to see what's next! Whether you've just launched a new
feature or are just getting started with an idea, we welcome demos from
Wikimedia community members and staff alike.

See you soon. And if you would like to invite anyone to CREDIT, feel free
to use this template.

*Hi *

*I hope all is well with you! I wanted to let you know about CREDIT, a
monthly demo series that we’re running to showcase open source tech
projects from Wikimedia Community, Reading, Editing, Discovery,
Infrastructure and Technology.*

*CREDIT is open to the public, and we welcome questions and discussion. The
next CREDIT will be held on November 2nd at 11am PT / 2pm ET / 18:00 UTC. *

*Here’s a link to the YouTube live stream
<https://www.youtube.com/watch?v=NmfqtP3pr2Y>, which will be available
shortly before the event starts. There’s more info on MediaWiki.org
<https://www.mediawiki.org/wiki/CREDIT_showcase>, and on Etherpad
<https://etherpad.wikimedia.org/p/CREDIT>, which is where we take notes and
ask questions. You can also ask questions on IRC in the Freenode chatroom
#wikimedia-office (web-based access here
<https://webchat.freenode.net/?channels=%23wikimedia-office>). *

*Please feel free to pass this information along to any interested folks.
Our projects tend to focus on areas that might be of interest to folks
working across the open source tech community: language detection,
numerical sort, large data visualizations, maps, and all sorts of other
things.*

*Thanks, and I hope to see you at CREDIT.*


   -

   *YOURNAME*
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Wikimedia looking for Exploratory QA Tester Contractor

[Adam Baso]

Hi all -

Just wanted to let you know that Wikimedia's Reading
 unit is looking for an exploratory
QA tester contractor to test our Wikipedia apps and web experiences. Please
do share this posting if you know someone!

https://boards.greenhouse.io/wikimedia/jobs/487209?gh_src=w3ekxu1#.WBFOBNzcP_Q

-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: CREDIT in 45 minutes (was: CREDIT Showcase, Wednesday, 5-October-2016 - call for demos)

[Adam Baso]

Link provided below for a video recording.

-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Wed, Oct 5, 2016 at 1:28 PM
Subject: Re: CREDIT in 45 minutes (was: CREDIT Showcase, Wednesday,
5-October-2016 - call for demos)
To: Wikimedia developers <wikitec...@lists.wikimedia.org>


In case you missed it, here's the video!

https://www.youtube.com/watch?v=PCn-oeHQnpU=youtu.be=6

On Wed, Oct 5, 2016 at 12:15 PM, Adam Baso <ab...@wikimedia.org> wrote:

> Reminder, this is happening in about 45 minutes.
>
> On Wed, Sep 28, 2016 at 2:34 PM, Adam Baso <ab...@wikimedia.org> wrote:
>
>> Greetings -
>>
>> The next CREDIT showcase is Wednesday, 5-October-2016 at 1800 UTC (1100
>> San Francisco).
>>
>> https://www.mediawiki.org/wiki/CREDIT_showcase
>>
>> We look forward to seeing your demos! Please add them to the Etherpad and
>> mark your calendars:
>>
>> https://etherpad.wikimedia.org/p/CREDIT
>>
>> We welcome works in progress and would be thrilled to see works from
>> Wikimedia community members, as well as staff.
>>
>> If you missed last month's CREDIT, here it is!
>>
>> https://www.youtube.com/watch?v=rfBQ6H14_SM=54
>>
>> Finally, If you would like to invite anyone to CREDIT, feel free to use
>> this template.
>>
>> *Hi *
>>
>> *I hope all is well with you! I wanted to let you know about CREDIT, a
>> monthly demo series that we’re running to showcase open source tech
>> projects from Wikimedia Community, Reading, Editing, Discovery,
>> Infrastructure and Technology.*
>>
>> *CREDIT is open to the public, and we welcome questions and discussion.
>> The next CREDIT will be held on October 5th at 11am PT / 2pm ET / 18:00
>> UTC. *
>>
>> *Here’s a link to the YouTube live stream
>> <https://www.youtube.com/watch?v=PCn-oeHQnpU>, which will be available
>> shortly before the event starts. There’s more info on MediaWiki.org
>> <https://www.mediawiki.org/wiki/CREDIT_showcase>, and on Etherpad
>> <https://etherpad.wikimedia.org/p/CREDIT>, which is where we take notes and
>> ask questions. You can also ask questions on IRC in the Freenode chatroom
>> #wikimedia-office (web-based access here
>> <https://webchat.freenode.net/?channels=%23wikimedia-office>). *
>>
>> *Please feel free to pass this information along to any interested folks.
>> Our projects tend to focus on areas that might be of interest to folks
>> working across the open source tech community: language detection,
>> numerical sort, large data visualizations, maps, and all sorts of other
>> things.*
>>
>> *Thanks, and I hope to see you at CREDIT.*
>>
>>
>>-
>>
>>*YOURNAME*
>>
>>
>>
>>
>> -Adam
>>
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: CREDIT in 45 minutes (was: CREDIT Showcase, Wednesday, 5-October-2016 - call for demos)

[Adam Baso]

Cross posting. CREDIT in 43 minutes :)

-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Wed, Oct 5, 2016 at 12:15 PM
Subject: CREDIT in 45 minutes (was: CREDIT Showcase, Wednesday,
5-October-2016 - call for demos)
To: Wikimedia developers <wikitec...@lists.wikimedia.org>


Reminder, this is happening in about 45 minutes.

On Wed, Sep 28, 2016 at 2:34 PM, Adam Baso <ab...@wikimedia.org> wrote:

> Greetings -
>
> The next CREDIT showcase is Wednesday, 5-October-2016 at 1800 UTC (1100
> San Francisco).
>
> https://www.mediawiki.org/wiki/CREDIT_showcase
>
> We look forward to seeing your demos! Please add them to the Etherpad and
> mark your calendars:
>
> https://etherpad.wikimedia.org/p/CREDIT
>
> We welcome works in progress and would be thrilled to see works from
> Wikimedia community members, as well as staff.
>
> If you missed last month's CREDIT, here it is!
>
> https://www.youtube.com/watch?v=rfBQ6H14_SM=54
>
> Finally, If you would like to invite anyone to CREDIT, feel free to use
> this template.
>
> *Hi *
>
> *I hope all is well with you! I wanted to let you know about CREDIT, a
> monthly demo series that we’re running to showcase open source tech
> projects from Wikimedia Community, Reading, Editing, Discovery,
> Infrastructure and Technology.*
>
> *CREDIT is open to the public, and we welcome questions and discussion.
> The next CREDIT will be held on October 5th at 11am PT / 2pm ET / 18:00
> UTC. *
>
> *Here’s a link to the YouTube live stream
> <https://www.youtube.com/watch?v=PCn-oeHQnpU>, which will be available
> shortly before the event starts. There’s more info on MediaWiki.org
> <https://www.mediawiki.org/wiki/CREDIT_showcase>, and on Etherpad
> <https://etherpad.wikimedia.org/p/CREDIT>, which is where we take notes and
> ask questions. You can also ask questions on IRC in the Freenode chatroom
> #wikimedia-office (web-based access here
> <https://webchat.freenode.net/?channels=%23wikimedia-office>). *
>
> *Please feel free to pass this information along to any interested folks.
> Our projects tend to focus on areas that might be of interest to folks
> working across the open source tech community: language detection,
> numerical sort, large data visualizations, maps, and all sorts of other
> things.*
>
> *Thanks, and I hope to see you at CREDIT.*
>
>
>-
>
>*YOURNAME*
>
>
>
>
> -Adam
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: CREDIT Showcase, Wednesday, 5-October-2016 - call for demos

[Adam Baso]

Cross posting to mobile-l and wikitech-ambassadors in case you don't follow
wikitech-l.

-Adam



-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Wed, Sep 28, 2016 at 2:34 PM
Subject: CREDIT Showcase, Wednesday, 5-October-2016 - call for demos
To: Wikimedia developers <wikitec...@lists.wikimedia.org>


Greetings -

The next CREDIT showcase is Wednesday, 5-October-2016 at 1800 UTC (1100 San
Francisco).

https://www.mediawiki.org/wiki/CREDIT_showcase

We look forward to seeing your demos! Please add them to the Etherpad and
mark your calendars:

https://etherpad.wikimedia.org/p/CREDIT

We welcome works in progress and would be thrilled to see works from
Wikimedia community members, as well as staff.

If you missed last month's CREDIT, here it is!

https://www.youtube.com/watch?v=rfBQ6H14_SM=54

Finally, If you would like to invite anyone to CREDIT, feel free to use
this template.

*Hi *

*I hope all is well with you! I wanted to let you know about CREDIT, a
monthly demo series that we’re running to showcase open source tech
projects from Wikimedia Community, Reading, Editing, Discovery,
Infrastructure and Technology.*

*CREDIT is open to the public, and we welcome questions and discussion. The
next CREDIT will be held on October 5th at 11am PT / 2pm ET / 18:00 UTC. *

*Here’s a link to the YouTube live stream
<https://www.youtube.com/watch?v=PCn-oeHQnpU>, which will be available
shortly before the event starts. There’s more info on MediaWiki.org
<https://www.mediawiki.org/wiki/CREDIT_showcase>, and on Etherpad
<https://etherpad.wikimedia.org/p/CREDIT>, which is where we take notes and
ask questions. You can also ask questions on IRC in the Freenode chatroom
#wikimedia-office (web-based access here
<https://webchat.freenode.net/?channels=%23wikimedia-office>). *

*Please feel free to pass this information along to any interested folks.
Our projects tend to focus on areas that might be of interest to folks
working across the open source tech community: language detection,
numerical sort, large data visualizations, maps, and all sorts of other
things.*

*Thanks, and I hope to see you at CREDIT.*


   -

   *YOURNAME*




-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] CREDIT Showcase Wednesday, 7-September-2016 - call for demos

[Adam Baso]

Reminder, this is happening in 30 minutes.

On Fri, Sep 2, 2016 at 12:21 PM, Adam Baso <ab...@wikimedia.org> wrote:

> Cross-posting to wikitech-ambassadors and mobile-l in case you don't
> follow the main wikitech-l closely.
>
> -- Forwarded message --
> From: Adam Baso <ab...@wikimedia.org>
> Date: Fri, Sep 2, 2016 at 12:05 PM
> Subject: CREDIT Showcase Wednesday, 7-September-2016 - call for demos
> To: Wikimedia developers <wikitec...@lists.wikimedia.org>
>
>
> Hello!
>
> The next CREDIT showcase is Wednesday, 7-September-2016 at 1800 UTC (1100
> San Francisco).
>
> https://www.mediawiki.org/wiki/CREDIT_showcase
>
> We look forward to seeing your demos! Please add them to the Etherpad and
> mark your calendars:
>
> https://etherpad.wikimedia.org/p/CREDIT
>
> CREDIT is a good place to show off works in progress and rough cuts. We
> welcome Wikimedia community members and staff alike :)
>
> If you haven't been to CREDIT, here are some videos from the last few
> months. Enjoy!
>
> June 2016: https://www.youtube.com/watch?v=0s81r17M-wk
>
> July 2016: https://www.youtube.com/watch?v=BkqPBKPZfOA=yo
> utu.be=46
>
> August 2016: https://www.youtube.com/watch?v=BOj6nDbdPMA=yo
> utu.be=55
>
> -Adam
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: CREDIT Showcase Wednesday, 7-September-2016 - call for demos

[Adam Baso]

Cross-posting to wikitech-ambassadors and mobile-l in case you don't follow
the main wikitech-l closely.

-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Fri, Sep 2, 2016 at 12:05 PM
Subject: CREDIT Showcase Wednesday, 7-September-2016 - call for demos
To: Wikimedia developers <wikitec...@lists.wikimedia.org>


Hello!

The next CREDIT showcase is Wednesday, 7-September-2016 at 1800 UTC (1100
San Francisco).

https://www.mediawiki.org/wiki/CREDIT_showcase

We look forward to seeing your demos! Please add them to the Etherpad and
mark your calendars:

https://etherpad.wikimedia.org/p/CREDIT

CREDIT is a good place to show off works in progress and rough cuts. We
welcome Wikimedia community members and staff alike :)

If you haven't been to CREDIT, here are some videos from the last few
months. Enjoy!

June 2016: https://www.youtube.com/watch?v=0s81r17M-wk

July 2016: https://www.youtube.com/watch?v=BkqPBKPZfOA=youtu.be=46

August 2016: https://www.youtube.com/watch?v=BOj6nDbdPMA=yo
utu.be=55

-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Mobile site is now lazy loading images

[Adam Baso]

Good question - the code tries to fetch the images ahead of them coming
into the viewport. That can mean upon section expansion, as well.

On Tuesday, August 23, 2016, Justin Ormont  wrote:

> This sounds great. Are the images pre-loaded when the user gets close, or
> once it's scrolled into view?
>
> --justin
>
> On Tue, Aug 23, 2016 at 3:48 PM, Volker Eckl  > wrote:
>
>> Amazing work! Enjoying the further speed improvements and the detailed
>> analysis of Japanese Wikipedia testcase.
>>
>> On Tue, Aug 23, 2016 at 2:20 PM, Jon Robson > > wrote:
>>
>>> FYI after much experimentation, research and testing the mobile site has
>>> been lazy loading images [1] since Thursday 18th August. This means if you
>>> do not see an image you will not download it. We have taken care to ensure
>>> users without JavaScript can still view images and that most users will
>>> barely notice the difference.
>>>
>>> We are currently crunching the data this change has made and we plan to
>>> write a blog post to reporting the results.
>>>
>>> In our experiments on Japanese Wikipedia we saw a drop in image bytes
>>> per page view by 54% On the Japanese Japan article bytes shipped to users
>>> dropped from 1.443 MB to 142 kB.
>>>
>>> This is pretty huge since bytes equate to money [3] and we expect this
>>> to be significant on wikis where mobile data is more expensive. In a
>>> nutshell Wikipedia mobile is cheaper.
>>>
>>> As I said blog post to follow once we have more information, but please
>>> report any bugs you are seeing with the implementation (we have already
>>> found a few thanks to our community of editors).
>>>
>>> ~Jon
>>>
>>> [1] https://www.mediawiki.org/wiki/Reading/Web/Projects/Performa
>>> nce/Lazy_loading_images
>>> [2] https://www.mediawiki.org/wiki/Reading/Web/Lazy_loading_
>>> of_images_on_Japanese_Wikipedia
>>> [3] https://whatdoesmysitecost.com/
>>>
>>>
>>>
>>> ___
>>> Mobile-l mailing list
>>> Mobile-l@lists.wikimedia.org
>>> 
>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>>
>>>
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> 
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Reading team updates from last quarter and planning for next quarter

[Adam Baso]

Thanks, Nemo. The rollout is for the lazy loaded images, not the
combination of lazy loaded images and on-demand references. Looks the URL
needs an update. Here's analysis from, for example, ja.m.wikipedia.org for
the lazy loaded images piece.

https://www.mediawiki.org/wiki/Reading/Web/Lazy_loading_of_images_on_Japanese_Wikipedia

We need to further analyze the page load time and data transfer aspect of
on-demand references, in addition to further weighing considerations like
the ones you mention.

-Adam


On Tue, Aug 9, 2016 at 6:16 PM, Federico Leva (Nemo) 
wrote:

> Deferring the loading of images is fine, but doing the same for references
> raises tons of questions. I wrote down the most obvious ones to start with:
> https://www.mediawiki.org/wiki/Talk:Reading/Web/Projects/
> Performance/Lazy_loading_references
>
> Nemo
>
> Moushira Elamrawy, 10/08/2016 00:44:
>
>> Good day everyone,
>>
>> Planning for the next quarter is coming soon,  if you have relevant
>> ideas that the reading team  can
>> consider to work on for the upcoming 3 months, please add them to the
>> page here
>> > >[0].
>> The page has archives for quarterly planning from previous months, and
>> you can review ideas from last quarter here
>> > >[1]
>>
>> There is also a summary for Reading team updates during the last quarte
>> > 2016_-_July_2016>r
>> [2], major highlights include, a) Lazy loading of images
>> > ance/Lazy_loading_references>,[3]
>> b) new readers ,[4] c) and
>> the move of the language switching button on mobile.
>>
>> Hope that was helpful,  looking forward to your ideas and input!
>>
>> Regards,
>> Moushira
>>
>>
>> [0] https://www.mediawiki.org/wiki/Reading/Quarterly_planning/
>> FY2016-2017/Q2
>> [1] https://www.mediawiki.org/wiki/Reading/Quarterly_planning/
>> FY2016-2017/Q1
>> [2]
>> https://www.mediawiki.org/wiki/Reading_team_updates_April_
>> 2016_-_July_2016
>> [3]
>> https://www.mediawiki.org/wiki/Reading/Web/Projects/Performa
>> nce/Lazy_loading_references
>> [4] https://meta.wikimedia.org/wiki/New_Readers
>>
>>
>>
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Analytics] [Pageview API] Data Retention Question

[Adam Baso]

Cross posting.

-- Forwarded message --
From: *Dan Andreescu* 
Date: Friday, July 29, 2016
Subject: [Analytics] [Pageview API] Data Retention Question
To: Analytics List 


Dear Pageview API consumers,

We would like to plan storage capacity for our pageview API cluster.  Right
now, with a reliable RAID setup, we can keep *18 months* of data.  If you'd
like to query further back than that, you can download dump files (which
we'll make easier to use with python utilities).

What do you think?  Will you need more than 18 months of data?  If so, we
need to add more nodes when we get to that point, and that costs money, so
we want to check if there is a real need for it.

Another option is to start degrading the resolution for older data (only
keep weekly or monthly for data older than 1 year for example).  If you
need more than 18 months, we'd love to hear your use case and something in
the form of:

need daily resolution for 1 year
need weekly resolution for 2 years
need monthly resolution for 3 years

Thank you!

Dan
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Scaling with Edge Caching at Wikimedia

[Adam Baso]

WMF's Emanuele Rocca talks at VarnishCon about how we scale to hundreds of
millions of users:

https://www.infoq.com/fr/presentations/varnishcon-emanuele-rocca-scaling-wikipedia

Enjoy!

-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] mobile-l：您...

[Adam Baso]

I have attempted to filter this forged sender.
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Mobile Content Service Phab board workflow

[Adam Baso]

Migrating thread to mobile-l.

-- Forwarded message --
From: Max Binder 
Date: Fri, May 20, 2016 at 3:58 PM
Subject: Mobile Content Service Phab board workflow


Hey iOS/Web/Android,

The MCS Phab board[1] used to have "Doing" and "Code Review" columns. This
was somewhat redundant with existing workboards, notably Android's sprint
boards (Android has been the primary contributor to MCS, but doesn't
officially own the work). It was weird to move the same task into "Doing"
and "Code Review" on different boards, so we simplified the flow and
removed the "Doing" and "Code Review" columns from MCS's Phab board.

What this means for you: *If you do MCS work, tag the task with your own
team's workboard.* For Android and Web, this means tagging it with your
sprint board. For iOS, this means tagging it with your release board. As
always, talk with your POs and teammates before pulling in work.

As the work is resolved in sprint/release boards, the tasks will also
disappear from the MCS board (same as the relationship that tasks have
between backlogs and sprints). If you're looking at the MCS board, you'll
be able to tell if a task is in-flight by noting the tags on the tasks on
the boardview. For example, tags for "Mobile-App-Android-Sprint-82-Lead"
and "Patch-for-Review" would indicate that a task is in-flight on Android's
sprint board, and in code review.

This will prevent redundancy of process, and will also let POs on each team
know what their team's devs are working on without having to hunt down MCS
tasks in Phab.

Please reach out with any questions.

Max


[1] https://phabricator.wikimedia.org/tag/mobile-content-service/
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [IEEE-BIZ2016] Invitation for Participation

[Adam Baso]

I apologize, I had banned the spammer, but not the user. Hopefully this is
the last o this spam.

On Sun, May 15, 2016 at 6:27 PM, Lubna Kanan  wrote:

> ***
> We apologize for multiples copies. Please circulate this CFP among your
> colleagues and students.
> ***
>
> 2016 Second International Conference on Big-data, Internet of things,
> nd Zero-size intelligence [BIZ]
>
> July 26-28, 2016
>
> Manchester, United Kingdom
>
> http://sdiwc.net/conferences/biz2016/
>
> All registered papers will be submitted to IEEE for potential inclusion to
> IEEE Xplore
>
> ***
> Paper due:  June 26, 2016
> ***
>
> The proposed conference will be held University of Salford, MediaCityUK,
> Manchester, United Kingdom, From July 26-28, 2016 which aims to enable
> researchers build connections between different digital applications.
>
> The conference welcomes papers on the following (but not limited to)
> research topics:
>
> - Foundational Models for Big Data
> - Algorithms and Programming Techniques for Big Data Processing
> - Big Data Analytics and Metrics
> - Representation Formats for Multimedia Big Data
> - Big Data Architectures
> - Cloud Computing Techniques for Big Data
> - Big Data as a Service
> - Big Data Open Platforms
> - Big Data in Mobile and Pervasive Computing
> - Big Data Management
> - Big Data Persistence and Preservation
> - Big Data Quality and Provenance Control
> - Management Issues of Social Network enabled Big Data
> - Big Data Protection, Integrity and Privacy
> - Models and Languages for Big Data Protection
> - Privacy Preserving Big Data Analytics Big Data Encryption
> - Security Applications of Big Data
> - Anomaly Detection in Very Large Scale Systems
> - Collaborative Threat Detection using Big Data Analytics
> - Big Data Search and Mining
> - Algorithms and Systems for Big Data Search
> - Distributed, and Peer-to-peer Search
> - Machine learning based on Big Data
> - Visualization Analytics for Big Data
> - Big Data for Enterprise
> - Big Data Economics
> - Real-life Case Studies of Value Creation through Big Data Analytics
> - Big Data for Business Model Innovation
> - Big Data Toolkits
> - Big Data in Business Performance Management
> - SME-centric Big Data Analytics
> - Big Data for Vertical Industries (Government, Healthcare, and
> Environment)
> - Scientific Applications of Big Data
> - Large-scale Social Media and Recommendation Systems
> - Experiences with Big Data Project Deployments
> - Big Data in Enterprise Management Models and Practices
> - Big Data in Government Management Models and Practices
> - Big Data in Smart Planet Solutions
> - Big Data for Enterprise Transformation
>
>
> ***
> The conference uses double-blind review by at least two reviewers,
> which means that both the reviewer and author identities are concealed
> from the reviewers, and vice versa, throughout the review process.
> To facilitate this, authors need to ensure that their manuscripts are
> prepared in a way that does not give away their identity.
>
> All the registered papers will be submitted to IEEE for potential
> inclusion
> to IEEE Xplore as well as other Abstracting and Indexing (A) databases.
> In addition, BEST registered papers will be published in one of the
> following
> special issues provided that the author do major improvements and
> extension
> within the time frame that will be set by the conference and his/her paper
> is approved by the chief editor:
>
> * International Journal of New Computer Architectures and their
> Applications (IJNCAA)
> * International Journal of Digital Information and Wireless Communications
> (IJDIWC)
> * International Journal of Cyber-Security and Digital Forensics (IJCSDF)
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Cross-post: Today's CREDIT showcase - video

[Adam Baso]

In case you don't follow wikitech-l.

-Adam


-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Thu, May 12, 2016 at 8:34 PM
Subject: Today's CREDIT showcase - video
To: Wikimedia developers <wikitec...@lists.wikimedia.org>


Here's video from today's 12-May-2016 CREDIT showcase
<https://www.mediawiki.org/wiki/CREDIT_showcase>.

https://www.youtube.com/watch?v=GwTDDWjxoek=youtu.be=7

https://commons.wikimedia.org/wiki/File:CREDIT_-_May_2016.webm

== Contents ==

* Derk-Jan Hartman: Video.js progress
* Dmitry Brant: Wikidata infoboxes in Android app
* Joaquin Hernandez: Vicky chat bot
* Baha: mobile printing for offline reading
* Monte: "smart random" content service endpoint
* Erik: Geo boosting search queries
* Julien: Maps for Wikivoyage

Thanks!
-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [IEEE-CyberSec2016] Invitation for Participation

[Adam Baso]

Done.

On Wed, May 11, 2016 at 9:58 PM, Tilman Bayer  wrote:

> Is it possible to block this spam?
>
> Note that this organization (SDIWC) is listed at
> http://scholarlyoa.com/publishers/ (cf.
> https://en.wikipedia.org/wiki/Predatory_open_access_publishing ).
>
> On Wed, May 11, 2016 at 3:39 PM, Lubna Kanan 
> wrote:
> >
> ***
> > We apologize for multiples copies. Please circulate this CFP among your
> > colleagues and students.
> >
> ***
> >
> > 2016 Fifth International Conference on Cyber Security, Cyber Warfare,
> > and Digital Forensic [CyberSec]
> >
> > July 26-28, 2016
> >
> > Manchester, United Kingdom
> >
> > http://sdiwc.net/conferences/cybersec2016/
> >
> > All registered papers will be submitted to IEEE for potential inclusion
> to
> > IEEE Xplore
> >
> >
> ***
> > Paper due:  June 26, 2016
> >
> ***
> >
> > The proposed conference will be held University of Salford, MediaCityUK,
> > Manchester, United Kingdom, From July 26-28, 2016 which aims to enable
> > researchers build connections between different digital applications.
> >
> > The conference welcomes papers on the following (but not limited to)
> > research topics:
> >
> > **Cyber Security
> > - Distributed and Pervasive Systems Security
> > - Enterprise Systems Security
> > - Formal Methods Application in Security
> > - Hardware-Based security
> > - Incident Handling and Penetration Testing
> > - Legal Issues
> > - Multimedia and Document Security
> > - Operating Systems and Database Security
> > - Privacy issues
> > - SCADA and Embedded systems security
> > - Secure Software Development, Architecture and Outsourcing
> > - Security for Future Networks
> > - Security in Cloud Computing
> > - Security in Social Networks
> > - Security of Web-based Applications and Services
> > - Security protocols
> > - VOIP, Wireless and Telecommunications Network Security
> > **Digital Forensic
> > - Anti-Forensics and Anti-Anti-Forensics Techniques
> > - Cyber-Crimes
> > - Data leakage, Data protection and Database forensics
> > - Evidentiary Aspects of Digital Forensics
> > - Executable Content and Content Filtering
> > - File System and Memory Analysis Multimedia Forensic
> > - Forensics of Virtual and Cloud Environments
> > - Information Hiding
> > - Investigation of Insider Attacks
> > - Large-Scale Investigations
> > - Malware forensics and Anti-Malware techniques
> > - Network Forensics and Traffic Analysis Hardware Vulnerabilities and
> Device
> > Forensics
> > - New threats and Non-Traditional approaches
> > **Information Assurance and Security Management
> > - Business Continuity & Disaster Recovery Planning
> > - Corporate Governance
> > - Critical Infrastructure Protection
> > - Decidability and Complexity
> > - Digital Rights Management and Intellectual Property Protection
> > - Economics of Security
> > - Fraud Management
> > - Identity Management
> > - Laws and Regulations
> > - Security Policies and Trust Management
> > - Threats, Vulnerabilities, and Risk Management
> > **Cyber warfare and Physical Security
> > - Surveillance Systems
> > - Biometrics Applications
> > - Cyber Warfare Trends and Approaches
> > - Electronic Passports, National ID and Smart Card Security
> > - Social engineering
> > - Template Protection and Liveliness detection
> > - Authentication and Access Control Systems
> > - Biometrics standards and standardization
> > - New theories and algorithms in biometrics
> >
> >
> ***
> > The conference uses double-blind review by at least two reviewers,
> > which means that both the reviewer and author identities are concealed
> > from the reviewers, and vice versa, throughout the review process.
> > To facilitate this, authors need to ensure that their manuscripts are
> > prepared in a way that does not give away their identity.
> >
> > All the registered papers will be submitted to IEEE for potential
> inclusion
> > to IEEE Xplore as well as other Abstracting and Indexing (A) databases.
> > In addition, BEST registered papers will be published in one of the
> > following
> > special issues provided that the author do major improvements and
> extension
> > within the time frame that will be set by the conference and his/her
> paper
> > is approved by the chief editor:
> >
> > * International Journal of New Computer Architectures and their
> Applications
> > (IJNCAA)
> > * International Journal of Digital Information and Wireless
> Communications
> > (IJDIWC)
> > * International Journal of Cyber-Security and Digital Forensics (IJCSDF)
> >
> > ___
> > Mobile-l mailing list
> > 

[WikimediaMobile] Fwd: [Wikitech-l] ArchCom RFC update #6

[Adam Baso]

Cross posting in case you don't follow wikitech-l.The following looks to be
up for discussion today on #wikimedia-office:

*** T122942: RFC: Support language variants in the REST API


-- Forwarded message --
From: Rob Lanphier 
Date: Mon, Apr 25, 2016 at 6:19 PM
Subject: [Wikitech-l] ArchCom RFC update #6
To: Wikimedia developers 


Hi everyone,

Here is the RFC status update from last week's ArchCom meeting (E165).
This is pretty much what is posted on-wiki [1], where everything has
links.

Rob



 Today's IRC session 
** April 20 [[Phab:E66/31]]
*** T91162: RFC: Shadow namespaces

 Queue for future RfC office hours 
** April 27: [[Phab:E66/32]]
*** T122942: RFC: Support language variants in the REST API
** May 4: [[Phab:E66/33]]
*** T130528: RFC: PSR-6 Cache interface in Mediawiki core

 Under discussion 
:Daniel: [[Phab:T124752]]
::Let’s turn the “Changes Tags” refactoring proposed by
[
https://gerrit.wikimedia.org/r/#/q/owner:cenarium.sysop%2540gmail.com+status:open,n,z
Cenarium] into an RFC and get it unstuck. Chain of patches starts at
https://gerrit.wikimedia.org/r/#/c/201905/64; The patch refers to
[[Phab:T91535]] but the topic is broader than that, and the ticket
doesn’t fully describe the proposed solution. Needs work.
: Tim: shepherding two for Parser. will pick another
: Roan: [[Phab:T108655]] still need to split it so discussion can take
place on part 2

 Other status 
The "RFC inbox" was empty, nothing "Entering Final Comment Period",
and we didn't discuss the "no activity" list

[1]
https://www.mediawiki.org/wiki/Architecture_committee/2016-04-20#RFC_status_update

___
Wikitech-l mailing list
wikitec...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Different testing approaches

[Adam Baso]

Hi there - I had a follow up action from a backlog grooming meeting today
regarding https://phabricator.wikimedia.org/T133023.

We're taking the discussion about this task to mobile-l and qa where we can
make sure our discussion is documented and also get some additional
opinions.

Proper test coverage and test coverage maintenance is a mildly complex
topic, to put it lightly, but let's see if we can discuss here on mobile-l
and qa lists and figure out how to tackle these sorts of tasks.

-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Cross post: CREDIT showcase Wednesday, 6-April-2016

[Adam Baso]

-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Wed, Mar 30, 2016 at 11:30 AM
Subject: Reminder: CREDIT showcase Wednesday, 6-April-2016
To: Wikimedia developers <wikitec...@lists.wikimedia.org>


Hello world -

Reminder: the next CREDIT showcase will be 6-April-2016 at 1800 UTC (1100
SF).

Looking forward to your demos! Please see the following links for
information and to add your demo :)

https://www.mediawiki.org/wiki/CREDIT_showcase

https://etherpad.wikimedia.org/p/CREDIT

-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Usage of correct diacritics in readers of Romanian Wikipedia

[Adam Baso]

Strainu, thanks for sending the message. I forgot to say - maybe a good
idea to email analyt...@lists.wikimedia.org as well (e.g., to discuss Event
Logging). I think I've seen you over on that list before :)

On Fri, Mar 11, 2016 at 7:50 AM, Strainu  wrote:

> Hi,
>
> I have proposed a new research project about the support for correct
> diacritics in the readers of the Romanian Wikipedia [1]. The plan I
> made is (probably) limited to the desktop site, but Adam suggested
> there might be some overlap with the work you are doing around
> emerging communities. So, if someone is interested in extending the
> study to mobile users or you have any feedback on the project, please
> leave a message on the talk page or contact me by email.
>
> Thanks,
>   Strainu
>
> P.S. Please keep me in the CC for any responses, as I don't get emails
> from mobile-l.
>
>
> [1]
> https://meta.wikimedia.org/wiki/Research:Usage_of_correct_diacritics_in_readers_of_Romanian_Wikipedia
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] iOS App Release

[Adam Baso]

Excellent work, all.

On Thu, Mar 10, 2016 at 8:19 PM, Joshua Minor  wrote:

> Hello again mobile wikimedians,
>
> This morning the 5.0.0 update to the Wikipedia Mobile iOS app went live on
> the App Store[1]. As previously described on list[2], and on wiki[3], this
> is a major overhaul to the app, focusing on making a great browsing, search
> and reading experience for app users.
>
> Features include:
>
>- New Explore feed for browsing and discovering content
>- Simplified and touch friendly navigation, including 3D touch
>shortcuts
>- Convenient multilingual search, and integration with iOS Spotlight
>- Clean and modern visual design and reading experience
>
> For more, check out this WMF blog post[4] or watch this short demo video
> on Commons[5].
>
> We've also been getting very positive press in many tech news outlets,
> including:
>
>- Venture Beat [6]
>- Engadget [7]
>- The Next Web [8]
>
> 5.0.0 is just the beginning of a new road to making an iOS app Wikipedians
> and can be really proud of, and readers will love. We know we have
> longstanding needs like text size adjustment and find-in-page that are
> still missing. We also need to get better at accessibility. And, sadly, our
> editing features remain minimal. But,we think this is a solid foundation we
> can build on.
>
> This was truly a team effort by the WMF iOS team, and many other staff
> (particular thanks to Communications, Research and Analytics). And of
> course thanks again to our code contributors, translators and beta testers.
>
> Feedback can be sent from in the app (open the Settings, then tap "Write
> to us"), chat us on freenode IRC at #wikimedia-ios, or  talk on our team's
> MediaWiki page[9].
>
> [1] - https://itunes.apple.com/us/app/wikipedia-mobile/id324715238?mt=8
> [2] -
> https://lists.wikimedia.org/pipermail/mobile-l/2015-December/010011.html
> [3] -  https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Why_5
> [4] - https://blog.wikimedia.org/2016/03/10/new-wikipedia-app-ios/
> [5] -
> https://upload.wikimedia.org/wikipedia/commons/6/68/Wikipedia_Mobile_5.0_for_iPhone_and_iPad.webm
> [6] -
> http://thenextweb.com/apps/2016/03/10/wikipedias-new-redesigned-ios-app-full-neat-factoids/
> [7] - http://www.engadget.com/2016/03/10/wikipedia-ios-app-redesigned/
> [8] -
> http://techcrunch.com/2016/03/10/wikipedias-new-ios-app-focuses-on-discovery-personalization/
> [9] - https://www.mediawiki.org/wiki/Talk:Wikimedia_Apps/Team/iOS
>
>
> Cheers,
> Josh Minor
> Product Manager
> Wikimedia Foundation
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Wikimedia-l] Wikimedia Foundation Draft Strategy

[Adam Baso]

Cross posting, in case you don't subscribe to wikimedia-l.


-- Forwarded message --
From: James Alexander 
Date: Fri, Mar 4, 2016 at 8:20 PM
Subject: [Wikimedia-l] Wikimedia Foundation Draft Strategy
To: Wikimedia Mailing List 


Hi all,

The draft Wikimedia Foundation strategy is now posted on Meta
 for your
feedback and comments[1]. This stage of feedback will be open between now
and March 18, 2016. Please note that WMF Staff will not be able to start
responding to comments until Monday (March 7th) so know that the lack of
comments over the weekend  is not a sign that you're being ignored :). We
welcome and appreciate any translations you are able to give for the draft
as well so that it can be read and understood by as many people as possible.

*Next steps*:

   - During March, the Wikimedia Foundation will use this proposed strategy
   to finalize its draft 2016-2017 Annual Plan.
   - Between March 18th and April 1st we will review and integrate your
   feedback from the draft strategy into the draft Annual Plan as
appropriate.
   - On April 1st, The Wikimedia Foundation’s draft annual plan will then
   be submitted for comment.


1, https://meta.wikimedia.org/wiki/2016_Strategy/Draft_WMF_Strategy

Thank you again for your feedback earlier that led to this draft and for
your comments in this stage,

James Alexander
Manager
Trust & Safety
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: wikimedi...@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Wikitech-l] RFC meeting (E147): Notifications in core & define an official thumb API

[Adam Baso]

Interesting RFC discussions tomorrow.


-- Forwarded message --
From: Rob Lanphier 
Date: Sun, Mar 6, 2016 at 10:36 PM
Subject: [Wikitech-l] RFC meeting (E147): Notifications in core & define an
official thumb API
To: Wikimedia developers 


Hi everyone,

We plan to discuss two RFCs at the 2016-03-09 RFC Meeting (22:00 UTC on
Wednesday):

   - T128351  RfC: Notifications
   in core
  - @brion  is shepherding,
  and would like to confirm rough consensus for moving some of the
Echo code
  into core
  - T66214 : Use content hash
   based image / thumb URLs & define an official thumb API
  - Based on the 2016-03-02 ArchCom meeting
  
  and what he said in T66214#2087161
  , I believe @GWicke
   hopes we can reach
  consensus on the format of a thumb API, possibly putting that aspect
into
  last call.

Details about the meeting are in Phabricator:
https://phabricator.wikimedia.org/E147

Hope to see y'all there!

Rob
___
Wikitech-l mailing list
wikitec...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Analytics] [Eventlogging] Dropping Client IPs from EventCapsule

[Adam Baso]

Cross-posting.

-- Forwarded message --
From: Madhumitha Viswanathan 
Date: Wed, Mar 2, 2016 at 12:18 PM
Subject: [Analytics] [Eventlogging] Dropping Client IPs from EventCapsule
To: "A mailing list for the Analytics Team at WMF and everybody who has an
interest in Wikipedia and analytics." ,
Development and Operations Engineers 


Hi all,

The analytics team, in an effort to collect sensitive data less, plans to
drop the clientIP field from the EventCapsule(
https://meta.wikimedia.org/wiki/Schema:EventCapsule), which is the wrapper
for all events flowing into Eventlogging (Currently IPs and User Agents get
purged after the 90 days mark). The field was originally meant only for
debugging, but has served some research usecases. Most of these cases have
been wrapped up at this point. It has also been used as a proxy to count
number of devices visiting sites like our blog - and since IP's are not a
good measure of that anyway - we plan to move such cases to use Piwik.

The rollout of the change will happen in stages (Drop clientIPs first on
the EL end, then the EventCapsule in meta, and finally on the VarnishKafka
end). It should be a clean deployment and there's no scheduled downtime -
EL will keep working as is. What does change? ClientIP's will start being
set as NULL in your mysql tables. If you update the Eventlogging schema you
maintain - causing new tables to be created, the new tables will not have
the clientIp field in them. The change is planned to be rolled out the week
of 11th or 18th March '16, pending the completion of data collection for
the ongoing QuickSurveys based research work.

Let us know if you have any questions/concerns on the list or on
#wikimedia-analytics. The related phab ticket is here -
https://phabricator.wikimedia.org/T128407.

Thanks,
Madhu Viswanathan
Software Engineer, Analytics

___
Analytics mailing list
analyt...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Reading-web-team] language switcher

[Adam Baso]

Forwarding to mobile-l for people with an interest in language switching on
the mobile web.

-Adam

-- Forwarded message --
From: Jon Katz 


Team,
After a productive engagement with the community around improving language
switching options on mobile web, I have posted the 'final' design on wiki...

https://www.mediawiki.org/wiki/Reading/Web/Projects/Improve_in-article_language_switching_on_mobile_web#Final_Design_Based_on_Feedback

Props to Nirzar for a fast turn-around.
-J
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Wikitech-l] Per-language URLs for multilingual wikis (RFC T114662)

[Adam Baso]

This looks particularly interesting if language variants are on your radar.

-- Forwarded message --
From: *Daniel Kinzler* 
Date: Friday, February 5, 2016
Subject: [Wikitech-l] Per-language URLs for multilingual wikis (RFC T114662)
To: Wikimedia developers 


Hi all!

During next Wednesday's RFC meeting on IRC, we are planning to discuss
introducing "Per-language URLs for pages of multilingual wikis". This is an
exploratory discussion, with no expectation of a final decision. We are
looking
for concerns and suggestions.

If you care about improved support for multi-lingual wikis, please visit
 and comment before next week's
"live" meeting on IRC. And of yourse, join that meeting, if you like!

Thanks,
Daniel


PS: Don't want to click the link? Let me copy that for you... but
please
comment on phab rather than here.


Context:
Some wikis show page content depending on the user's interface language (for
instance wikidata.org and commons.wikimedia.org, or other wikis using the
Translate extension). All language versions (renderings) of a page are
served
from the same URL, which is problematic for web caching. This is the reason
we
currently do not allow anonymous users to change their interface language.
This
makes it hard for use multilingual wikis without logging in.

See also for context:
* {T114640}

Proposal:
* For multilingual wikis, the user language is part of the request path:
e.g. we
would use `/wiki-de/` instead of `/wiki/`.
* The plain `/wiki/` path would act as a 302 redirect to the language
specific
path (based on the user's language, or a best guess or cookie as
implemented by ULS)
* When viewing a page via a language-specific path, all links on the page
(both
content and skin) point to pathes specific to that language. Both content
and
skin are shown in the user's ui language (as far as possible, using whatever
mechanism for content translation or internationalization is available)
* When viewing a page in a language different from the user's preferred
language
(according to user preferences or the cookie set by ULS), a warnign bar is
shown
at the top, giving the user the option to
## switch to the version in their own language (according to user
preference)
## change their user language to the current page's language
## hide the bar for a while (a day, or the browser session, or so).

Challanges:
* Make the Linker class aware of the target language (probably needs a
complete
refactoring), so it generates links to the right path.
* Make all code that generates links in the skin use the Linker class
(directly,
or via the Parser), so the path is consistent.
* Allow efficient purging of the entire "bundle" of all the renderings of a
given page when the page's content changes.
* Should translated names for namespaces and special pages be supported on
the
language specific pathes? (would be nice, but tricky)
* Provide a way to explicitly link to a specific language rendering from
wikitext, e.g. `{{#link|Foo|lang=de-ch}}`

___
Wikitech-l mailing list
wikitec...@lists.wikimedia.org 
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] PageImages Tech Meeting Scheduled (was: Similar articles feature performance in CirrusSearch for apps and mobile web)

[Adam Baso]

By the way, a meeting has been scheduled for 1920 UTC on Thursday,
4-February-2016 to go into technical specifics on PageImages.

Email me off list if you'd like to be added to the meeting.

-Adam

-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Sat, Jan 30, 2016 at 8:11 AM
Subject: Re: [WikimediaMobile] Similar articles feature performance in
CirrusSearch for apps and mobile web
To: Erik Bernhardson <ebernhard...@wikimedia.org>
Cc: Joaquin Oltra Hernandez <jhernan...@wikimedia.org>, mobile-l <
mobile-l@lists.wikimedia.org>


Okay. As per https://phabricator.wikimedia.org/T124225#1984080 I think if
we're doing near term experimentation with a controlled A/B test the
Android app is the only logical place to start. Dmitry, can that work for
you? It's not required, but I think it would be neat to see if we can move
the needle even more. Of course your quarterly goals take top
priority...but what do you think?

On Sat, Jan 23, 2016 at 5:58 AM, Adam Baso <ab...@wikimedia.org> wrote:

> Hey all, am planning to look at Phabricator tasks and provide a reply
> during the upcoming weekdays. Just wanted to acknowledge I saw your replies!
>
>
> On Friday, January 22, 2016, Erik Bernhardson <ebernhard...@wikimedia.org>
> wrote:
>
>> On Thu, Jan 21, 2016 at 1:29 AM, Joaquin Oltra Hernandez <
>> jhernan...@wikimedia.org> wrote:
>>
>>> Regarding the caching, we would need to agree between apps and web about
>>> the url and smaxage parameter as Adam noted so that the urls are
>>> *exactly* the same to not bloat varnish and reuse the same cached
>>> objects across platforms.
>>>
>>> It is an extremely adhoc and brittle solution but seems like it would be
>>> the greatest win.
>>>
>>> 20% of the traffic from searches by being only in android and web beta
>>> seems a lot to me, and we should work on reducing it, otherwise when it
>>> hits web stable we're going to crush the servers, so caching seems the
>>> highest priority.
>>>
>>> To clarify its 20% of the load, as opposed to 20% of the traffic. But
>> same difference :)
>>
>>
>>> Let's chime in https://phabricator.wikimedia.org/T124216 and continue
>>> the cache discussion there.
>>>
>>> Regarding the validity of results with opening text only, how should we
>>> proceed? Adam?
>>>
>>> I've put together https://phabricator.wikimedia.org/T124258 to track
>> putting together an AB test that measures the difference in click through
>> rates for the two approaches.
>>
>>
>>
>>> On Wed, Jan 20, 2016 at 9:34 PM, David Causse <dcau...@wikimedia.org>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Yes we can combine many factors, from templates (quality but also
>>>> disambiguation/stubs), size and others.
>>>> Today cirrus uses mostly the number of incoming links which (imho) is
>>>> not very good for morelike.
>>>> On enwiki results will also be scored according the weights defined in
>>>> https://en.wikipedia.org/wiki/MediaWiki:Cirrussearch-boost-templates.
>>>>
>>>> I wrote a small bash to compare results :
>>>> https://gist.github.com/nomoa/93c5097e3c3cb3b6ebad
>>>> Here is some random results from the list (Semetimes better, sometimes
>>>> worse) :
>>>>
>>>> $ sh morelike.sh Revolution_Muslim
>>>> Defaults
>>>> "title": "Chess",
>>>> "title": "Suicide attack",
>>>> "title": "Zachary Adam Chesser",
>>>> ===
>>>> Opening text no boost links
>>>> "title": "Hungarian Revolution of 1956",
>>>> "title": "Muslims for America",
>>>> "title": "Salafist Front",
>>>>
>>>> $ sh morelike.sh Chesser
>>>> Defaults
>>>> "title": "Chess",
>>>> "title": "Edinburgh",
>>>> "title": "Edinburgh Corn Exchange",
>>>> ===
>>>> Opening text no boost links
>>>> "title": "Dreghorn Barracks",
>>>> "title": "Edinburgh Chess Club",
>>>> "title": "Threipmuir Reservoir",
>>>>
>>>> $ sh morelike.sh Time_%28disambiguation%29
>>>> Defaults
>>>>

Re: [WikimediaMobile] Similar articles feature performance in CirrusSearch for apps and mobile web

[Adam Baso]

Okay. As per https://phabricator.wikimedia.org/T124225#1984080 I think if
we're doing near term experimentation with a controlled A/B test the
Android app is the only logical place to start. Dmitry, can that work for
you? It's not required, but I think it would be neat to see if we can move
the needle even more. Of course your quarterly goals take top
priority...but what do you think?

On Sat, Jan 23, 2016 at 5:58 AM, Adam Baso <ab...@wikimedia.org> wrote:

> Hey all, am planning to look at Phabricator tasks and provide a reply
> during the upcoming weekdays. Just wanted to acknowledge I saw your replies!
>
>
> On Friday, January 22, 2016, Erik Bernhardson <ebernhard...@wikimedia.org>
> wrote:
>
>> On Thu, Jan 21, 2016 at 1:29 AM, Joaquin Oltra Hernandez <
>> jhernan...@wikimedia.org> wrote:
>>
>>> Regarding the caching, we would need to agree between apps and web about
>>> the url and smaxage parameter as Adam noted so that the urls are
>>> *exactly* the same to not bloat varnish and reuse the same cached
>>> objects across platforms.
>>>
>>> It is an extremely adhoc and brittle solution but seems like it would be
>>> the greatest win.
>>>
>>> 20% of the traffic from searches by being only in android and web beta
>>> seems a lot to me, and we should work on reducing it, otherwise when it
>>> hits web stable we're going to crush the servers, so caching seems the
>>> highest priority.
>>>
>>> To clarify its 20% of the load, as opposed to 20% of the traffic. But
>> same difference :)
>>
>>
>>> Let's chime in https://phabricator.wikimedia.org/T124216 and continue
>>> the cache discussion there.
>>>
>>> Regarding the validity of results with opening text only, how should we
>>> proceed? Adam?
>>>
>>> I've put together https://phabricator.wikimedia.org/T124258 to track
>> putting together an AB test that measures the difference in click through
>> rates for the two approaches.
>>
>>
>>
>>> On Wed, Jan 20, 2016 at 9:34 PM, David Causse <dcau...@wikimedia.org>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Yes we can combine many factors, from templates (quality but also
>>>> disambiguation/stubs), size and others.
>>>> Today cirrus uses mostly the number of incoming links which (imho) is
>>>> not very good for morelike.
>>>> On enwiki results will also be scored according the weights defined in
>>>> https://en.wikipedia.org/wiki/MediaWiki:Cirrussearch-boost-templates.
>>>>
>>>> I wrote a small bash to compare results :
>>>> https://gist.github.com/nomoa/93c5097e3c3cb3b6ebad
>>>> Here is some random results from the list (Semetimes better, sometimes
>>>> worse) :
>>>>
>>>> $ sh morelike.sh Revolution_Muslim
>>>> Defaults
>>>> "title": "Chess",
>>>> "title": "Suicide attack",
>>>> "title": "Zachary Adam Chesser",
>>>> ===
>>>> Opening text no boost links
>>>> "title": "Hungarian Revolution of 1956",
>>>> "title": "Muslims for America",
>>>> "title": "Salafist Front",
>>>>
>>>> $ sh morelike.sh Chesser
>>>> Defaults
>>>> "title": "Chess",
>>>> "title": "Edinburgh",
>>>> "title": "Edinburgh Corn Exchange",
>>>> ===
>>>> Opening text no boost links
>>>> "title": "Dreghorn Barracks",
>>>> "title": "Edinburgh Chess Club",
>>>> "title": "Threipmuir Reservoir",
>>>>
>>>> $ sh morelike.sh Time_%28disambiguation%29
>>>> Defaults
>>>> "title": "Atlantis: The Lost Empire",
>>>> "title": "Stargate",
>>>> "title": "Stargate SG-1",
>>>> ===
>>>> Opening text no boost links
>>>> "title": "Father Time (disambiguation)",
>>>> "title": "The Last Time",
>>>> "title": "Time After Time",
>>>>
>>>>
>>>>
>>>>
>>>&g

Re: [WikimediaMobile] Similar articles feature performance in CirrusSearch for apps and mobile web

[Adam Baso]

Hey all, am planning to look at Phabricator tasks and provide a reply
during the upcoming weekdays. Just wanted to acknowledge I saw your replies!

On Friday, January 22, 2016, Erik Bernhardson <ebernhard...@wikimedia.org>
wrote:

> On Thu, Jan 21, 2016 at 1:29 AM, Joaquin Oltra Hernandez <
> jhernan...@wikimedia.org
> <javascript:_e(%7B%7D,'cvml','jhernan...@wikimedia.org');>> wrote:
>
>> Regarding the caching, we would need to agree between apps and web about
>> the url and smaxage parameter as Adam noted so that the urls are
>> *exactly* the same to not bloat varnish and reuse the same cached
>> objects across platforms.
>>
>> It is an extremely adhoc and brittle solution but seems like it would be
>> the greatest win.
>>
>> 20% of the traffic from searches by being only in android and web beta
>> seems a lot to me, and we should work on reducing it, otherwise when it
>> hits web stable we're going to crush the servers, so caching seems the
>> highest priority.
>>
>> To clarify its 20% of the load, as opposed to 20% of the traffic. But
> same difference :)
>
>
>> Let's chime in https://phabricator.wikimedia.org/T124216 and continue
>> the cache discussion there.
>>
>> Regarding the validity of results with opening text only, how should we
>> proceed? Adam?
>>
>> I've put together https://phabricator.wikimedia.org/T124258 to track
> putting together an AB test that measures the difference in click through
> rates for the two approaches.
>
>
>
>> On Wed, Jan 20, 2016 at 9:34 PM, David Causse <dcau...@wikimedia.org
>> <javascript:_e(%7B%7D,'cvml','dcau...@wikimedia.org');>> wrote:
>>
>>> Hi,
>>>
>>> Yes we can combine many factors, from templates (quality but also
>>> disambiguation/stubs), size and others.
>>> Today cirrus uses mostly the number of incoming links which (imho) is
>>> not very good for morelike.
>>> On enwiki results will also be scored according the weights defined in
>>> https://en.wikipedia.org/wiki/MediaWiki:Cirrussearch-boost-templates.
>>>
>>> I wrote a small bash to compare results :
>>> https://gist.github.com/nomoa/93c5097e3c3cb3b6ebad
>>> Here is some random results from the list (Semetimes better, sometimes
>>> worse) :
>>>
>>> $ sh morelike.sh Revolution_Muslim
>>> Defaults
>>> "title": "Chess",
>>> "title": "Suicide attack",
>>> "title": "Zachary Adam Chesser",
>>> ===
>>> Opening text no boost links
>>> "title": "Hungarian Revolution of 1956",
>>> "title": "Muslims for America",
>>> "title": "Salafist Front",
>>>
>>> $ sh morelike.sh Chesser
>>> Defaults
>>> "title": "Chess",
>>> "title": "Edinburgh",
>>> "title": "Edinburgh Corn Exchange",
>>> ===
>>> Opening text no boost links
>>> "title": "Dreghorn Barracks",
>>> "title": "Edinburgh Chess Club",
>>> "title": "Threipmuir Reservoir",
>>>
>>> $ sh morelike.sh Time_%28disambiguation%29
>>> Defaults
>>> "title": "Atlantis: The Lost Empire",
>>> "title": "Stargate",
>>> "title": "Stargate SG-1",
>>> ===
>>> Opening text no boost links
>>> "title": "Father Time (disambiguation)",
>>> "title": "The Last Time",
>>> "title": "Time After Time",
>>>
>>>
>>>
>>>
>>>
>>> Le 20/01/2016 19:34, Jon Robson a écrit :
>>>
>>>> I'm actually  interested to see whether this yields better results in
>>>> certain examples where the algorithm is lacking [1]. If it's done as
>>>> an A/B test we could even measure things such as click throughs in the
>>>> related article feature (whether they go up or not)
>>>>
>>>> Out of interest is it also possible to take article size and type into
>>>> account and not returning any morelike results for things like
>>>> disambiguation pages and stubs?
>>>>
>>>> [1] https://www.mediawiki.org/wiki/Topic:Sw

Re: [WikimediaMobile] Similar articles feature performance in CirrusSearch for apps and mobile web

[Adam Baso]

One thing we could do regarding the quality of the output is check results
against a random sample of popular articles (example approach
 to find some articles)
on mdot Wikipedia. Presuming that improves the quality of the
recommendations or at least does not degrade them, we should consider
adding the enhancement task to a future sprint, with further
instrumentation and A/B testing / timeboxed beta test, etc.

Joaquin, smaxage (e.g., 24 hour cached responses) does seem a good fix for
now for further reduction of client perceived wait, at least for non-cold
cache requests, even if we stop beating up the backend. Does anyone know of
a compelling reason to not do that for the time being? The main thing that
comes to mind as always is growing the Varnish cache object pool - probably
not a huge deal while the thing is only in beta, but on the stable channel
maybe noteworthy because it would run on probably most pages (but that's
what edge caches are for, after all).

Erik, from your perspective does use of smaxage relieve the backend
sufficiently?

If we do smaxage, then Web, Android, iOS should standardize their URLs so
we get more cache hits at the edge across all clients. Here's the URL I see
being used on the web today from mobile web beta:

https://en.m.wikipedia.org/w/api.php?action=query=json=2=pageimages%7Cpageterms=thumbnail=80=description=3=search=morelike%3ACome_Share_My_Love=0=3


-Adam

On Wed, Jan 20, 2016 at 7:45 AM, Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:

> I'd be up to it if we manage to cram it up in a following sprint and it is
> worth it.
>
> We could run a controlled test against production with a long batch of
> articles and check median/percentiles response time with repeated runs and
> highlight the different results for human inspection regarding quality.
>
> It's been noted previously that the results are far from ideal (which they
> are because it is just *morelike*), and I think it would be a great idea
> to change the endpoint to a specific one that is smarter and has some cache
> (we could do much more to get relevant results besides text similarity,
> take into account links, or *see also* links if there are, etc...).
>
> As a note, in mobile web the related articles extension allows editors to
> specify articles to show in the section, which would avoid queries to
> cirrussearch if it was more used (once rolled into stable I guess).
>
> I remember that the performance related task was closed as resolved (
> https://phabricator.wikimedia.org/T121254#1907192), should we reopen it
> or create a new one?
>
> I'm not sure if we ended up adding the smaxage parameter (I think we
> didn't
> ),
> should we? To me it seems a no-brainer that we should be caching this
> results in varnish since they don't need to be completely up to date for
> this use case.
>
> On Tue, Jan 19, 2016 at 11:54 PM, Erik Bernhardson <
> ebernhard...@wikimedia.org> wrote:
>
>> Both mobile apps and web are using CirrusSearch's morelike: feature which
>> is showing some performance issues on our end. We would like to make a
>> performance optimization to it, but before we would prefer to run an A/B
>> test to see if the results are still "about as good" as they are currently.
>>
>> The optimization is basically: Currently more like this takes the entire
>> article into account, we would like to change this to take only the opening
>> text of an article into account. This should reduce the amount of work we
>> have to do on the backend saving both server load and latency the user sees
>> running the query.
>>
>> This can be triggered by adding these two query parameters to the search
>> api request that is being performed:
>>
>> cirrusMltUseFields=yes=opening_text
>>
>>
>> The API will give a warning that these parameters do not exist, but they
>> are safe to ignore. Would any of you be willing to run this test? We would
>> basically want to look at user perceived latency along with click through
>> rates for the current default setup along with the restricted setup using
>> only opening_text.
>>
>> Erik B.
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Related Articles / Read More Data Analysis

[Adam Baso]

Hi there,

I posed some basic funnel analysis and Referer analysis for the Related
Articles / Read More functionality:

https://www.mediawiki.org/wiki/Reading/Web/Projects/Related_pages#Metrics_analysis

Short version: it seems to have relatively higher engagement on the mobile
web beta channel, but relatively lower engagement on the desktop web beta
feature.

Analysis and discussion on the feature is ongoing, but I wanted to share
out this data anyway.

-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Wikitech-l] MediaWiki authentication changes

[Adam Baso]

In case you don't follow wikitech-l.

-Adam


-- Forwarded message --
From: Brad Jorsch (Anomie) 
Date: Thu, Jan 14, 2016 at 8:55 AM
Subject: [Wikitech-l] MediaWiki authentication changes
To: Wikimedia developers 


*TL;DR:* Stuff is changing. If you notice problems with session handling in
1.27.0-wmf.11, file a bug in Phabricator and CC me (Anomie) and Gergő (Tgr).

MediaWiki's authentication layer is getting a major overhaul! This will
allow us to do cool stuff like 2-factor authentication without the 2-factor
extension having to be redone for LdapAuth/CentralAuth/every-other-auth,
third-party login (e.g. Google, Facebook) without hacking around everything
with crazy hooks, and supporting more than just one authentication method
at a time.

Broadly speaking, this change involves the addition of two new things:
SessionManager (already merged, being deployed with 1.27.0-wmf.11) and
AuthManager (hopefully coming by the end of February).

   - SessionManager replaces the use of PHP's $_SESSION and session_*()
   functions and the UserLoadFromSession and UserSetCookies hooks with a
more
   extensible mechanism.
   - AuthManager allows for independent pluggable authentication modules,
   multiple authentication methods, and removes the assumption that all
logins
   can be handled with a one-page form having "username" and "password"
   fields. No more needing to adjust every authentication extension to know
   about every other authentication extension it might have to cooperate
with.

However, the changes we're making do mean that various things are going to
need updating.

== For users ==

You shouldn't notice any changes due to SessionManager. If you do see
problems related to session handling in 1.27.0-wmf.11, file a bug in
Phabricator and CC me (Anomie) and Gergő (Tgr).

Once AuthManager comes around, the most visible change will be that the
login form will probably be a bit different, and if your browser remembers
your login information for you then you might have to re-enter it.

== For bots ==

You shouldn't notice any changes due to SessionManager, but do make sure
your code is handling cookies normally instead of using the deprecated
return values from action=login to construct cookies manually.[1] If you
are handling cookies properly and see problems related to session handling
in 1.27.0-wmf.11, file a bug in Phabricator and CC me (Anomie) and Gergő
(Tgr).

For AuthManager, the new features mean that unattended login might no
longer work since the login flow will now natively support user
interaction: the account might have 2-factor enabled, or might need a
password reset, or some other thing that requires user interaction. We've
created two ways to work around this:

   - If possible, switch to OAuth. This week (1.27.0-wmf.10) "owner-only"
   consumers are being rolled out to make this easier for bot operators: log
   into your bot account, go to
   https://meta.wikimedia.org/wiki/Special:OAuthConsumerRegistration/propose
,
   and create a consumer with the "This consumer is for use only by
MyBotName"
   checkbox checked.The consumer will be approved for use immediately, no
   waiting or trying to find someone who can approve the consumer for you.
   Owner-only consumers also don't tag every edit, since all the edits will
be
   from the one account anyway.
   - If you need to continue using the existing action=login, next week
   (1.27.0-wmf.11) we're rolling out Bot Passwords. This is something like
   OAuth-lite, or Google's application passwords: go to
Special:BotPasswords,
   set one up, and then use new bot-password username and password to login
as
   you've always done (no code changes, just update your bot's
configuration).
   It's already live in Beta Labs if you want to test it out.

Login with the "main" account password will continue to work until
AuthManager is deployed, and might continue to work after that too (as long
as nothing requires user interaction).

For bots that run on third-party wikis, Bot Passwords are in core and are
enabled by default, but it's possible a wiki could disable them. OAuth is
an extension.

 [1]:
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2015-December/99.html

== For user scripts and gadgets ==

Since user scripts and gadgets rely on the user already being logged in,
you shouldn't notice any changes.

== For core and extension developers ==

There's some other useful stuff that has already been merged, written as
part of the groundwork for this project:

   - User::newSystemUser(), which replaces directly screwing around with
   accounts when an extension needs a user for logged actions.
   - Deprecation or removal of much of the password handling logic from the
   User class. In particular User::getPassword() no longer works.
   - CentralIdLookup, a generic mechanism for looking up a "central" ID for
   cross-wiki features instead of everything needing that 

[WikimediaMobile] Fwd: [Analytics] MobileWebSectionUsage table dropped from Eventlogging mysql db. Data is available on hadoop.

[Adam Baso]

FYI. Tilman is in discussion with Nuria for remediation of this in order to
get things back up and running to support analysis on this event set.

-- Forwarded message --
From: Nuria Ruiz 
Date: Wed, Jan 13, 2016 at 2:49 PM
Subject: [Analytics] MobileWebSectionUsage table dropped from Eventlogging
mysql db. Data is available on hadoop.
To: "A mailing list for the Analytics Team at WMF and everybody who has an
interest in Wikipedia and analytics." 
Cc: Jon Robson 


Team:

We had to take some desperate measures to unblock replication on
Eventlogging in the absence of our DBA.

We had to drop the MobileWebSectionUsage table. Table is blacklisted as
stream of events was to great for the system to sustain it, we will
whitelist it again once the new sampling rate takes effect.

Data is not available in mysql but it is present on hadoop so , to be
clear, no data has been lost.

We will report on replication issues as we have more knowledge. Sorry again
about the late notice.

Thanks,


Nuria


___
Analytics mailing list
analyt...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Mobile web and the curious case of the peacock butterfly

[Adam Baso]

I tried with ?action=purge and choosing Yes. No luck for me. Tagging a
cachebusting parameter did yield a fresh copy, though.

On Tue, Dec 15, 2015 at 3:30 PM, Jon Robson <jrob...@wikimedia.org> wrote:

> Did you run the purge command on the mobile site? The mobile and
> desktop site have separate parser caches.
>
>
> On Tue, Dec 15, 2015 at 3:21 PM, Adam Baso <ab...@wikimedia.org> wrote:
> > Note: a manual deploy for api.php action=mobileview was SWAT deployed
> > yesterday.
> >
> > To err on the side of caution I've created a separate task at
> > https://phabricator.wikimedia.org/T121594 for this stale webpage issue.
> >
> > -Adam
> >
> > On Tue, Dec 15, 2015 at 3:11 PM, Gergo Tisza <gti...@wikimedia.org>
> wrote:
> >>
> >> On Tue, Dec 15, 2015 at 2:38 PM, Dan Garry <dga...@wikimedia.org>
> wrote:
> >>>
> >>> Thanks for sending the screenshots. For some reason, the version I'm
> >>> seeing is actually up to date.
> >>
> >>
> >> You are probably logged in, or for some other reason not getting into
> the
> >> same cache bucket as Pine.
> >>
> >> If it is really caused by the linked bug, it will be fixed on Thursday
> >> when the current master is deployed to Wikipedias. (...if MobileFrontend
> >> uses the standard deploy train. I know some Reading extensions don't
> but can
> >> never remember which ones.)
> >>
> >> ___
> >> Mobile-l mailing list
> >> Mobile-l@lists.wikimedia.org
> >> https://lists.wikimedia.org/mailman/listinfo/mobile-l
> >>
> >
> >
> > ___
> > Mobile-l mailing list
> > Mobile-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/mobile-l
> >
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Mobile web and the curious case of the peacock butterfly

[Adam Baso]

Note: a manual deploy for api.php action=mobileview was SWAT deployed
yesterday.

To err on the side of caution I've created a separate task at
https://phabricator.wikimedia.org/T121594 for this stale webpage issue.

-Adam

On Tue, Dec 15, 2015 at 3:11 PM, Gergo Tisza  wrote:

> On Tue, Dec 15, 2015 at 2:38 PM, Dan Garry  wrote:
>
>> Thanks for sending the screenshots. For some reason, the version I'm
>> seeing is actually up to date.
>>
>
> You are probably logged in, or for some other reason not getting into the
> same cache bucket as Pine.
>
> If it is really caused by the linked bug, it will be fixed on Thursday
> when the current master is deployed to Wikipedias. (...if MobileFrontend
> uses the standard deploy train. I know some Reading extensions don't but
> can never remember which ones.)
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Cross Post to mobile-l: No browser test failures to this mailing list anymore

[Adam Baso]

Please see below if you want to follow test failure messages for some of
the key Reading Web (formerly Mobile web) technologies

-Adam

-- Forwarded message --
From: Bahodir Mansurov 
Date: Wed, Nov 25, 2015 at 5:53 PM

Hello all,

As you may know, we used to get emails about browser test failures for the
MobileFrontend, Gather, and QuickSurveys to this mailing list (along with
to qa-ale...@lists.wikimedia.org). Some people seem to have muted those
(rightly so if they are not interested), other interested people may not
have been getting those emails because they are not subscribed to
reading-wmf. So, in order to reach a broader audience and stop bugging
folks who are not interested in these emails, we will no longer send those
automated emails to this list.

I encourage the reading web team, its product manager, editing team members
who contribute to MobileFrontend, and others who like reading emails that
start with the word "FAILURE:" in bold and red, please subscribe to
qa-ale...@lists.wikimedia.org.

I used the following filter to only get the emails I'm interested in:

to:(qa-ale...@lists.wikimedia.org) (MobileFrontend OR QuickSurveys OR
Gather)


Thank you,
Baha
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Link Preview Update

[Adam Baso]

>
> We made the call not to work on link preview on the mobile web (or
> hovercards on desktop web [1]) in the remainder of Q2 based on our earlier
> analysis.  I am tempted to say that this secondary analysis justifies
> implementing link preview on the web, but think it is at least worth a
> discussion for mobile web, due to the potential trade-off.  Do we try again
> in Q3?  I know Florian is already doing a great deal of the work.
>

I'm interested in doing it as part of the speed arena. In addition to the
apparent lift with the other metric, for users who don't go to the next
page, it saves a lot of bandwidth and is very fast. There is the drawback
that some users may really hate it even when most users appreciate it (even
if unknowingly) - it seems like an obvious opt out could address that case.
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Analytics] EventLogging outage in progress?

[Adam Baso]

Heads up in case you query Event Logging tables.

-- Forwarded message --
From: *Marcel Ruiz Forns* 
Date: Monday, November 30, 2015
Subject: [Analytics] EventLogging outage in progress?
To: "A mailing list for the Analytics Team at WMF and everybody who has an
interest in Wikipedia and analytics." 


Team, I checked and, indeed, EventLogging database needs backfilling from
2015-11-27 01:00 until 2015-11-27 07:00. I updated the docs and started the
backfilling process. I'll let you know when it it finished.
Cheers

On Fri, Nov 27, 2015 at 8:31 PM, Oliver Keyes > wrote:

> It seems like it would depend on the class of error. 48 hours for
> events not syncing, fine. 48 hours of /total data loss/ is a
> completely different class of problem.
>
> On 27 November 2015 at 11:35, Nuria Ruiz  > wrote:
> >>Unfortunately, the only team-members working full-time yesterday and
> today
> >> are we Europe folks.
> >>We weren't there when that happened and we don't get those alerts on the
> >> phone, we should though.
> > Given that this system is tier-2 i do not think we need an immediate
> > response, 24 hours should be an acceptable ETA. I would say even 48.
> >
> > On Fri, Nov 27, 2015 at 2:31 AM, Marcel Ruiz Forns  >
> > wrote:
> >>
> >> Thanks, Ori, for having a look at this and restarting EL.
> >>
> >> I understand it was 01:30 UTC on Friday (today), not Thursday. It went
> on
> >> during 5-6 hours.
> >> Unfortunately, the only team-members working full-time yesterday and
> today
> >> are we Europe folks.
> >> We weren't there when that happened and we don't get those alerts on the
> >> phone, we should though.
> >>
> >> This problem happened already like a month ago. We'll backfill the
> missing
> >> events and will investigate.
> >> Thanks again for the heads-up.
> >>
> >> On Fri, Nov 27, 2015 at 8:01 AM, Ori Livneh  > wrote:
> >>>
> >>> On Thu, Nov 26, 2015 at 10:46 PM, Ori Livneh  > wrote:
> 
>  Seems that eventlog1001 has not received any events since 01:30 UTC on
>  Thursday
> 
> 
> 
> http://ganglia.wikimedia.org/latest/graph.php?r=day=xlarge=Miscellaneous+eqiad=eventlog1001.eqiad.wmnet===hide=0=140128.28=bytes_in=bytes%2Fsec=Bytes+Received
> 
>  This is pretty severe; I'd page if it wasn't a US holiday.
> >>>
> >>>
> >>> Kafka clients on eventlog1001 were in a "Autocommitting consumer
> offset"
> >>> death-loop and not receiving any events from the Kafka brokers. I ran
> >>> eventloggingctl stop / eventloggingctl start and they recovered. Needs
> to be
> >>> investigated more thoroughly. Otto, can you follow up?
> >>>
> >>>
> >>> ___
> >>> Analytics mailing list
> >>> analyt...@lists.wikimedia.org
> 
> >>> https://lists.wikimedia.org/mailman/listinfo/analytics
> >>>
> >>
> >>
> >>
> >> --
> >> Marcel Ruiz Forns
> >> Analytics Developer
> >> Wikimedia Foundation
> >>
> >> ___
> >> Analytics mailing list
> >> analyt...@lists.wikimedia.org
> 
> >> https://lists.wikimedia.org/mailman/listinfo/analytics
> >>
> >
> >
> > ___
> > Analytics mailing list
> > analyt...@lists.wikimedia.org
> 
> > https://lists.wikimedia.org/mailman/listinfo/analytics
> >
>
>
>
> --
> Oliver Keyes
> Count Logula
> Wikimedia Foundation
>
> ___
> Analytics mailing list
> analyt...@lists.wikimedia.org
> 
> https://lists.wikimedia.org/mailman/listinfo/analytics
>



-- 
*Marcel Ruiz Forns*
Analytics Developer
Wikimedia Foundation
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [discovery] Announcement: New dashboard covering the Wikipedia portal

[Adam Baso]

It's a stats morning (depending on your timezone)!

The two dashboards in the link below are a pretty neat look at what happens
when people visit https://wikipedia.org/ .

-Adam

-- Forwarded message --
From: Oliver Keyes 
Date: Mon, Nov 30, 2015 at 7:37 AM
Subject: Re: [discovery] Announcement: New dashboard covering the Wikipedia
portal
To: A public mailing list about Wikimedia Search and Discovery projects <
discov...@lists.wikimedia.org>


My bad; the /non-beta/ link is http://discovery.wmflabs.org/portal/ ;)

On 30 November 2015 at 10:09, Oliver Keyes  wrote:
> Hey all,
>
> The Discovery Analysis team is pleased to report we have released a
> new dashboard, providing basic data about usage of the Wikipedia
> portal (https://www.wikipedia.org). It can be found at
> http://discovery-beta.wmflabs.org/portal/
>
> Thanks,
>
> Oliver, on behalf of the Discovery Analysis team
> --
> Oliver Keyes
> Count Logula
> Wikimedia Foundation



--
Oliver Keyes
Count Logula
Wikimedia Foundation

___
discovery mailing list
discov...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/discovery
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Wikitech-l] CI and cross repository dependencies

[Adam Baso]

Cross, posting - this is great!

-- Forwarded message --
From: Antoine Musso 
Date: Thu, Nov 19, 2015 at 5:19 AM
Subject: [Wikitech-l] CI and cross repository dependencies
To: wikitec...@lists.wikimedia.org


Hello,

We often have the case of a change to an extension depending on a
pending patch to MediaWiki core.  I have upgraded our CI scheduler -
Zuul - a couple weeks ago and it now supports marking dependencies even
in different repositories.


Why does it matter?  To make sure the dependency is fulfilled one
usually either:

* CR-2 the patch until dependent change is merged
* write a test that exercise the required patch in MediaWiki.

With the first solution (lack of test), once both are merged, nothing
prevent one from cherry picking a patch without its dependent patch.
For example for MediaWiki minor releases or Wikimedia deployment branches.

When a test covers the dependency, it will fail until the dependent one
is merged which is rather annoying.


Zuul now recognizes the header 'Depends-On' in git messages, similar to
'Change-Id' and 'Bug'.  'Depends-On' takes as parameter a change-id and
multiple ones can be added.

When a patch is proposed in Gerrit, Zuul looks for Gerrit changes
matching the 'Depends-On' and verify whether any are still open. In such
a case, it will craft references for the open patches so all the
dependencies can be tested as if they got merged.


Real world example
--

The ContentTranslation extension is tested with the Wikidata one and was
not passing the test.  Wikidata created a patch and we did not want to
merge it until we confirm the ContentTranslation one is passing properly.

The Wikidata patch is https://gerrit.wikimedia.org/r/#/c/252227/
Change-Id: I0312c23628d706deb507b5534b868480945b6163

On ContentTranslation we indicated the dependency:
https://gerrit.wikimedia.org/r/#/c/252172/1..2//COMMIT_MSG
+ Depends-On: I0312c23628d706deb507b5534b868480945b6163

Which is the Wikidata patch.


Zuul:
* received the patch for ContentTranslation
* looked up the change-id and found the Wikidata
* created git references in both repo to point to the proper patches

Jenkins:
* zuul-cloner cloned both repos and fetched the references created by
the Zuul service
* run tests
* SUCCESS

That confirmed us the Wikidata patch was actually fixing the issue for
ContentTranslation. Hence we CR+2 both and all merged fine.


Please take a moment to read upstream documentation:

http://docs.openstack.org/infra/zuul/gating.html#cross-repository-dependencies

Wikidata/ContentTranslation task:
https://phabricator.wikimedia.org/T118263


--
Antoine "hashar" Musso


___
Wikitech-l mailing list
wikitec...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Extension Responsibility

[Adam Baso]

Hi all. Apologies for the delay on this! We're pretty close now to having a
complete table of Reading-associated extensions, meaning I think I can
update the maintainers table to at least point to this content after I move
the page. Would you please take a look at it now?

https://www.mediawiki.org/wiki/User:ABaso_(WMF)/Extension_Responsibility

TheDJ and brion, note you're mentioned in MwEmbedSupport and
TimedMediaHandler. Is it fair to say you're the main people working on
these two things today (in the future we should figure out how
consumption-oriented stuff can be divvied up further, I think).

Again,

On Thu, Jul 30, 2015 at 7:03 AM, Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:

> +1 to being generic. For example if you look at Echo, the *Collaboration
> team* is on the maintainers.
>
> On Thu, Jul 23, 2015 at 7:49 PM, Adam Baso <ab...@wikimedia.org> wrote:
>
>> Thanks! I added it to my subpage and assigned it to Reading Design.
>> Assuming comments on this thread taper off soon, I'll figure out how to get
>> this stuff added into
>> https://www.mediawiki.org/wiki/Developers/Maintainers . I think in the
>> Maintainers column we'll want to be generic and point to the particular
>> team if someone isn't actively maintaining it, but otherwise point to a
>> person who we know to be actively developing *plus* the particular team.
>>
>> -Adam
>>
>> On Thu, Jul 23, 2015 at 9:31 AM, Volker Eckl <ve...@wikimedia.org> wrote:
>>
>>> There are currently plans on deploying skin Blueprint on mediawiki.org
>>> <https://phabricator.wikimedia.org/T93613>. Besides my work on UI
>>> Standardization I'll also continue to work on the skin. I think Blueprint
>>> should be on that list.
>>>
>>> Best,
>>> Volker
>>>
>>> On Thu, Jul 23, 2015 at 6:25 PM, Adam Baso <ab...@wikimedia.org> wrote:
>>>
>>>> Would you please share this on the list?
>>>>
>>>> On Thursday, July 23, 2015, Volker Eckl <ve...@wikimedia.org> wrote:
>>>>
>>>>> Hi Adam,
>>>>> there are currently plans on deploying skin Blueprint on mediawiki.org
>>>>> <https://phabricator.wikimedia.org/T93613>. Besides my work on UI
>>>>> Standardization I'll also continue to work on Blueprint. Although UI
>>>>> Standardization is a "special case", formally we belong to Reading and
>>>>> therefore I think Blueprint should be on that list.
>>>>>
>>>>>
>>>>> Best,
>>>>> Volker
>>>>>
>>>>> On Mon, Jul 20, 2015 at 10:58 PM, Adam Baso <ab...@wikimedia.org>
>>>>> wrote:
>>>>>
>>>>>> Hi all -
>>>>>>
>>>>>> I've been reviewing a list of extensions with Reading Engineering and
>>>>>> Reading Infrastructure leads - props to James Forrester for promoting 
>>>>>> this
>>>>>> discussion. Here's a list of extensions we believe currently falls under
>>>>>> Reading for triage (n.b., not all extensions will get active development
>>>>>> support).
>>>>>>
>>>>>>
>>>>>> https://www.mediawiki.org/wiki/User:ABaso_(WMF)/Extension_Responsibility
>>>>>>
>>>>>> Presuming no major issues with this, I think we should move the page
>>>>>> to mw:Reading/Extension_Responsibility.
>>>>>>
>>>>>> One important outstanding question:
>>>>>>
>>>>>> Is MultimediaViewer appropriate for Reading given its
>>>>>> consumption-oriented nature? Or is this actually better suited to Editing
>>>>>> (where there exists a team named Multimedia)?
>>>>>>
>>>>>> Some other notes:
>>>>>>
>>>>>> * For skins with low utilization, we in time probably should
>>>>>> coordinate handover to interested community members (or discuss with
>>>>>> community members practical approaches for EOL).
>>>>>>
>>>>>> * Regarding the Nostalgia skin, we believe it's only used on
>>>>>> https://nostalgia.wikipedia.org/wiki/HomePage, so maintenance would
>>>>>> be updating for breaking skin changes or security issues only.
>>>>>>
>>>>>> * JsonConfig, ZeroBanner, ZeroPortal - we'll need to examine this
>>>>>> more closely. Yuri (who has deepest PHP knowledge on extensions) is now
>>>>>> over in Discovery, Jeff (JS & Lua) is in Reading, and now I'm managing
>>>>>> instead of writing lots of code.
>>>>>>
>>>>>> * Collection probably belongs in Services
>>>>>>
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> Mobile-l mailing list
>>>>>> Mobile-l@lists.wikimedia.org
>>>>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>>>>>
>>>>>>
>>>>>
>>>
>>> ___
>>> Mobile-l mailing list
>>> Mobile-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>>
>>>
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Reading goals for the quarter.

[Adam Baso]

Done.

On Mon, Nov 2, 2015 at 2:07 AM, Andre Klapper 
wrote:

> On Sun, 2015-11-01 at 19:08 -0800, Toby Negrin wrote:
> > Our goals for Fiscal Year Q2 (Oct - Dec) are up on the wiki.
> > Apologies for this taking so long.
> >
> > https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q2_Goals
> > #Reading
>
> Should that be linked from the central team page on mw.org, like under
> "Strategy and planning" of https://www.mediawiki.org/wiki/Reading ?
>
> andre
> --
> Andre Klapper | Wikimedia Bugwrangler
> http://blogs.gnome.org/aklapper/
>
>
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Cross-Post: The page design of our dreams

[Adam Baso]

Sharing this on mobile-l.

-Adam

-- Forwarded message --
From: C. Scott Ananian 
Date: Wed, Sep 30, 2015 at 12:14 PM
Subject: [Design] The page design of our dreams
To: Wikimedia designers 


Let's revisit the basic way that Mediawiki lays out media and content.
It has worked well enough for twenty years, but perhaps we can do
better.

In particular, I would like to be able to (a) make Wikimedia projects
looks Really Beautiful (b) on a variety of different devices and
formats.

Mobile and print are the forerunners here: in both cases we'd like
more flexibility to lay out infoboxes, media, tables, and content in
not-strictly-linear ways:

1) We'd like to be able to tag lead images, and use them more
generally (backgrounds for page titles, previews, etc)

2) Infoboxes, references, footnotes, etc want to be untethered from
their source location in the content and moved around -- for example,
to sidebars or popups on mobile; to the footer or dedicated pages in
print.

3) We would like to be able to crop and scale images better, but need
focal point information or a box around critical regions of the image.
(If the article is about the sun, and the photo is of a sunny day,
cropping the sun out would be bad.  Other images have critical
features at the edges of the image we don't want to lose.)  We
currently have a single option "thumb", and a single user-specified
scaling factor, meant for accessibility --- but an accessible size
will differ on different devices, and the scaling factor doesn't apply
to all images, only to those using "thumb".

4) We need more semantic information about images in order to make
better layouts: in print, is this a "wide" image appropriate for
spanning across multiple columns, or a "feature" image appropriate for
having a page to itself?  Is this a meaningful parallel grouping of
images (ie, before and after) which shouldn't be broken up (but could
be arranged either horizontally or vertically, or perhaps with a
slider)?  Should this image be laid out inline (rarely) or can it
float to a more aesthetic location?

5) Even text content might be unmoored -- why can't we have pull
quotes or sidebars in our articles?

6) What else?  What other features of magazine, newpaper, or
encyclopedia design are we missing?

>From a technical perspective, I'd like to move eventually toward a
system with greater separation of layout and content (think of
something like adobe pagemaker), where changes to layout can be made
without editing the article text.  But I'd also like to make sure that
the technical issues don't overshadow the actual goal:

* What beautiful designs would you like for article content?

* What tools could we build to enable these designs?

Eventually we'd like to boil this down into a concrete design for a
better image styling system, which seems like a reasonable first step
in revamping what mediawiki can do for designers.  That RFC is
https://phabricator.wikimedia.org/T90914 -- ideally the RFC will be
guided by a concrete design for a specific article, say,
http://en.wikipedia.beta.wmflabs.org/wiki/Moon, so that the
implementation of the RFC can focus on building the capabilities
needed to execute that specific design.  That way we're certain we're
building something useful and beautiful for designers and readers, not
just implementing something whose PHP code seems elegant.
 --scott

--
(http://cscott.net)

___
Design mailing list
des...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Cross-Post: A couple videos: Parsoid with Reading Engineering; Reading Showcase 20150824

[Adam Baso]

Sending this to mobile-l in case you don't follow wikitech-l.

-Adam

-- Forwarded message --
From: Adam Baso <ab...@wikimedia.org>
Date: Thu, Sep 17, 2015 at 10:58 AM
Subject: A couple videos: Parsoid with Reading Engineering; Reading
Showcase 20150824
To: Wikimedia developers <wikitec...@lists.wikimedia.org>


Hi all,

Just wanted to share a couple recent videos. Enjoy!

== Parsoid with Reading ==

https://youtu.be/3WJID_WC7BQ?t=14

C. Scott Ananian and Subbu Sastry from the Wikimedia Foundation provide an
overview of Parsoid, a Wikimedia technology that supports HTML to wikitext
(and vice versa) translation, supporting rich annotated output markup for
translation layers and other clients (e.g., Wikipedia related technology)
to more specifically query elements from wiki content.

You may have caught some of this material at Wikimania, or maybe this is
your first time. In any event, it's good stuff! This was an interactive
session with questions from Wikimedia Reading Engineering.

== Reading Showcase 20150824 ==

https://youtu.be/F9ExzUaRI0k

About every 4 weeks the Wikimedia Reading department gets together to
showcase experiments and works in progress and the like. This is the
session from 24-August-2015.

-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Android Wikipedia legacy device active maintenance ending

[Adam Baso]

Following up...

For Wikipedia Zero tagged Wikipedia for Android access, looking at days
from August 20-26, it looks like about somewhere between 14.8% and 16.6% of
pageviews are on Android 2.3-4.0. [1]

Wikipedia Zero tagged Wikipedia for Android access constitutes about 5.3%
of the overall Wikipedia for Android app pageviews, based on a week of
pageviews from August 20-26.

-Adam

[1]

select day, user_agent_map['os_major'], user_agent_map['os_minor'],
sum(view_count) from wmf.pageview_hourly where
year = 2015 and month = 8 and day  19 and day  27
and access_method = 'mobile app'
and zero_carrier is not null
and user_agent_map['os_family'] = 'Android'
group by day, user_agent_map['os_major'], user_agent_map['os_minor'];


[2]

select sum(view_count)
from wmf.pageview_hourly
where year = 2015 and month = 8 and day  19 and day  27
and access_method = 'mobile app'
and user_agent_map['os_family'] = 'Android'
and zero_carrier is null;

36197035


select sum(view_count)
from wmf.pageview_hourly
where year = 2015 and month = 8 and day  19 and day  27
and access_method = 'mobile app'
and user_agent_map['os_family'] = 'Android'
and zero_carrier is not null;

2032938


2032938 / (2032938 + 36197035) = 0.05317654815


On Thu, Aug 27, 2015 at 4:43 PM, Adam Baso ab...@wikimedia.org wrote:

 I think I can get this in Hadoop. Will get back on thread.

 On Thu, Aug 27, 2015 at 3:22 PM, Pine W wiki.p...@gmail.com wrote:

 Just to check: what percentage of Wikipedia Zero users are running
 Android legacy OS versions?

 Pine
 On Aug 27, 2015 12:49 PM, Stephen Niedzielski 
 sniedziel...@wikimedia.org wrote:

 The WMF Android App team will be ceasing active support for older
 devices soon, namely devices that run Android 4.0 (Ice Cream Sandwich)
 or older. Our final legacy device release is expected in mid to late
 September[0]. This release will remain available on the Google Play
 Store for devices running Android 2.3 (Gingerbread) through 4.0 (Ice
 Cream Sandwich). However, future releases will only target devices
 running Android 4.0.3 (Ice Cream Sandwich MR1) and higher. [1]

 * Why this is happening
   Devices running Android versions older than 4.0.3 make up less than
   8%[2] of the Wikipedia for Android install base, and supporting older
   devices requires disproportionate developer time and effort. Focusing
   our efforts on the most recent and widely used versions will allow us
   to provide a faster, more stable, and more delightful Wikipedia
   experience.

 * What this means for older devices
   Enjoy a stable and beautiful legacy release for as long as you wish.
   When you're ready for a new device, a sleek and modern app awaits you.

 * What this means for all other devices
   Reap the benefits of a Wikipedia for Android experience built to take
   advantage of the latest and greatest Android technology available.

 -The Wikimedia Android team

 [0] This will be the final planned legacy device release. Allowances
 will be made to enable back support patches of critical issues.
 [1] https://source.android.com/source/build-numbers.html
 [2] Google Play Developer Console, Current Installs by Device on August
 20, 2015.

 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l


 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l



___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Android Wikipedia legacy device active maintenance ending

[Adam Baso]

I think I can get this in Hadoop. Will get back on thread.

On Thu, Aug 27, 2015 at 3:22 PM, Pine W wiki.p...@gmail.com wrote:

 Just to check: what percentage of Wikipedia Zero users are running Android
 legacy OS versions?

 Pine
 On Aug 27, 2015 12:49 PM, Stephen Niedzielski 
 sniedziel...@wikimedia.org wrote:

 The WMF Android App team will be ceasing active support for older
 devices soon, namely devices that run Android 4.0 (Ice Cream Sandwich)
 or older. Our final legacy device release is expected in mid to late
 September[0]. This release will remain available on the Google Play
 Store for devices running Android 2.3 (Gingerbread) through 4.0 (Ice
 Cream Sandwich). However, future releases will only target devices
 running Android 4.0.3 (Ice Cream Sandwich MR1) and higher. [1]

 * Why this is happening
   Devices running Android versions older than 4.0.3 make up less than
   8%[2] of the Wikipedia for Android install base, and supporting older
   devices requires disproportionate developer time and effort. Focusing
   our efforts on the most recent and widely used versions will allow us
   to provide a faster, more stable, and more delightful Wikipedia
   experience.

 * What this means for older devices
   Enjoy a stable and beautiful legacy release for as long as you wish.
   When you're ready for a new device, a sleek and modern app awaits you.

 * What this means for all other devices
   Reap the benefits of a Wikipedia for Android experience built to take
   advantage of the latest and greatest Android technology available.

 -The Wikimedia Android team

 [0] This will be the final planned legacy device release. Allowances
 will be made to enable back support patches of critical issues.
 [1] https://source.android.com/source/build-numbers.html
 [2] Google Play Developer Console, Current Installs by Device on August
 20, 2015.

 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l


 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l


___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Fwd: Interesting WSJ article: The Rise of Phone Reading

[Adam Baso]

Rupert,

I might suggest that a point in time analysis can sometimes create the self
fulfilling prophecy issue you talk about, although sometimes it's good to
simply verify if assumptions hold (you know, the whole everyone knows
that! kind of stuff). What I find to be interesting in the case of
thinking forward is the trajectory of the answers. If we're seeing users
are losing interest or gaining interest in something, it may behoove action.

I agree editing is compelling, although there are lots of compelling things
to go after for better reading/consumption/learning experiences.

Regarding editing, there's a bit of discussion starting from
https://lists.wikimedia.org/pipermail/wikitech-l/2015-July/082571.html
about future plans on mobile web editing. As is you can get a VE experience
on tablet in the mobile website. But it's generally wikitext for mobile
devices otherwise.

One note on saving - the Wikipedia apps have save-for-offline capabilities
for Wikipedia; there some projects like Kiwix that focus on offline content
as well. At times people have voiced interest in more advanced offline
capabilities for the Wikipedia apps.

-Adam


On Tue, Aug 18, 2015 at 3:12 PM, rupert THURNER rupert.thur...@gmail.com
wrote:

 Hi,

 This is an interesting discussion. Imo, the unique selling point of
 Wikipedia is the editing.  A known fact is that mobile data rates are
 expensive in many countries. Also known is the number of smartphones
 existing and the number of computers.

 Connecting the above with my own behaviour is sufficient to conclude three
 important use cases ;-) first, read on the phone. Currently good enough.
 Second, write on the phone, current support close to catastrophic. Third,
 save articles to take away, ie offline. Non existing.

 Therfore I think measuring what is used, as well measuring what would be
 needed is quite pointless. The result would be that things working
 sufficiently well will be overweight, kind of self fulfilling prophecy.

 Best,
 Rupert

 On Aug 18, 2015 9:46 PM, Jon Robson jdlrob...@gmail.com wrote:
 
  On Mon, Aug 17, 2015 at 9:13 PM, Corey Floyd cfl...@wikimedia.org
 wrote:
   Definitely interesting… not too surprising that there has been a bump
 in
   mobile reading over that past few years - seeing as everyone's phone
 screens
   are twice as big as they were in 2012. Anecdotally, I am more likely
 to read
   on my phone now than I was a few years ago (I always used to reach for
 my
   iPad before I had an iPhone 6).
  
   When reviewing these stats, we should keep in mind the primary use
 case of
   Wikipedia - a reference. While it is true that some will read
 significant
   portions of a book or a blog posts on their phones, most people aren't
   looking to read a Wikipedia article from top-to-bottom. Some will read
 a
   section or 2, while many others will only need to ready the first
 paragraph
   to get the answer that they need.
 
  I definitely think we need to test this assumption. I wonder if this
  is something the QuickSurvey could be used to measure e.g. a simple
  question What are you here for? (although results might get skewed
  by quick lookups having no time to do a survey). I'm not sure it is.
  Personally I read much more than the lead section (I tend to use
  Google quick facts for those quick lookups).
 
  Thoughts welcomed on how we could work this out.
 
  
   So even as the number of long form readers increases on mobile, that
 might
   not directly translate into more full article Wikipedia readers on
 mobile.
  
   I definitely believe we should continue improving our mobile reading
   experience - it will only become more important as these numbers
 increase,
   however we shouldn't draw to many conclusions from this article as the
   content being discussed is quite different.
  
  
   On Mon, Aug 17, 2015 at 12:31 PM, Tilman Bayer tba...@wikimedia.org
 wrote:
  
   Forwarding to the public list too.
  
  
   -- Forwarded message --
   From: Tilman Bayer tba...@wikimedia.org
   Date: Sun, Aug 16, 2015 at 9:40 PM
   Subject: Interesting WSJ article: The Rise of Phone Reading
   To: Internal communication for WMF Reading team
   reading-...@lists.wikimedia.org
  
  
   Some food for thought - it's probably not entirely surprising in 2015,
   but this article collects a lot of information showing that the
   assumption few people want to read long texts on a phone is too
   simplistic:
   http://www.wsj.com/articles/the-rise-of-phone-reading-1439398395
  
   TLDR from our perspective: Smartphones are becoming a major venue for
   reading ebooks, ie. really long-form texts, more than was predicted a
   few years ago. (In a Nielsen survey of 2,000 people this past
   December, about 54% of e-book buyers said they used smartphones to
   read their books at least some of the time. That’s up from 24% in
   2012.) One reason is convenience - “The best device to read on is the
   one you have with you/Most people who read on 

Re: [WikimediaMobile] What people think about Wikidata descriptions in search on mobile web beta, and a question about arbitrary access of Wikidata data

[Adam Baso]

Kunal,

I believe what Joaquin was referring to is the notion that the web team in
Reading will be entering into work on the desktop-oriented experience. As
you rightly note, the Android and iOS teams are focused squarely on
experiences for mobile devices.

For the edification of the list, the web engineers in Reading were in the
mobile web team, with a focus on experiences for users on mobile form
factor devices like phones and tablets. It's going to take some time to
ramp up practices for tackling code and architecture historically oriented
to the desktop form factor. We'll need to ensure continued stability in the
platform and work with the community as we propose and introduce changes to
the desktop form factor user experience.

-Adam


On Tue, Aug 18, 2015 at 11:22 AM, Legoktm legoktm.wikipe...@gmail.com
wrote:

 On 08/18/2015 10:29 AM, Joaquin Oltra Hernandez wrote:
  Luckily there's no mobile teams any more after the reorg.

 Are you sure? [1] In any case, it would be interesting to look at how
 many commits and contributions the Desktop  Mobile Web team has made
 to the desktop interface.

 [1] https://wikimediafoundation.org/wiki/Staff_and_contractors#Mobile_Apps

 -- Legoktm

 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] What people think about Wikidata descriptions in search on mobile web beta, and a question about arbitrary access of Wikidata data

[Adam Baso]

Magnus, were you thinking that if there *is* a description field for the
knowledge item then that should override the computed description?

On Fri, Aug 14, 2015 at 10:31 AM, Magnus Manske magnusman...@googlemail.com
 wrote:

 As to Wikidata descriptions, I think it's a good first step. As someone
 mentioned, it's pretty useless for most languages, as there are no
 descriptions on Wikidata. IMHO the next step is auto-generating short
 descriptions from the item statements, which will be perfectly fine for the
 vast majority of cases.

 If this is done, I suggest to NOT put the auto-generated text in the
 manual description field, as descriptions will improve over time, through
 both new statements and better algorithms. Rather, cache descriptions
 separately, and update them as required.

 On Fri, Aug 14, 2015 at 4:52 PM Adam Baso ab...@wikimedia.org wrote:

 We recently resumed tweeting with the @WikimediaMobile handle, and I
 wanted to share one tweet with you:

 https://twitter.com/WikimediaMobile/status/631178379501285376

 It looks like people are pretty keen on it.

 There was one person who said outside of top Wikipedias it doesn't seem
 quite as useful. I was wondering, what role might
 https://www.wikidata.org/wiki/Wikidata:Arbitrary_access play in helping
 to enrich results? https://phabricator.wikimedia.org/T100786 and
 https://phabricator.wikimedia.org/T100787 are recent examples of
 implementation of this sort of thing, as mentioned on
 https://wikitech.wikimedia.org/wiki/Deployments.

 -Adam
 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l


___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Reading showcase video and links: Dev Settings, Link Previews, Language Selector, Feeds, Barry the Browser Test Bot

[Adam Baso]

Hi all - we hold a Reading showcase every 4 weeks where people show off
cool work and experimental projects. Thought some people on the list may
have an interest in the following from the one earlier this week. For a
couple of the presentations the screensharing cut out, so that was trimmed
from the end.

https://www.youtube.com/watch?v=UM9YwsAMC_o

Here are the ones where video isn't available.

Kaity and Sherah showed the feeds prototype:

http://feeds-a.meteor.com/

http://feeds-b.meteor.com/

Baha showed off output fromfrom Barry the Browser Test Bot, which Jon
Robson has been rocking:

https://github.com/jdlrobson/Barry-the-Browser-Test-Bot

Enjoy!

-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Apps for Kindle and Windows

[Adam Baso]

My understanding is: in part, although people who were on the mobile team
during the most active part of these projects are probably best situated to
speak to it. There's also this page that has some historical information:

https://www.mediawiki.org/wiki/Wikimedia_Apps/Wikipedia/Hybrid_notes

-Adam





On Thu, Jul 30, 2015 at 7:41 AM, Stephane Bisson sbis...@wikimedia.org
wrote:

 Is the firefox os wikipedia app that's currently out there based on the
 old phonegap app?

 https://marketplace.firefox.com/app/wikipedia/

 https://gerrit.wikimedia.org/r/#/admin/projects/apps/firefox/wikipedia


 On Thu, Jul 30, 2015 at 10:06 AM, Michael Holloway 
 mhollo...@wikimedia.org wrote:

 The old PhoneGap app repo lives here on GitHub:
 https://github.com/wikimedia/WikipediaMobile

 (I haven't touched it and can't speak to its current state.)

 On Thu, Jul 30, 2015 at 9:52 AM, Joaquin Oltra Hernandez 
 jhernan...@wikimedia.org wrote:

 I've also floated the idea of cleaning up / replacing the experimental
 Firefox OS app (which is based on our old PhoneGap app code) and using a
 modernized HTML5+JS app for both Firefox OS and Windows 10 Tablet/Mobile.
 Nobody's bitten on the idea yet, but I think it might be better than trying
 to separately spin up resources for multiple minority mobile OSs.


 Where is such phonegap app? I'm very interested in building a web client and
 have already been doing so for the last 2 hackathons
 http://chimeces.com/webkipedia/ (T106275
 https://phabricator.wikimedia.org/T106275) and I'm working on it
 thinking mobile first.

 I would be very interested in checking the feature set of the old
 phonegap app and when good enough, making an effort to package something
 like that web client for firefoxOS  windows phone.

 Thoughts?

 On Sun, Jul 26, 2015 at 4:10 AM, Stephen Niedzielski 
 sniedziel...@wikimedia.org wrote:

   Hey! I believe we update the Wikipedia for Fire OS (Android) app[0]
 whenever a production version has fully rolled out on Play, although we
 don't offer the Beta[2] on Appstore. I can see they're both currently at
 the latest and greatest. I don't have Fire device presently, but if you
 highlight a term for sharing and have Wikipedia installed, you should get
 the option to search with the app. I *thought* there was also some
 additional platform level support for Wikipedia lookups built by Amazon but
 I might be mistaken.


 --stephen

 [0] https://www.amazon.com/gp/mas/dl/android?p=org.wikipedia
 [1] https://play.google.com/store/apps/details?id=org.wikipedia
 [2] https://play.google.com/store/apps/details?id=org.wikipedia.beta

 On Sat, Jul 25, 2015 at 7:42 PM, Pine W wiki.p...@gmail.com wrote:

 Hi Brion,

 Ok, thanks.

 Is the Wikipedia app promoted to Kindle Fire users very much? It would
 be interesting if highlighting a term in a Kindle book or newspaper would
 take the user to a Wikipedia or Wiktionary article for definitions and
 background info.

 I wonder if Microsoft would be willing to support Wikipedia app
 development for Windows with Microsoft financing or in-kind contribution 
 of
 developer time. Any thoughts?

 Pine
 On Jul 25, 2015 6:08 PM, Brion Vibber bvib...@wikimedia.org wrote:

 On Sat, Jul 25, 2015 at 5:56 PM, Pine W wiki.p...@gmail.com wrote:

 Hi Mobilizers,

 1. Do you think it would make sense to develop a Wikipedia app for
 Kindle, or to encourage Amazon to do so or financially sponsor its
 development?


 Kindle Fire devices are Android-based and can run the existing
 Android Wikipedia app. The bare-bones e-ink Kindle readers are another
 story perhaps. :)


 2. Same questions for Windows and Microsoft, especially considering
 the Windows 10 launch.


 I did an experimental JavaScript/WinJS-based Windows tablet app back
 for the Windows 8 launch, which is still in the Windows Store but needs 
 to
 be cleaned up for Windows 10 or perhaps killed and replaced. :)

 Windows 10 will also have a Mobile edition for phones 'and small
 tablets'; there's a unified app platform between desktop and mobile on
 Windows 10 so it should be possible to adapt the tablet app to run on
 phones (or rewrite it entirely to run on both!)


 There's also been some talk about using the framework Microsoft has
 put together for porting Android apps to Windows 10 Mobile, but I don't
 think anybody has a good handle on how tricky that will be to use, or the
 cost-benefit of working on Windows 10 Mobile in general.

 I've also floated the idea of cleaning up / replacing the
 experimental Firefox OS app (which is based on our old PhoneGap app code)
 and using a modernized HTML5+JS app for both Firefox OS and Windows 10
 Tablet/Mobile. Nobody's bitten on the idea yet, but I think it might be
 better than trying to separately spin up resources for multiple minority
 mobile OSs.

 -- brion


 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l



 

Re: [WikimediaMobile] [reading-wmf] Is Schema:MobileWebClickTracking dead?

[Adam Baso]

Oops, should have sent this on mobile-l to start with. Thanks. Do you think
we should remove that chart from the dashboard, or just prune stuff after
2015 and disable the job that keeps adding records to it?

Kevin and Marcel from Analytics on the CC.

-Adam

On Thu, Jul 30, 2015 at 11:57 AM, Jon Robson jrob...@wikimedia.org wrote:

 Yes. It got split into main-menu-daily, page-ui-daily and various other
 schemas.

 On Thu, Jul 30, 2015 at 11:54 AM, Adam Baso ab...@wikimedia.org wrote:
  Hi there - is Schema:MobileWebClickTracking dead?
 
  On the ui-daily-historic chart in
  https://mobile-reportcard.wmflabs.org/#other-graphs-tab it looks like
 stuff
  pretty much stops at the beginning of 2015.
 
  I'm going to ask Analytics to prune the long tail of events in 2015 to
 make
  the graph prettier without the big drop off if no one objects.
 
  -Adam
 
  ___
  reading-wmf mailing list
  reading-...@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/reading-wmf
 

 ___
 reading-wmf mailing list
 reading-...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/reading-wmf

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Event Logging Field Aggregation versus Time-based Deletion

[Adam Baso]

Hi there - we're reviewing with Analytics the Event Logging tables that
have historically been part of the mobile presence. To reduce longer than
necessary storage of information in some fields yet retaining information
where it will be useful for future analyses, Marcel has noted a couple
approaches. Would you please weigh in over the next couple days on which
approach you prefer?

Read:
https://wikitech.wikimedia.org/wiki/Analytics/EventLogging_Sanitization_vs_Aggregation

Then comment:
https://wikitech.wikimedia.org/wiki/Talk:Analytics/EventLogging_Sanitization_vs_Aggregation

Thanks!
-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Cross-Post: Editing + Reading Meeting Notes

[Adam Baso]

Cross posting to mobile-l.

-- Forwarded message --
From: Adam Baso ab...@wikimedia.org
Date: Mon, Jul 27, 2015 at 10:11 AM
Subject: Editing + Reading Meeting Notes
To: Wikimedia developers wikitec...@lists.wikimedia.org


Hi all,

James Forrester, Florian, and I met Wednesday, 22-July-2015 to discuss the
Editing roadmap, with the backdrop of editing modes available in mobile web
and apps but both the mobile web and apps teams now being in the Reading
department. Notes:

* FY 2015-2016: active Editing development for apps not planned

* General plan is to replace the current mobile web editing experiences
with new (replacement) VE and wikitext editor maintained by the VE team for
mobile web

* Q1: VE mobile prototyping (doesn't require Reading involvement)

* Q2: Editing for mobile web replacement *coding* starting, but rollout on
mobile web would begin in some future quarter _after_ Q2

* Feature submission practices for volunteers submitting editing related
stuff for the mobile web for the time being (feature submissions
discouraged for now as it will end up being replaced; mainline VisualEditor
/ next gen wikitext editing in collaboration with VE team would probably
make more sense) -

** Create task in reading-web Phabricator board and indicate the details of
what you were thinking to work on and roughly when. Add James Forrester and
Joaquin Hernandez to card.

** Reach out to James_F (Senior Product Manager, VisualEditor) and joakino
(Reading Web engineering product owner and tech lead) on #wikimedia-mobile
on Freenode to discuss the idea and to determine who would need to code
review and test

* Code review for bugfixes for the existing mobile editing code should be
done by Reading Web, and code review plus testing should be done by Editing
as well. Ping joakino and James_F on IRC to figure out who to add to
bugfixes.

* As the Editing team gets into the practice of submitting patches for
MobileFrontend to swap out the editor, as usual, tasks should be filed well
ahead of time in the reading-web Phabricator board so there's a heads up
about potential code review. Also, Editing and Reading should be tracking
Q2 and subsequent quarter planning together to ensure dependencies are
clearly defined and agreed upon.

I also spoke to Roan from Collaboration after the Scrum of Scrums the same
day. Roan indicated that there isn't an emphasis on rolling out Flow to
mobile Wikipedias en masse for FY 2015-2016. And generally, when Flow does
become slated for rollout on the mobile Wikipedias and sister projects in a
broader sense it shouldn't require work - or anything substantial, anyway -
from the Reading team.

-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] reading-web board

[Adam Baso]

Hi all - just wanted to let you know about
https://phabricator.wikimedia.org/tag/reading-admin/ if you didn't know
about it already. This is a place the Reading management team adds and
tracks more manager oriented tasks.

As items get moved to Done, we will in the future probably actually want to
check into whether they should be moved farther left in the board to be
repeated / re-reviewed or figure out some appropriate lightweight workflow
for such things.

-Adam
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] In-app editing / talk pages support

[Adam Baso]

Moving discussion to mobile-l.

On Wednesday, July 22, 2015, Michael Holloway mhollo...@wikimedia.org
wrote:

 OK by me.

 On Wed, Jul 22, 2015 at 10:53 AM, Adam Baso ab...@wikimedia.org
 javascript:_e(%7B%7D,'cvml','ab...@wikimedia.org'); wrote:

 Okay to move this discussion to mobile-l?

 I'm talking with Editing (includes VE and Flow) this morning about
 engagement model and their short to medium term roadmap, which should be
 helpful in your guys' examination of bridge/stopgap solutions for this
 pretty fundamental stuff.


 On Wednesday, July 22, 2015, Michael Holloway mhollo...@wikimedia.org
 javascript:_e(%7B%7D,'cvml','mhollo...@wikimedia.org'); wrote:

 Hey all,

 Last week at Wikimania I had some interesting conversations about the
 Android app.  On the whole, people really like the new and improved app,
 but there are definitely frustrations with the editing experience -- from
 people thinking it's not possible to edit in the app, to uninstalling it so
 that Google links direct them to the mobile website, where they vastly
 prefer the editing experience.  Editors are a small but important group and
 I don't think we're doing them justice at the moment.  Although reading is
 our focus, I would suggest we devote some resources to improving the
 editing experience as well.  (It turns out that Abbey Ripstra and the
 design research team are running a survey research study on mobile
 contribution experiences as I write, so I'll be interested to hear what
 insights they have to offer.)

 I also had a conversation with Asaf Bartov, who mentioned that it would
 be nice to be able to access talk pages in the mobile app.  I'm sympathetic
 to this; most users may not care about talk pages, but they're very
 important to the editing experience, and even for savvy readers they offer
 useful commentary about what's on (or off) the page and why.  So yesterday
 afternoon I hacked up a POC patch to add a toolbar button to flip back and
 forth between main articles and talk pages.  Have a look and let me know
 what you think!

 https://gerrit.wikimedia.org/r/#/c/226297/

 Cheers,
 Michael

 --
 You received this message because you are subscribed to the Google
 Groups android group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to android+unsubscr...@wikimedia.org.
 To post to this group, send email to andr...@wikimedia.org.
 To view this discussion on the web visit
 https://groups.google.com/a/wikimedia.org/d/msgid/android/CAMEEL1-AxGuy%2BGUT0f9fYiMVzqpGGwym58a%2BirvaG5njvVQ_Uw%40mail.gmail.com
 https://groups.google.com/a/wikimedia.org/d/msgid/android/CAMEEL1-AxGuy%2BGUT0f9fYiMVzqpGGwym58a%2BirvaG5njvVQ_Uw%40mail.gmail.com?utm_medium=emailutm_source=footer
 .



___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] reading-web board

[Adam Baso]

Okay, I need more coffee! The subject should have been reading-admin, not
reading-web!

There is a reading-web board, too :)

On Wed, Jul 22, 2015 at 9:22 AM, Adam Baso ab...@wikimedia.org wrote:

 Hi all - just wanted to let you know about
 https://phabricator.wikimedia.org/tag/reading-admin/ if you didn't know
 about it already. This is a place the Reading management team adds and
 tracks more manager oriented tasks.

 As items get moved to Done, we will in the future probably actually want
 to check into whether they should be moved farther left in the board to be
 repeated / re-reviewed or figure out some appropriate lightweight workflow
 for such things.

 -Adam

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Outdated Reading-Admin Phab project description

[Adam Baso]

Done.

On Wed, Jul 22, 2015 at 9:16 AM, Adam Baso ab...@wikimedia.org wrote:

 On it.

 On Wed, Jul 22, 2015 at 9:10 AM, Andre Klapper aklap...@wikimedia.org
 wrote:

 Hi,

 could someone please update the description of Reading-Admin in
 https://phabricator.wikimedia.org/project/profile/1199/ ?
 Currently it talks about future plans to happen in April 2015.

 Thanks in advance,
 andre

 PS: Sent this to mobile-l after starring at the numerous lists at
 https://www.mediawiki.org/wiki/Reading#Mailing_Lists for a while.
 --
 Andre Klapper | Wikimedia Bugwrangler
 http://blogs.gnome.org/aklapper/


 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l



___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Outdated Reading-Admin Phab project description

[Adam Baso]

On it.

On Wed, Jul 22, 2015 at 9:10 AM, Andre Klapper aklap...@wikimedia.org
wrote:

 Hi,

 could someone please update the description of Reading-Admin in
 https://phabricator.wikimedia.org/project/profile/1199/ ?
 Currently it talks about future plans to happen in April 2015.

 Thanks in advance,
 andre

 PS: Sent this to mobile-l after starring at the numerous lists at
 https://www.mediawiki.org/wiki/Reading#Mailing_Lists for a while.
 --
 Andre Klapper | Wikimedia Bugwrangler
 http://blogs.gnome.org/aklapper/


 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Wikitech-l] Fwd: Wikipedia iOS app moving to GH

[Adam Baso]

They're two separate lists. I believe most Reading engineers are on both
mobile-l and wikitech-l. Couldn't say so much for other people.

On Wed, Jul 22, 2015 at 10:16 AM, Brian Gerstle bgers...@wikimedia.org
wrote:

 sorry, didn't hit reply-all. (these lists aren't a subset of each other,
 are they?)

 Also, we're losing IRC notifications, but that should be easy enough to add
 back via fastlane.

 -- Forwarded message --
 From: Brian Gerstle bgers...@wikimedia.org
 Date: Wed, Jul 22, 2015 at 12:59 PM
 Subject: Re: [Wikitech-l] Wikipedia iOS app moving to GH
 To: Wikimedia developers wikitec...@lists.wikimedia.org


 I have no problem with that, as long as everyone with +2 keeps his access


 This should already be the case for the main iOS engineers, but I've made a
 ticket https://phabricator.wikimedia.org/T106547 to make sure people
 don't slip through the cracks.

 Oh, and when
  it syncs with phabricator tickets
 

 Phabricator ticket sync is something we're sad to lose, but it's part of
 the trade-off we're making.  That said, it was only slightly beneficial as
 we relied more on cards being in a Code Review column (w/ a WIP limit)
 than looking at the gerrit updates on the cards themselves (which aren't
 visible from the board view).  Not that GH will make this any easier, but
 we're not losing too much here, IMHO.

 On Wed, Jul 22, 2015 at 8:01 AM, Derk-Jan Hartman 
 d.j.hartman+wmf...@gmail.com wrote:

  I have no problem with that, as long as everyone with +2 keeps his access
  and someone manages developer account additions and removals. Oh, and
 when
  it syncs with phabricator tickets
 
  DJ
 
  On Wed, Jul 22, 2015 at 1:39 PM, Petr Bena benap...@gmail.com wrote:
 
   Good job, you aren't the only one. Huggle team is using it for quite
   some time. To be honest I still feel that github is far superior to
   our gerrit installation and don't really understand why we don't use
   it for other projects too.
  
   The GitHub's pull requests are more compliant with original git
   philosophy of Linus, see this video:
   https://www.youtube.com/watch?v=4XpnKHJAok8 and would be sufficient
   replacement to our current git-review mechanism, which is very
   complex and unfriendly to new developers who probably find it very
   difficult to use.
  
   On Wed, Jul 22, 2015 at 12:40 PM, Brian Gerstle 
 bgers...@wikimedia.org
   wrote:
Hey everyone,
   
I'm writing with plans for the Wikimedia iOS engineering team to move
  its
workflow to GitHub with Travis CI, much like RESTbase.
   
The Wikimedia iOS engineers have been maintaining their own CI and
  build
server and using Gerrit for code review. The more time efficient and
commonplace approach for open source iOS software development leans
   heavily
on GitHub with Travis CI instead (e.g., WordPress[0][1] and
   Firefox[2][3]).
By using GitHub with Travis CI, the team believes it will work
 faster,
improve testing, grow developer confidence in making code changes,
 and,
most importantly, deploy fewer bugs to production.
   
For builds requiring sensitive information (e.g., prod certs), will
continue to run on WMF's Mac Mini. As is done for Android, when betas
  are
pushed, the team will notify mobile-l.
   
Feel free to reply or email me directly with any questions or
 comments.
   
Regards,
   
Brian
   
0: https://github.com/wordpress-mobile/WordPress-iOS
1: https://travis-ci.org/wordpress-mobile/WordPress-iOS
2: https://github.com/mozilla/firefox-ios
3: https://travis-ci.org/mozilla/firefox-ios
   
--
EN Wikipedia user page:
  https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
___
Wikitech-l mailing list
wikitec...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  
   ___
   Wikitech-l mailing list
   wikitec...@lists.wikimedia.org
   https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  ___
  Wikitech-l mailing list
  wikitec...@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 



 --
 EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
 IRC: bgerstle



 --
 EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
 IRC: bgerstle
 ___
 Wikitech-l mailing list
 wikitec...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Extension Responsibility

[Adam Baso]

Shall I make it so?

On Tue, Jul 21, 2015 at 3:59 PM, Gergo Tisza gti...@wikimedia.org wrote:

 On Mon, Jul 20, 2015 at 3:58 PM, Adam Baso ab...@wikimedia.org wrote:

 Hi all -

 I've been reviewing a list of extensions with Reading Engineering and
 Reading Infrastructure leads - props to James Forrester for promoting this
 discussion. Here's a list of extensions we believe currently falls under
 Reading for triage (n.b., not all extensions will get active development
 support).

 https://www.mediawiki.org/wiki/User:ABaso_(WMF)/Extension_Responsibility

 Presuming no major issues with this, I think we should move the page to
 mw:Reading/Extension_Responsibility.


  Definitely not a *major* issue, but VipsScaler
 https://www.mediawiki.org/wiki/Extension:VipsScaler would logically
 belong together with the media handler extensions (which are all on the
 list) IMO.

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Extension Responsibility

[Adam Baso]

Okay, to be clear, VipsTest, too, right?

On Tue, Jul 21, 2015 at 4:22 PM, Gergo Tisza gti...@wikimedia.org wrote:

 On Tue, Jul 21, 2015 at 6:11 PM, Adam Baso ab...@wikimedia.org wrote:

 Shall I make it so?


 I don't see a reason not to. While one could argue both for media handlers
 belonging to Reading and to Editing, they should in any case be all at the
 same place as they require the same knowledge (familiarity with core
 MediaHandler classes, File etc). VipsScaler is not itself a media handler,
 but it is about modifying media handler behavior via hooks so it is close
 enough.

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Extension Responsibility

[Adam Baso]

Done.

On Tue, Jul 21, 2015 at 4:30 PM, Gergo Tisza gti...@wikimedia.org wrote:

 On Tue, Jul 21, 2015 at 6:27 PM, Adam Baso ab...@wikimedia.org wrote:

 Okay, to be clear, VipsTest, too, right?


 Yes, that's essentially the same extension (a different PHP endpoint in
 the same repo).

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Extension Responsibility

[Adam Baso]

Hi all -

I've been reviewing a list of extensions with Reading Engineering and
Reading Infrastructure leads - props to James Forrester for promoting this
discussion. Here's a list of extensions we believe currently falls under
Reading for triage (n.b., not all extensions will get active development
support).

https://www.mediawiki.org/wiki/User:ABaso_(WMF)/Extension_Responsibility

Presuming no major issues with this, I think we should move the page to
mw:Reading/Extension_Responsibility.

One important outstanding question:

Is MultimediaViewer appropriate for Reading given its consumption-oriented
nature? Or is this actually better suited to Editing (where there exists a
team named Multimedia)?

Some other notes:

* For skins with low utilization, we in time probably should coordinate
handover to interested community members (or discuss with community members
practical approaches for EOL).

* Regarding the Nostalgia skin, we believe it's only used on
https://nostalgia.wikipedia.org/wiki/HomePage, so maintenance would be
updating for breaking skin changes or security issues only.

* JsonConfig, ZeroBanner, ZeroPortal - we'll need to examine this more
closely. Yuri (who has deepest PHP knowledge on extensions) is now over in
Discovery, Jeff (JS  Lua) is in Reading, and now I'm managing instead of
writing lots of code.

* Collection probably belongs in Services
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Extension Responsibility

[Adam Baso]

Ah, yes, that.

On Mon, Jul 20, 2015 at 4:41 PM, Federico Leva (Nemo) nemow...@gmail.com
wrote:

 Adam Baso, 20/07/2015 22:58:

 I think we should move the page to mw:Reading/Extension_Responsibility.


 Or better, merge with
 https://www.mediawiki.org/wiki/Developers/Maintainers

 Nemo

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Extension Responsibility

[Adam Baso]

Agreed. Borrowing a snippet from the earlier discussion on this, and I
should have copied this in earlier:

This is entirely about ... fixing urgent issues that affect production,
ideally before they hit it (security issues, deprecated code, etc.). It is
not necessarily about doing planning, development, or code review, except
in as much as you want to do that and be 'good citizens' in open source and
making people happy/*etc.*.

Marking SLAs and point people will be a good idea.

Regarding the skin sunset concept, glad you pointed out that thread. Will
need to review the material. I understand it's complex.


On Monday, July 20, 2015, Jon Robson jdlrob...@gmail.com wrote:

 A SLA and point person for each of these extensions would be a good
 next step. I worry that saying the reading vertical maintains the
 Cologne blue skin sets an expectation that we will be code reviewing
 all patches for Modern which is simply untrue.

 This may also be a good time to revisit this thread...
 https://www.marc.info/?l=wikitech-lm=139448582829276w=3


 On Mon, Jul 20, 2015 at 4:41 PM, Federico Leva (Nemo)
 nemow...@gmail.com javascript:; wrote:
  Adam Baso, 20/07/2015 22:58:
 
  I think we should move the page to mw:Reading/Extension_Responsibility.
 
 
  Or better, merge with
 https://www.mediawiki.org/wiki/Developers/Maintainers
 
  Nemo
 
  ___
  Mobile-l mailing list
  Mobile-l@lists.wikimedia.org javascript:;
  https://lists.wikimedia.org/mailman/listinfo/mobile-l



 --
 Jon Robson
 * http://jonrobson.me.uk
 * https://www.facebook.com/jonrobson
 * @rakugojon

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [reading-wmf] interesting topic readouts

[Adam Baso]

Fun visualizations!

-- Forwarded message --
From: Toby Negrin tneg...@wikimedia.org
Date: Thu, Jul 16, 2015 at 11:58 AM
Subject: [reading-wmf] interesting topic readouts

snip

https://www.wikidata.org/wiki/Wikidata:Statistics/Wikipedia
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] mobiledot and wapdot removal

[Adam Baso]

Provided this on wikitech-l, too:

Looks like the user pageviews for wap.wikipedia.org and
mobile.wikipedia.org subdomains
are approximately 0.02% of the size of pageviews for m.wikipedia.org subdomains
based on a recent one day check.

hive select count(*) from
wmf.webrequest where
year = 2015 and month = 7 and day = 14
and access_method = 'mobile web'
and (uri_host like '%.wap.wikipedia.org' OR uri_host like '%.
mobile.wikipedia.org')
and is_pageview = true and agent_type = 'user';

35,543

hive select count(*) from
wmf.webrequest where
year = 2015 and month = 7 and day = 14
and access_method = 'mobile web'
and uri_host like '%.m.wikipedia.org'
and is_pageview = true and agent_type = 'user';

202,024,891

On Thu, Jul 16, 2015 at 5:36 AM, Adam Baso ab...@wikimedia.org wrote:

 There's a ticket for removing mobile.wikipedia.org and wap.wikipedia.org
 domains/subdomains, which are legacy domain names superseded by
 m.wikipedia.org and its subdomains.

 https://phabricator.wikimedia.org/T104942

 The rationale for the removal of these legacy domain names is to help
 support HSTS preloading in browsers with the existing TLS SAN cert.

 After review of the ticket, can anyone think of a compelling reason to
 keep those old domain names?

 I opened a separate thread about this on wikitech-l under a different
 subject about this as well.

 -Adam

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [QA] How make to make your (stable) browser tests voting

[Adam Baso]

FYI


-- Forwarded message --
From: Željko Filipin zfili...@wikimedia.org
Date: Sat, Jul 11, 2015 at 12:35 AM
Subject: Re: [QA] How make to make your (stable) browser tests voting
To: QA for Wikimedia projects. q...@lists.wikimedia.org


Amazing. Thanks Dan and everybody else that made this happen.

Željko

On Sat, Jul 11, 2015 at 1:29 AM, Dan Duvall dduv...@wikimedia.org wrote:

 Standing on the successes of Barry, the browser-test bot that Reading has
 been using recently to test Gerrit patches before merging them, we've taken
 the next logical step and implemented a JJB builder/template that can do
 the same but is fully integrated into the Gerrit/Zuul pipeline(s). I've
 been working out some of the kinks in it this week, and I think it's
 finally working well enough for general use.

 Big thanks to Legoktm and Krinkle for helping to refactor/generalize the
 support builders/templates/scripts that were currently being used to
 support QUnit tests, and to Jon Robson and the Reading team for setting up
 Barry, proving that a well curated set of end-to-end tests can be stable
 enough for this purpose.

 See here for details on how to try it out!
 https://www.mediawiki.org/wiki/Continuous_integration/Browser_tests

 --
 Dan Duvall
 Automation Engineer
 Wikimedia Foundation http://wikimediafoundation.org

 ___
 QA mailing list
 q...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/qa



___
QA mailing list
q...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/qa
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Reading/API/services tech sync meeting notes

[Adam Baso]

Thanks, Bernd. For the edification of the list, I missed my meeting alert
somehow and when Brian pinged me on IRC I actually told him we should just
cancel this week! I'm glad Bernd and Gabriel met anyway. Brian, Bernd,
Gabriel, sorry about the mixup!

-Adam



-Adam

On Tue, Jul 14, 2015 at 8:50 PM, Bernd Sitzmann be...@wikimedia.org wrote:

 This time we only had Gabriel from the RESTBase services team and myself
 from the Android/Mobile Content service team attending.
 We basically talked about the status of the Mobile Content Service and
 plans to moving forward.

 See the notes at https://etherpad.wikimedia.org/p/ReadingAPIServices.

 Cheers,
 Bernd


 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l


___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l