Re: [WikimediaMobile] [Wikitech-l] MobileFrontend disruption: Plans to break Minerva out into its own repository

[Jon Robson]

This is now done and deployed in production! Thanks to everyone involved.
Special thanks to Tyler and Chad for their help with the rather
unexpectedly messy deployment.

https://phabricator.wikimedia.org/T171000

The resulting repos can be seen here:
https://github.com/wikimedia/mediawiki-skins-MinervaNeue
https://github.com/wikimedia/mediawiki-extensions-MobileFrontend

The next step would be to break the MobileFrontend dependency on the
Minerva skin. I've setup an epic
https://phabricator.wikimedia.org/T171000 (subtasks
to be filed as I find them) and would appreciate help doing this if anyone
is looking for a fun side project and interested in improving our skin
ecosystem!

There is a milestone on the MinervaNeue project tracking all open bugs:
https://phabricator.wikimedia.org/project/board/2799/

Your help is welcomed and appreciated!!




‪On Tue, Jul 4, 2017 at 10:46 AM ‫יגאל חיטרון‬‎ <khit...@post.bgu.ac.il>
wrote:‬

> Hi. The link [5] is dead.
> IKhitron
>
>
> 2017-07-04 20:45 GMT+03:00 Gergo Tisza <gti...@wikimedia.org>:
>
>> Nice! Thanks for working on this.
>>
>> On Mon, Jul 3, 2017 at 7:03 PM, Jon Robson <jrob...@wikimedia.org> wrote:
>>
>> > Dear all
>> > Back in 2014, Legoktm made the sensible suggestion [1] that we should
>> pull
>> > the skin portion of code from the MobileFrontend extension.
>> >
>> > I've spent the last few months making it possible and I now plan to make
>> > this a reality. I now plan to make this change on the 12th&13th July
>> with
>> > Chad (RainbowSprinkles) [2].
>> >
>> > I'm writing to give notice; answer questions and minimise the disruption
>> > that may cause. A while back when Vector was pulled out of MediaWiki
>> core,
>> > there was a little bit of pain so I'm keen to help people avoid this.
>> >
>>
> > *Developers:*
>
>
>> > Please make sure you update vagrant. Vagrant will install the new skin
>> as
>> > part of the MobileFrontend role and provided you do `vagrant git-update`
>> > you will not experience any breakage.
>> >
>> > If you are not using Vagrant, please install the new skin [3] and load
>> it
>> > using wfLoadSkin (after including MobileFrontend extension). When
>> > MobileFrontend stops working thats a sign you need to pull the latest
>> code
>> > from Master.
>> >
>>
> > *3rd parties who are using MobileFrontend in deployed wikis*
>
>
>> > Please be aware of this change when updating MobileFrontend. To be safe
>> > you should install the MinervaNeue skin [3] as part of your deploy
>> process
>> > and keep an eye on compatibility.
>> >
>> > The MinervaNeue skin and MobileFrontend are being kept backwards
>> > compatibility to ensure we do not break anything in Wikimedia's
>> production
>> > cluster, which is detailed in the Phabricator task [4].
>> >
>>
> > *Translators*
>
>
>> > As part of the migration I will be porting over translations to the new
>> > skin from MobileFrontend. There may be some changes to the message keys
>> > during this period of time so please bare this in mind when translating.
>> > The goal is to avoid unnecessary translations!
>> >
>>
> > *Why are you doing this?!!?*
>
>
>> > I've tried to write up this here [5]. Feel free to ask questions on the
>> > talk page there. It's a good conversation to have.
>> >
>>
> > *Can I just use MobileFrontend?*
>
>
>> > Sure. If you just have MobileFrontend it will give you a separate mobile
>> > site and you are free to use whatever skin you want there.
>> > https://www.mediawiki.org/wiki/Extension:MobileFrontend#Setup_a_skin
>> >
>>
> > *Can I just use the Minerva skin and throw away my mobile site?*
>
>
>> > Not quite. But that's the next step that this enables... :) More on that
>> > later.
>> >
>>
> > *Any questions?*
>
>
>> > Feel free to reply to this thread with any concerns or questions you
>> have
>> > or any way I can improve this migration.
>> >
>>
> > *Can I do nothing?*
>
>
>> > If you do not update sure, but if you are updating your instance it's
>> > going to break soon if you do not do anything.
>> >
>> > Let me know if any questions!
>> > Jon
>> >
>> > [1] https://phabricator.wikimedia.org/T71366
>> > [2]  https://wikitech.wikimedia.org/wiki/Deployments#Week_of_July_10th
>> > [3] https://github.com/wikimedia

[WikimediaMobile] MobileFrontend disruption: Plans to break Minerva out into its own repository

[Jon Robson]

Dear all
Back in 2014, Legoktm made the sensible suggestion [1] that we should pull
the skin portion of code from the MobileFrontend extension.

I've spent the last few months making it possible and I now plan to make
this a reality. I now plan to make this change on the 12th&13th July with
Chad (RainbowSprinkles) [2].

I'm writing to give notice; answer questions and minimise the disruption
that may cause. A while back when Vector was pulled out of MediaWiki core,
there was a little bit of pain so I'm keen to help people avoid this.

*Developers:*
Please make sure you update vagrant. Vagrant will install the new skin as
part of the MobileFrontend role and provided you do `vagrant git-update`
you will not experience any breakage.

If you are not using Vagrant, please install the new skin [3] and load it
using wfLoadSkin (after including MobileFrontend extension). When
MobileFrontend stops working thats a sign you need to pull the latest code
from Master.

*3rd parties who are using MobileFrontend in deployed wikis*
Please be aware of this change when updating MobileFrontend. To be safe you
should install the MinervaNeue skin [3] as part of your deploy process and
keep an eye on compatibility.

The MinervaNeue skin and MobileFrontend are being kept backwards
compatibility to ensure we do not break anything in Wikimedia's production
cluster, which is detailed in the Phabricator task [4].

*Translators*
As part of the migration I will be porting over translations to the new
skin from MobileFrontend. There may be some changes to the message keys
during this period of time so please bare this in mind when translating.
The goal is to avoid unnecessary translations!

*Why are you doing this?!!?*
I've tried to write up this here [5]. Feel free to ask questions on the
talk page there. It's a good conversation to have.

*Can I just use MobileFrontend?*
Sure. If you just have MobileFrontend it will give you a separate mobile
site and you are free to use whatever skin you want there.
https://www.mediawiki.org/wiki/Extension:MobileFrontend#Setup_a_skin

*Can I just use the Minerva skin and throw away my mobile site?*
Not quite. But that's the next step that this enables... :) More on that
later.

*Any questions?*
Feel free to reply to this thread with any concerns or questions you have
or any way I can improve this migration.

*Can I do nothing?*
If you do not update sure, but if you are updating your instance it's going
to break soon if you do not do anything.

Let me know if any questions!
Jon

[1] https://phabricator.wikimedia.org/T71366
[2]  https://wikitech.wikimedia.org/wiki/Deployments#Week_of_July_10th
[3] https://github.com/wikimedia/mediawiki-skins-MinervaNeue
[4] https://phabricator.wikimedia.org/T166748
[5]
https://www.mediawiki.org/wiki/Reading/Web/MobileFrontend_and_Minerva#..._but_why_do_we_care_about_Minerva_as_a_desktop_skin.3F
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Reading monthly update for May 2017

[Jon Robson]

On Sun, Jun 18, 2017 at 7:08 PM Kaartic Sivaraam <
kaarticsivaraam91...@gmail.com> wrote:

> > On Mon, 12 Jun 2017 18:21:10, Jon Robson <jrob...@wikimedia.org>
> > wrote:
> >
> > It's deployed!
>
> Good to hear that! I tried to print a page using my mobile and it
> looked great! Great work people. It would be better if the following
> were considered,
>
> 1. Currently it seems that the images found in the unexpanded sections
> aren't rendered in the PDF file. As a result a blank space is found in
> their place and the image description seems to be describing a blank
> space!! Possible solutions are,
>
> i) Trying to render all images found in a page regardless of whether
> the sections are expanded or not
>
> ii) Don't print the unexpanded sections
>
> I would love to see (i) being chosen as a solution. :)
>

Yes sadly this is a known problem and relates to the fact we lazy load
images. You can follow what we discussed and what our plans are going
forward here:
https://phabricator.wikimedia.org/T162414

The short of it is:
* There is no way to asynchronously load images when a print is detected
* We filed a bug upstream against the HTML standard:
https://github.com/whatwg/html/issues/2532#issuecomment-294021096
* It looks like the only way to avoid this problem in the mean time is to
provide a non-browser print button.


> 2. Rendering links would be helpful but it seems to clutter up the
> reading experience of printed articles which have a lot of links in
> them (e.g. God). It would be better if some kind of alternative was
> chosen to highlight links such that they don't distract the user from
> their main motive (reading).
>

I'll defer to Nirzar on this one!

>
> > Note they will only work if you are using the print function on your
> > phone... not if you are viewing the mobile site on desktop :)
> >
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Reading monthly update for May 2017

[Jon Robson]

On Mon, Jun 12, 2017 at 3:41 AM Kaartic Sivaraam 
wrote:

>
>  Original Message 
> Subject: [WikimediaMobile] Reading monthly update for May 2017
> Local Time: June 1, 2017 4:16 AM
> UTC Time: May 31, 2017 10:46 PM
> From: ckoer...@wikimedia.org
> To: wikitec...@lists.wikimedia.org, mobile-l@lists.wikimedia.org
>
> Hello,
> Welcome to the first in a reoccurring monthly update from the Reading
> department at the Wikimedia foundation. Here we'll provide a quick summary
> of things that are currently being worked on. An archive of past activity
> can be found on Mediawiki.org. Feedback and questions are welcome.
>
>
> == Web ==
>
> === New print styles for the mobile web ===
> Based on the findings of the New Readers team, we learned that users are
> increasingly getting information online, and then sharing or consuming it
> offline. In terms of mobile devices, this often means taking screenshots of
> useful information, or saving the article as a PDF to read later on their
> phones. Our older print styles did not account for reading on mobile
> devices - they focused on paper printing. We will update our print styles
> for mobile devices to account for offline consumption, making them easier
> to read and navigate, as well as accounting for missing crucial information
> such as article title and branding.[0]
>
> I would love to see this getting deployed :)
>
It's deployed!
Note they will only work if you are using the print function on your
phone... not if you are viewing the mobile site on desktop :)


>
> === Moving the lead section before the infobox on the mobile web ===
> Over the past few quarters, we've been focusing on the top of the article
> experience on the mobile website. One of the identified issues was that,
> for articles which contained an infobox, users were exposed to the infobox
> content prior to having an overview of the subject of the article itself.
> To improve on this issue, we've moved the lead section of each article so
> that it appears before the infobox on mobile, allowing readers to have
> access to the main content of the page earlier. This change is now live on
> all projects. Before, [0] After [1]
>
> === Completing related pages deployment ===
> Since March 30, 2017, we have been running a test on enwiki on the related
> pages feature. Over the past month, we collected data and analyzed the
> performance of the feature.[2] Based on the results, we completed the
> deployment of the feature on mobile English Wikipedia.
>
> These seem to be great features too. Thanks a lot for the great work!
> --
> Regards,
> Kaartic
>
> ___
> 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] editing smaller headings

[Jon Robson]

Interestingly due to a bug we do show them on English Wikipedia and I was
wondering myself whether that was the right behaviour or not.

https://phabricator.wikimedia.org/T130898#2675368

On Wed, 5 Oct 2016, 7:45 a.m. Stephen Niedzielski, <
sniedziel...@wikimedia.org> wrote:

> I think this might be a question for design (cc'd). We do have long press
> to edit text anywhere within the article.
>
> On Wed, Oct 5, 2016 at 8:14 AM, Amir E. Aharoni <
> amir.ahar...@mail.huji.ac.il> wrote:
>
> Hi,
>
> I've been asked by a Hebrew Wikipedia editor: Why is it only possible to
> have the edit button at the top headings (==), but not smaller headings
> (===, etc.)?
>
> This should be in
> https://www.mediawiki.org/wiki/Wikimedia_Apps/Android_FAQ#Editing :)
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
>
> ___
> 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] Mobile site is now lazy loading images

[Jon Robson]

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/Performance/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

Re: [WikimediaMobile] Redlinks in Android app

[Jon Robson]

Please also note the parent bug and rfc which blocks that. I've cced
wikitech in case anyone has an update.

https://phabricator.wikimedia.org/T39902
On 3 Aug 2016 5:14 a.m., "Stephen Niedzielski" 
wrote:

> Hello! Thank you for the report! This issue is currently being tracked
> here[0]. We had hoped to fix this properly but maybe we should consider a
> temporary change in the client to handle this more gracefully.
>
> [0] https://phabricator.wikimedia.org/T119266
>
> On Wed, Aug 3, 2016 at 4:21 AM, Andy Mabbett 
> wrote:
>
>> The Android Wikipedia app shows Wikipedia's red links as blue links,
>> then returns a user-unfriendly 404 error page, with the somewhat
>> dishonest text "an unknown error occurred".
>>
>> Alternative, and better, behaviours would be one of (in no particular
>> order):
>>
>> * Show a red link; behave like desktop Wikipedia
>>
>> * Show a red link; when the link is selected, show a customised 404
>> page, which advises users how start a new article
>>
>> * Show red text, but make it non linking (i.e. "unclickable")
>>
>> * Remove the link and colour-styling, and render ordinary text
>>
>> * Fix the erorr page so it says "Sorry, that page does not exist",
>> with a link to a guide to starting a new article
>>
>> --
>> Andy Mabbett
>> @pigsonthewing
>> http://pigsonthewing.org.uk
>>
>> ___
>> 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] Getting link to a contact form to work using mobile view

[Jon Robson]

 SkinTemplateOutputPageBeforeExec should be fine for this but
extension loading may interfere.

It's used in WikimediaMessages extension to add the developers and
cookie statement links to the footer.
https://github.com/wikimedia/mediawiki-extensions-WikimediaMessages/blob/master/WikimediaMessages.hooks.php#L221
You can restrict to just mobile by wrapping the hook in the if statement:
$context= MobileContext::singleton();
if ($context->shouldDisplayMobileView() ) {
// add links
}

However... this hook needs to be registered after MobileFrontend
installs its own hooks.
Last time I checked (but didn't verify) pasting into LocalSettings.php
caused the hook to register after MobileFrontend (which loads via
extension loading). I'm not sure if this is a known bug or a
workaround exists.


On Mon, Aug 1, 2016 at 2:22 AM, Sam Smith  wrote:
> On Fri, Jul 29, 2016 at 11:22 PM, Bryan Davis  wrote:
>>
>> It would be a nice thing for someone to document this hook on
>> mediawiki.org. It seems that there are several hooks for
>> MobileFrontend that are currently undocumented [3].
>
>
> Duly Phabricated! [0]
>
> -Sam
>
> [0]: https://phabricator.wikimedia.org/T141755
>
> ___
> 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] [Wikimedia-l] Fwd: "Among mobile sites, Wikipedia reigns in terms of popularity"

[Jon Robson]

On Wed, May 11, 2016 at 2:07 PM, James Forrester
 wrote:
> On 11 May 2016 at 12:50, Michael Peel  wrote:
>>
>> Isn't it time to start moving to responsive mediawiki templates
>> (https://en.wikipedia.org/wiki/Responsive_web_design), rather than having a
>> separate mobile interface/URL?
>>
>>
>> For a practical example, see the BBC News website
>> (http://www.bbc.co.uk/news), which is the same website on all devices, it
>> just rescales the content/navigation/layout to suit the device. (Try
>> resizing your web browser on your computer to the size of a mobile web
>> browser to see what I mean.)
>
>
Since you brought up this example the BBC news site used to have a
mobile and desktop site... just like we did.

Eventually, they got their mobile site to a good state, removed the
desktop site and used the mobile site:
http://www.bbc.com/news/technology-31966686

It's worth pointing out we are a smaller amount of volunteers with a
far more complex ecosystem (extensions) so it's likely to take us much
longer.

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

Re: [WikimediaMobile] The future of Related Pages feature

[Jon Robson]

1) The related articles are editable via the {{RelatedArticles}} magic
word. They have been since day one of launch.

2) There is a great conversation around how this feature could serve as a
see also replacement here:https://www.mediawiki.org/w/

index.php

?title=Topic:

Syte4nkfr13nlfw4

=history


3) it's a beta feature and as far as I'm aware there are no plans to push
this to all users without community buy in.

4) in general I think beta features are a great way to have conversations
about how we can make the wiki better. I think this is generating good
conversations - especially around the PageImages extension and the
usefulness of see also and the exposure of the more like API.
On 4 Apr 2016 9:53 a.m., "John Mark Vandenberg"  wrote:

> This feature appears to be an automated edition of the "See also" section
> on English Wikipedia. Having both Related Articles and See also feels like
> a usability issue.
>
> Has there been any discussions on the wikis about this overlap?
> On 24 Mar 2016 05:18, "Moushira Elamrawy"  wrote:
>
>> Hello everyone,
>>
>> Related pages feature has been in beta for over two months now,  the
>> future of the feature depends on our discussions.  While we currently don't
>> have a clear process for deciding collaboratively on an all languages
>> product, Alsee and the reading team have put together this document on meta
>> [0], as a request for comment, seeking comments and ideas on modifications
>> required, and how to further test the feature.  In fact, we are not sure if
>> an rfc is the best strategy to move forward with product decisions, but
>> lets see how the discussion evolves, and we might explore the need for a
>> different process, as we move on with this one.
>>
>> We managed to translate a brief introduction about the topic, please feel
>> free to fully translate the document and/or further promote the discussion
>> on your wiki.  We are trying hard to avoid having an English centric
>> discussion for a feature that could be available across all language
>> projects, and while we don't have a clear solution for this, we are trying
>> this method as an experiment, where at least our communities can leave
>> comments in their preferred language if they aren't comfortable writing in
>> English but they can understand it.
>>
>> Please check the page, help with translation or promotion in your
>> Wikipedia, and most importantly, comment on how you think it can evolve. :)
>>
>> Lets see how this works!
>>
>>
>> All the best,
>> M
>>
>> [0] https://meta.wikimedia.org/wiki/Requests_for_comment/Related_Pages
>>
>> ___
>> 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-wmf] Usability of the mobile web site

[Jon Robson]

I've submitted patches on 2 of the 3 issues. Review welcomed.
https://gerrit.wikimedia.org/r/273542
https://gerrit.wikimedia.org/r/273540


On Thu, Feb 25, 2016 at 10:09 PM, Ori Livneh  wrote:
> So, with mobile usage creeping up to and even exceeding desktop, I figured I
> was overdue for switching over to the mobile skin, so I get to know it a bit
> better.
>
> I think it looks very attractive and modern. But it is marred by a usability
> issue so severe that it is borderline unusable to me, and that is the manner
> in which the content jumps around as the page is loading.
>
> The problem is that sections are initially loaded in an expanded state, and
> then collapsed by JavaScript code which is only executed on document ready.
> This code also pulls in interface elements that are drawn quite late. Even
> on a fast connection, a quick reader can be halfway through reading a
> paragraph when all of a sudden the content suddenly and rudely shifts to
> side or is revoked entirely.
>
> The result is very dizzying and unpleasant. As a result, I find that I have
> to train myself *not* to start reading the text in front of me until the
> page has settled down.
>
> I don't think that this is good performance. It may get something to render
> sooner than it otherwise would have, but it ends up delaying the time it
> takes for the page to settle into its fully-loaded layout, which forces the
> user to wait longer (or tolerate the electric jolt of having the content
> skip around mid-sentence).
>
> Roan filed this as https://phabricator.wikimedia.org/T126825 . I set its
> priority to "high", and I hope this e-mail gives some context as to why.
>
> ___
> 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] MobileFrontend+Wikibase security patch

[Jon Robson]

A security vulnerability has been discovered in MediaWiki setups which
use both Wikibase and MobileFrontend.

All projects in the Wikimedia cluster have been since patched but if
you use these two extensions please be sure to apply the fix.

Patch file and issue are documented on https://phabricator.wikimedia.org/T125684

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

Re: [WikimediaMobile] Lead section improvement contest on English Wikipedia

[Jon Robson]

Is the data from the analysis we did on MobileWebSectionUsage up on
meta wiki yet? If so could you link to it?


On Wed, Jan 27, 2016 at 11:03 AM, Tilman Bayer <tba...@wikimedia.org> wrote:
> User:Casliber has started an editing contest on the English Wikipedia
> focused on improving or adding lead (intro) sections:
> https://en.wikipedia.org/wiki/Wikipedia:Take_the_lead! (open until
> this Sunday, January 31)
>
> Notably, the invitation cites mobile readers as a motivation:
>
> "Many articles on the English Wikipedia have deficient or poorly
> written leads that do not summarise the article or present the
> information in an engaging manner. With increased mobile phone usage,
> this is becoming more of an issue, because mobile interfaces often
> show the lead alone, with other sections collapsed."
>
> I added the subsequent sentence, to support this point with data from
> the analysis that JonR and I did some weeks ago for the
> MobileWebSectionUsage data. This also lead to some interesting
> community discussion in several places, and someone added that chart
> to 
> https://en.wikipedia.org/wiki/Wikipedia:How_to_create_and_manage_a_good_lead_section
> . It's a great example of how we can support editors' work with
> readership data beyond mere pageviews (I also submitted a Wikimania
> talk about this topic earlier this month).
>
> --
> Tilman Bayer
> Senior Analyst
> Wikimedia Foundation
> IRC (Freenode): HaeB
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> 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

Re: [WikimediaMobile] Cross-post: pageviews.js—A JavaScript Client Library for the Wikimedia Pageviews API for Node.js and the browser

[Jon Robson]

I can report this was super easy to use and I've now incorporated it into
https://pushipedia.wmflabs.org/ - now I can keep up with what all the cool
kids are reading!

Sadly right now it just sends me the star wars episode 7 link every
morning... but I'm looking forward to the day the star wars buzz dies down
:)


On Tue, Dec 15, 2015 at 5:21 PM, Adam Baso  wrote:

> Interesting! Also, so is this:
>
> http://top.hatnote.com
>
>
> -- Forwarded message --
> From: *Thomas Steiner* 
> Date: Tuesday, December 15, 2015
> Subject: [Wiki-research-l] pageviews.js—A JavaScript Client Library for
> the Wikimedia Pageviews API for Node.js and the browser
> To: Research into Wikimedia content and communities <
> wiki-researc...@lists.wikimedia.org>
> Cc: Analytics List 
>
>
> Dear all,
>
> First and foremost, thanks for making the Wikimedia Pageviews API
> available; your work is highly appreciated and super useful! As a
> modest "thank you", I am happy to release the JavaScript client
> library pageviews.js for Node.js and the browser to make working with
> this API easy for JavaScript developers. Please find the code and all
> instructions at [1]. The library adds some convenience functions
> (getting batch pageviews and limiting the number of results) that were
> inspired by Dan Andreescu's Python library [2] and is Promise-based:
>
> ===
> var pageviews = require('pageviews');
>
> // Getting pageviews for a single article
> pageviews.getPerArticlePageviews({
>   article: 'Berlin',
>   project: 'en.wikipedia',
>   start: '20151201',
>   end: '20151202'
> }).then(function(result) {
>   console.log(JSON.stringify(result, null, 2));
> }).catch(function(error) {
>   console.log(error);
> });
>
> // Getting top-n items ranked by pageviews for multiple projects
> pageviews.getTopPageviews({
>   projects: ['en.wikipedia', 'de.wikipedia'], // Plural
>   year: '2015',
>   month: '12',
>   day: '01',
>   limit: 2 // Limit to the first n results
> }).then(function(result) {
>   console.log(JSON.stringify(result, null, 2));
> }).catch(function(error) {
>   console.log(error);
> });
> ===
>
> On a more technical note—trying to be a good citizen [3]—the client
> library sets an identifying User-Agent header in Node.js mode.
> However, trying to set the corresponding X-User-Agent (note the "X-")
> header from a browser context (XMLHttpRequest cannot override the
> browser's intrinsic User-Agent for security reasons), this fails with
> an error message "Request header field X-User-Agent is not allowed by
> Access-Control-Allow-Headers in preflight response". Maybe you could
> change your CORS settings and include X-User-Agent in your
> Access-Control-Allow-Headers?!
>
> Hope this is useful.
>
> Thanks,
> Tom
>
> --
> [1] pageviews.js: https://github.com/tomayac/pageviews.js
> [2] python-mwviews: https://github.com/mediawiki-utilities/python-mwviews
> [3] User-Agent requirement: https://wikimedia.org/api/rest_v1/?doc
>
> --
> Dr. Thomas Steiner, Employee (blog.tomayac.com, twitter.com/tomayac)
>
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
> Registergericht und -nummer: Hamburg, HRB 86891
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.29 (GNU/Linux)
>
>
> iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtP5://xKcd.c0m/1181/
> -END PGP SIGNATURE-
>
> ___
> Wiki-research-l mailing list
> wiki-researc...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wiki-research-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

[Jon Robson]

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  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  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
>

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

[WikimediaMobile] Wikipedia in Indonesia

[Jon Robson]

Whilst in Indonesia I was subjected to some horrifically slow
connections. Although I was only ever on WiFi, connection speeds were
on par with 2G/Edge connection.

Whilst searching the web, I saw various results (including Tripadvisor
and Wikipedia) labelled as being slow to load. When clicked I was
redirected to a product called Google Web Light [1] that had a link to
the original site and used 80% less data.

As a consumer, taking off my Wikimedia hat, I actually appreciated
this experience for Wikipedia. When I clicked view original the
process was so painfully slow I eventually found myself just living
with it as it didn't devoid me of any activities as a reader (at the
time connection was so slow editing just wasn't on my mind). For sites
such as tripadvisor and hotels.com the experience was so bad, to look
things up I ended up always switching to the original. This was more
annoying as I was unable to find some global opt out for the entire
site.

To crudely describe what the weblight experience does:
1) It loads just lead content
2) It strips lots of styles and some JS but not all JavaScript (for
instance main menu works)
3) IT throws away features such as search, editing, talk pages, category
4) It bundles all links into the left menu accessible by the hamburger

I took some screenshots of the experience [2] - you can see the
content is available but not well styled - it's how I'd imagine an AMP
experience of Wikipedia to look like and you can play around with it
yourself [3].

To summarise what this means to us:
Google are making it possible for users with slow connections to get
to our content
... thus various traffic never hits our servers.
... those users cannot edit.
(although on plus side they do see our fundraising banners :-))

We can opt out of this experience via headers but right now I strongly
believe we have to improve the speed of our offering.

I think this is in reach and will be a subject at the dev summit in
various forms.
The reading team has been experimenting in ways to optimise our page
content by using Parsoid [3] specifically to explore how we can
optimise views to HTML heavy pages such as Barack Obama. I'm looking
forward to sharing results.

[1] https://googleweblight.com/?lite_url=https://en.m.wikipedia.org/wiki/Barack
Obama
[2] http://imgur.com/a/dO4wt
[3] 
https://www.mediawiki.org/w/index.php?title=Reading/Web/Projects/Barack_Obama_in_under_15_seconds_on_2G

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

Re: [WikimediaMobile] [Android application]Project WikiJourney

[Jon Robson]

I'm not an app developer but if you need a beta tester or any specific
guidance on how you are using the API please let me know. It would also be
great to hear from you what pain points you ran into whilst building this -
specifically it would be good to understand we can improve in MediaWiki's
API to better support what you are trying to do.

On Fri, Dec 4, 2015 at 9:45 AM, Paul Arzelier  wrote:

> Yes!
> Because we don't know if it's well-written enough so that someone who's
> not in the project could read, understand what our code is doing and modify
> it without much trouble...
>
> Regards,
> Paul
>
>
> Le 04/12/2015 18:19, Toby Negrin a écrit :
>
> Hi Paul -- Are you asking for some sort of code or architecture review for
> your application?
>
> Best,
>
> -Toby
>
> On Fri, Dec 4, 2015 at 1:26 AM, Paul Arzelier 
> wrote:
>
>> Hi,
>>
>> I'm currently developing, with some friends, an application called
>> WikiJourney to promote « free » (as in a speech) tourism. For now, it can
>> locate an android user on a map, display points of interests extracted from
>> wikidata and show the user the associated wikipedia articles.
>>
>> The application will shortly be able to create touristic « tours », but
>> currently, we need some feedback from people, and not just user-related
>> feedback...
>> We feel our code (https://github.com/WikiJourney/wikijourney_app/) is a
>> bit messy, but don't know if there's a precise « coding convention » here
>> at Wikimedia.
>>
>> What do you think of it?
>>
>> Thanks by advance for your feedback,
>>
>> The WikiJourney Team
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>
>
> --
> Paul ARZELIER
> Élève ingénieur à l'École Centrale de Lille
> 2014-2017
>
>
> ___
> 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 - WikidataPageBanner properties available from API

[Jon Robson]

and cc. Sumit who has made all of this awesome stuff happen (not sure
if he's on the mailing list - hopefully he will join if not :-))


On Fri, Dec 4, 2015 at 9:44 AM, Dmitry Brant <dbr...@wikimedia.org> wrote:
> Wow! Very cool.
>
>
> On Fri, Dec 4, 2015 at 12:42 PM, Jon Robson <jrob...@wikimedia.org> wrote:
>>
>> Thanks to Sumit's latest change you can now access focus area and
>> image directly from the API in pageprops [1].
>>
>> The image comes from editor, if not present Wikidata and soon (if
>> someone merges it) from PageImages [2].
>>
>> Currently this is only deployed on WIkivoyage but by deploying the
>> extension on Wikipedia and disabling article rendering you could use
>> the API for the app.
>>
>> Currently updating the origin x and origin y values with the API is
>> not easy and as nice as it could be but it is potentially doable by
>> editing the entire page and using some clever regexps.
>>
>> Something to think about!
>>
>> [1]
>> http://en.wikipedia.beta.wmflabs.org/wiki/Special:ApiSandbox#action=query=pageprops=json=WikidataPageBanner_example_1
>> [2] https://gerrit.wikimedia.org/r/#/c/239010/
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
>
>
> --
> Dmitry Brant
> Mobile Apps Team (Android)
> Wikimedia Foundation
> https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering
>

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

Re: [WikimediaMobile] MobileWebClickTracking schema

[Jon Robson]

That said I'm confused to see 3 events for 27th November 2015 from
Russian and English Wikipedia so this table is growing - but I suspect
this might be due to some mirror site?


On Fri, Dec 4, 2015 at 1:13 PM, Jon Robson <jdlrob...@gmail.com> wrote:
> Jon This table isn't used to my knowledge any more.
> MobileWebUIClickTracking tracks clicks to hamburger/search/language etc..
> MobileWebMainMenuClickTracking_11568715 clicks inside menu
> MobileWebWatchlistClickTracking_10720361 inside watchlist feature
>
> MobileWebDiffClickTracking_10720373 within diff
> The discovery team has MobileWebSearch_12054448 which tracks search behaviour.
>
>
> On Fri, Dec 4, 2015 at 12:09 PM, Jon Katz <jk...@wikimedia.org> wrote:
>> I think we should remove search events from it, but currently this is the
>> only schema that tracks article-level actions.
>>
>> A while back we shrunk its predecessor by removing the hamburger menu
>> actions, but the search actions account for the vast bulk of this table.
>> Now that there is a separate search action table, I think we can remove
>> search and shrink the table dramatically.
>> -J
>>
>> On Fri, Dec 4, 2015 at 11:24 AM, Nuria Ruiz <nu...@wikimedia.org> wrote:
>>>
>>> Team:
>>>
>>> This schema https://meta.wikimedia.org/wiki/Schema:MobileWebClickTracking
>>> has a lot of data in eventlogging. Tables are getting huge.
>>> Too huge to be queried.
>>>
>>> I remember that we agreed to split this schema in several others, can we
>>> do away with this schema now?
>>>
>>> Thanks,
>>>
>>> ___
>>> 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
>>
>
>
>
> --
> Jon Robson
> * http://jonrobson.me.uk
> * https://www.facebook.com/jonrobson
> * @rakugojon



-- 
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

Re: [WikimediaMobile] MobileWebClickTracking schema

[Jon Robson]

Jon This table isn't used to my knowledge any more.
MobileWebUIClickTracking tracks clicks to hamburger/search/language etc..
MobileWebMainMenuClickTracking_11568715 clicks inside menu
MobileWebWatchlistClickTracking_10720361 inside watchlist feature

MobileWebDiffClickTracking_10720373 within diff
The discovery team has MobileWebSearch_12054448 which tracks search behaviour.


On Fri, Dec 4, 2015 at 12:09 PM, Jon Katz <jk...@wikimedia.org> wrote:
> I think we should remove search events from it, but currently this is the
> only schema that tracks article-level actions.
>
> A while back we shrunk its predecessor by removing the hamburger menu
> actions, but the search actions account for the vast bulk of this table.
> Now that there is a separate search action table, I think we can remove
> search and shrink the table dramatically.
> -J
>
> On Fri, Dec 4, 2015 at 11:24 AM, Nuria Ruiz <nu...@wikimedia.org> wrote:
>>
>> Team:
>>
>> This schema https://meta.wikimedia.org/wiki/Schema:MobileWebClickTracking
>> has a lot of data in eventlogging. Tables are getting huge.
>> Too huge to be queried.
>>
>> I remember that we agreed to split this schema in several others, can we
>> do away with this schema now?
>>
>> Thanks,
>>
>> ___
>> 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
>



-- 
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

Re: [WikimediaMobile] Banner on ENWP mobile site

[Jon Robson]

On Mon, Nov 2, 2015 at 11:20 AM, Pine W  wrote:

> Hi mobilizers,
> Can you add "Template:Main Page banner" to the ENWP mobile site main page?
>
This should be a discussion for the talk page as editors control the
content...


> Thanks,
> Pine
>
> ___
> 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] Cleanup of Reading/Web/Team

[Jon Robson]

I've taken a pass at these pages too (mostly cleaning up
https://www.mediawiki.org/wiki/Reading/Web/Mobile - although still a lot
more work to happen there!)

On Sun, Oct 25, 2015 at 4:36 AM, Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:

> Hi!
>
> I've cleaned https://www.mediawiki.org/wiki/Reading/Web and moved the
> mobile specific information to
> https://www.mediawiki.org/wiki/Reading/Web/Mobile
>
> Feedback welcome!
> Cheers
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> 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

Re: [WikimediaMobile] Some interesting stuff from Google

[Jon Robson]

I'd love to go but won't be here. Let us know what you find out Volker. I'd
personally be interested in what their answer is to "should wikipedia adopt
this (and why)"
On 12 Oct 2015 12:51 pm, "Volker Eckl"  wrote:

> Google will give an introduction on AMP at SFHTML5 Meetup on 23 Oct:
> http://www.meetup.com/de/sfhtml5/events/219966898/
>
> I'm in.
>
> On Fri, Oct 9, 2015 at 6:43 PM, Jon Katz  wrote:
>
>>
>> On Fri, Oct 9, 2015 at 12:34 AM, Joaquin Oltra Hernandez <
>> jhernan...@wikimedia.org> wrote:
>>
>>> If you really wanted to, you can subset what you send to mobile browsers
>>> and get the same benefits (provided you use a really good CDN).
>>
>>
>> I think this announcement + the transcoding work Google is doing show
>> that this ^ is something we should be strongly considering. If google can
>> transcode our content and make it significantly faster (as Gergo showed in
>> another thread) and/or other sites are adopting similar technology, than
>> our users are going to expect a level of speed far higher than we can
>> currently provide.  I don't care if we use google's or our own, but do want
>> to make sure we aren't rebuilding the wheel if we don't have to.
>>
>> The conversations as to whether or not google is acting out of self
>> interest are fairly moot (they are...always), but I think Luis's points are
>> very apt about googles self interests being more closely aligned with ours
>> on the web than the other big players in this space.
>>
>> On Fri, Oct 9, 2015 at 9:27 AM, Luis Villa  wrote:
>>
>>> On Thu, Oct 8, 2015 at 5:39 PM, Toby Negrin 
>>> wrote:
>>>
 Hi Luis --

 I honestly don't see a lot of difference between Google, Twitter and
 Facebook, since they are all ad supported entities with a fiscal
 responsibility to track their users and sell the data. Apple's a bit
 different on the surface since they have a different business model. I
 agree that these are bad for the internet but so are incredibly slow web
 pages that make apps essentially required for a good experience.

>>>
>>> I agree that the companies all have (essentially[1]) the same motives at
>>> the company level. The difference is that Google's technical approach to
>>> solving the latency problem is not explicitly tied to Google or to
>>> particular Google apps. (There is a pure web demo, for example, which works
>>> in any mobile browser, including Firefox for Android, and Twitter - a
>>> Google competitor - has already adopted it.) In contrast, Facebook and
>>> Apple's "solutions" for fast reading are very explicitly tied to (1) apps,
>>> not browsers, and (2) apps specifically from those companies. There will
>>> never be a future where Facebook's solution for latency works outside of
>>> Facebook; there is (at least in theory, and possibly in practice w/
>>> Twitter) such a future with AMP.
>>>
>>> Or to put it another way: Google's solution still might not be good, but
>>> it's at least possible that it could keep content on the open web; Facebook
>>> and Apple are pretty explicitly trying to kill the open web. There is no
>>> way the long game of the FB/Apple apps lead to good outcomes for
>>> independent publishers like us.
>>>
>>>
 On the analytics, this would probably not include their use of our
 content in the knowledge graph or elsewhere

>>>
>>> Oh, definitely won't. But it might give us some leverage in those
>>> discussions - having conceded that the analytics from some cached pages
>>> should be shared, it is no longer such a huge leap to analytics on other
>>> types of "cached"/processed data.
>>>
>>>
 and also might be troublesome for those who prefer google not to track
 their reading.

>>>
>>> There is a lot of devil in those details, of course, but for those
>>> coming from Google Search (still the vast majority of our users) the first
>>> leap is already tracked/known to Google. This doesn't necessarily make that
>>> worse. (Much depends on how the caching occurs; their ability to track the
>>> *second* page you read would be new, at least for iOS users - Android users
>>> already have this problem, I believe.)
>>>
>>>
 Bryan's ticket is a good embarkation point for thinking about
 supporting new clients; Reading is also planning some Reading
 infrastructure work for the summit which could relate[1]

>>>
 [1] https://phabricator.wikimedia.org/T114542

>>>
>>> Great link, thanks.
>>>
>>> [1] The subtle difference, from our perspective, is that Google has
>>> pretty strong incentives to keep the open web viable, because making sense
>>> of (and selling ads on) the open web is their core competence. Facebook and
>>> Apple, in contrast, have no strategic reason to keep the open web viable:
>>> if they can turn every publisher into a FB-only or Apple-only publisher,
>>> they'd happily do that. Of course, an open web that doesn't depend 

Re: [WikimediaMobile] [reading-wmf] Browse Hypothesis Results

[Jon Robson]

Jon thanks so much for writing this up and thanks Joaquin for putting it on
the wiki (you beat me to it :))

I'm a little confused to the meaning of "tag impression" -  does it mean
they rendered or that the user saw them?

If the latter...
https://www.mediawiki.org/wiki/Reading/Web/Projects/Categories_Browse#/media/File:Browse-Views_and_clickthrough.png
suggests that 50% of the time a reader saw a tag (.45% of the time) (there
was a tag impression) they clicked on them (0.18%). Am I misunderstanding
what tag impression means?

Is this a fair summary?:
"When the tags were __visible__ to the user, 30-50% of the time they
clicked through to the "category page". On this page only 40% of visits
resulted in a click to an article in the list.

To me this is significant traffic... especially if made more visible.
I personally would expect normal link traffic to be higher and for this to
be a new source of engagement.

Can we clarify this on the wiki page and in this thread as I fear I'm
misunderstanding something..?

Other questions:
* What was the number of clicks to tags per visit? (were being opening new
tabs or clicking on one?)

On Tue, Oct 13, 2015 at 8:36 AM, Brian Gerstle 
wrote:

> Great experiment!  A couple questions/comments:
>
>1. The % clickthrough per category shows SF Landmarks at 120%. Is that
>correct, and if so, what does it mean?
>2. As a big believer in the power of categories as a driver for
>engagement, I would love to see more variations of this experiment w/
>different placements, in a feed, different categories, add'n of portals, as
>a FTUE, etc. (likely to have a great deal of overlap w/ cascade D: deep
>dive educational experience)
>3. Also loved the win/needs-improvement breakdown at the end
>
> Again, nice work!
>
> On Tue, Oct 13, 2015 at 11:23 AM, Jon Katz  wrote:
>
>> Thanks, Joaquin!
>>
>> On Tue, Oct 13, 2015 at 4:32 AM, Joaquin Oltra Hernandez <
>> jhernan...@wikimedia.org> wrote:
>>
>>> Thanks a lot for the detailed report Jon.
>>>
>>> I've parsed it and posted it to
>>> https://www.mediawiki.org/wiki/Reading/Web/Projects/Categories_Browse so
>>> that can keep it more accessible than the mailing list archive
>>> 
>>> .
>>>
>>> Any help with formatting or text corrections would be appreciated.
>>>
>>>
>>> On Sun, Oct 11, 2015 at 8:32 PM, Jon Katz  wrote:
>>>
 Hi Team,
 I just wanted to update you on the results of something we internally
 referred to as the '*browse' *prototype.
 TLDR: as implemented the mobile 'browse by category' test did not drive
 significant engagement.  In fact, as implemented, it seemed inferior to
 blue links.  However, we started with a very rough and low-impact
 prototype, so a few tweaks would give us more definitive results.

 Here is the doc from which I am pasting from below:
 https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit?usp=sharing

 Questions/comments welcome!
 Best,

 J


 Browse Prototype Results


 

 Intro
 

 Process
 

 Results
 

 Blue links in general
 

 Category tags
 

 Conclusion and Next Steps
 

 Process
 

 Do people want to browse by categories?
 
 


 Intro

 As outlined in this doc
 ,
 the concept is a tag that allows readers to navigate WP via categories that
 are meaningful and populated in order of 'significance' (as determined by
 user input).  The hypothesis:

-

users will want to navigate by category if there are fewer, more
meaningful categories per page and those category pages showed the most
‘notable’ members first.

 Again, see the full doc
 

[WikimediaMobile] Reading web dashboard

[Jon Robson]

The reading web dashboard -
https://phabricator.wikimedia.org/dashboard/manage/125/ - has been
updated to have panels allowing you to easily find easy patches to
work on (in priority order) and code to review.

I'm using the code to review column as part of Gerrit cleanup day
since it seems to be a more reliable mechanism to identify what needs
reviewing.

Please add it to your bookmarks so we are all on the same page. I'm
going to be encouraging the Wikimedia reading web team to use this
frequently in our standups.

Happy coding reviewing/submitting! :)

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

[WikimediaMobile] Super-charging Mobile: An experiment with ServiceWorkers in MediaWiki

[Jon Robson]

Sam asked me to write up my recent adventures with ServiceWorkers and
making requests for MediaWiki content super super fast so all our
lovely users can access information quicker. Right now we're trying to
make the mobile site ridiculously fast by using new shiny standard web
technologies.

The biggest issue we have on the mobile site right now is we ship a
lot of content - HTML and images - since we ship those on desktop. On
desktop it's not really a problem from a performance perspective but
it may be an issue from a download perspective if you have some kind
of data limit on your broadband and you are addicted to Wikipedia.

The problem however is that on mobile, the connection speeds are not
quite up to desktops standard. To take an example the Barack Obama
article contains 102 image tags and 186KB of HTML resulting in about
1MB of HTML. If you're on your mobile phone just to look up his place
of birth (which is in the lead section) or to see the County results
of the 2004 U.S. Senate race in Illinois [1] that's a lot of
unnecessary stuff you are forced to load. You have to load all the
images and all the text! Owch!

Gilles D said a while back [2] "The Barack Obama article might be a
bit of an extreme example due to its length, but in that case the API
data needed for section 0's text + the list of sections is almost 30
times smaller than the data needed for all sections's text (5.9kb
gzipped versus 173.8kb gzipped)."

Somewhat related, some experimenting with webpagetest.org has
suggested that disabling images on this page has a serious impact on
first paint (which we believe is due to too many simultaneous
connections) [3,4]

Given that ServiceWorker is here (in Chrome first [5] but hopefully
others soon) I wrote a small proof of concept that lazy loads images
to expose myself to this promising technology.

For those interested I've documented my idea here:
https://en.m.wikipedia.org/wiki/User:Jdlrobson/lazyloader
but basically what is does is:
1) intercept network requests for HTML
2) Rewrites the src and srcset attributes to data-src and data-srcset attributes
3) Uses JavaScript to lazy load images when they appear in the screen.
4) Without JS the ServiceWorker doesn't run so the web remains unbroken
(But as Jake Archibald points out though there are downsides to this
approach [6].)

It doesn't quite work as a user script due to how scope works in
service workers but if we want to use these in production we can use a
header [7] to allow use of scope: '/' so if we wanted to do this in
production there's no real problem with that, but we will have to
ensure we can accurately measure that... [8]

A more radical next step for ServiceWorkers would be to intercept
network requests for HTML to use an API to serve just the lead section
[9]. This won't help first ever loads from our users, but it might be
enough to get going quickly.

If we want to target that first page load we need to really rethink a
lot of our parser architecture fun times.

Would this be a good topic to bring up in January at the dev summit?

[1] 
https://en.m.wikipedia.org/wiki/Barack_Obama#/media/File:2004_Illinois_Senate_results.svg
[2] https://phabricator.wikimedia.org/T97570
[3] https://phabricator.wikimedia.org/T110615
[4] https://phabricator.wikimedia.org/T105365#1477762
[5] https://jakearchibald.com/2014/using-serviceworker-today/
[6] https://twitter.com/jaffathecake/status/644168091216310273
[7] 
https://gerrit.wikimedia.org/r/#/c/219960/8/includes/resourceloader/ResourceLoader.php,unified
[8] https://phabricator.wikimedia.org/T112588
[9] https://phabricator.wikimedia.org/T100258

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

Re: [WikimediaMobile] Super-charging Mobile: An experiment with ServiceWorkers in MediaWiki

[Jon Robson]

On Wed, Sep 16, 2015 at 2:18 PM, Jon Robson <jrob...@wikimedia.org> wrote:
> Sam asked me to write up my recent adventures with ServiceWorkers and
> making requests for MediaWiki content super super fast so all our
> lovely users can access information quicker. Right now we're trying to
> make the mobile site ridiculously fast by using new shiny standard web
> technologies.
>
> The biggest issue we have on the mobile site right now is we ship a
> lot of content - HTML and images - since we ship those on desktop. On
> desktop it's not really a problem from a performance perspective but
> it may be an issue from a download perspective if you have some kind
> of data limit on your broadband and you are addicted to Wikipedia.
>
> The problem however is that on mobile, the connection speeds are not
> quite up to desktops standard. To take an example the Barack Obama
> article contains 102 image tags and 186KB of HTML resulting in about
> 1MB of HTML
Correction:
s/HTML/content

. If you're on your mobile phone just to look up his place
> of birth (which is in the lead section) or to see the County results
> of the 2004 U.S. Senate race in Illinois [1] that's a lot of
> unnecessary stuff you are forced to load. You have to load all the
> images and all the text! Owch!
>
> Gilles D said a while back [2] "The Barack Obama article might be a
> bit of an extreme example due to its length, but in that case the API
> data needed for section 0's text + the list of sections is almost 30
> times smaller than the data needed for all sections's text (5.9kb
> gzipped versus 173.8kb gzipped)."
>
> Somewhat related, some experimenting with webpagetest.org has
> suggested that disabling images on this page has a serious impact on
> first paint (which we believe is due to too many simultaneous
> connections) [3,4]
>
> Given that ServiceWorker is here (in Chrome first [5] but hopefully
> others soon) I wrote a small proof of concept that lazy loads images
> to expose myself to this promising technology.
>
> For those interested I've documented my idea here:
> https://en.m.wikipedia.org/wiki/User:Jdlrobson/lazyloader
> but basically what is does is:
> 1) intercept network requests for HTML
> 2) Rewrites the src and srcset attributes to data-src and data-srcset 
> attributes
> 3) Uses JavaScript to lazy load images when they appear in the screen.
> 4) Without JS the ServiceWorker doesn't run so the web remains unbroken
> (But as Jake Archibald points out though there are downsides to this
> approach [6].)
>
> It doesn't quite work as a user script due to how scope works in
> service workers but if we want to use these in production we can use a
> header [7] to allow use of scope: '/' so if we wanted to do this in
> production there's no real problem with that, but we will have to
> ensure we can accurately measure that... [8]
>
> A more radical next step for ServiceWorkers would be to intercept
> network requests for HTML to use an API to serve just the lead section
> [9]. This won't help first ever loads from our users, but it might be
> enough to get going quickly.
>
> If we want to target that first page load we need to really rethink a
> lot of our parser architecture fun times.
>
> Would this be a good topic to bring up in January at the dev summit?
>
> [1] 
> https://en.m.wikipedia.org/wiki/Barack_Obama#/media/File:2004_Illinois_Senate_results.svg
> [2] https://phabricator.wikimedia.org/T97570
> [3] https://phabricator.wikimedia.org/T110615
> [4] https://phabricator.wikimedia.org/T105365#1477762
> [5] https://jakearchibald.com/2014/using-serviceworker-today/
> [6] https://twitter.com/jaffathecake/status/644168091216310273
> [7] 
> https://gerrit.wikimedia.org/r/#/c/219960/8/includes/resourceloader/ResourceLoader.php,unified
> [8] https://phabricator.wikimedia.org/T112588
> [9] https://phabricator.wikimedia.org/T100258

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

[WikimediaMobile] QA: Holding our code to better standards.

[Jon Robson]

Dear Greg, and anyone else that is involved in deployment

This is a follow-up from Dan Duvall's talk today during the metrics
meeting about voting browser tests.

Background:
The reading web team this quarter with the help of Dan Duvall has made
huge strides in our QA infrastructure. The extensions Gather,
MobileFrontend and now the new extension QuickSurveys are all running
browser tests on a per commit basis. A selected set of MobileFrontend
@smoke tests (a selected subset of all he tests) are running in
15minutes on every commit and the entire set of Gather browser tests
is running in around 21minutes. It marginally slows down getting
patches deployed... but I think this is a good thing. The results
speak for themselves.

In the past month (August 4th-September 4th) only 3/33 builds failed
for MobileFrontend's daily smoke test build [1] (all 3 due to issues
with the Jenkins infrastructure). For the full set of tests only 10/33
failed in the Chrome daily build [3], 8 of which were due to tests
being flakey and needing improvement or issues with the Jenkin
infrastructure and the two others serious bugs [4,5] brought about by
work the performance team had been doing that we were able to fix
shortly after.

In Firefox [2] there were only 6 failures and only 2 of these were
serious bugs, again caused by things outside MobileFrontend [4,6]. One
of these was pretty serious - we had started loading JavaScript for
users with legacy browsers such as IE6. These were caught prior to the
daily builds when suddenly our MobileFrontend commits would not merge.

The future!:
Given this success:
1) I would like to see us run @integration tests on core, but I
understand given the number of bugs this might not be feasible so far.
2) We should run @integration tests prior to deployments to the
cluster via the train and communicate out when we have failures (and
make a decision to push broken code)
3) I'd like to see other extensions adopt browser test voting on their
extensions. Please feel free to reach out to me if you need help with
that. The more coverage across our extensions we have, the better.

We really have no excuse going forward to push broken code out to our
users and at the very least we need to be visible to each other when
we are deploying broken code. We have a responsibility to our users.

Thoughts? Reactions? Who's with me?!

[1] 
https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFrontend-SmokeTests-linux-chrome-sauce/
[2] 
https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox-sauce/
[3] 
https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/
[4] https://phabricator.wikimedia.org/T108045
[5] https://phabricator.wikimedia.org/T108191
[6] https://phabricator.wikimedia.org/T111233

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

Re: [WikimediaMobile] Removing of MobileFrontends Login page code - long live core login page

[Jon Robson]

Thanks for sending this update Florian!
Please do keep your eyes peeled on login pages over the next few days
across our projects as there is likely to be a few bugs we missed.
This is part of a drive to upstream changes from MobileFrontend and
ultimately repurpose the extension as a skin.

You can help test by visiting your favourite wiki and substituting the
url in the triangle brackets and reporting any oddities when viewed on
a mobile resolution:
/w/index.php?title=Special:UserLogin=beta=mobile

One of the benefits of this is things such as OAuth integration via
other extensions should just work (TM).

Thanks to Florian for pushing this forward and helping with a lot of the work.




On Thu, Sep 3, 2015 at 2:48 PM, Florian Schmidt
 wrote:
> Hello together,
>
> today I want to notice the members of this lthat that I've merged a (at
> least for me) very important change for MobileFrontend. By resolving task
> T74910, MobileFrontend now will use the mediawiki core login page instead of
> it's own implementation. That reduces code duplication and minimizes the
> cost of maintenance for MobileFrontend. On the other hand, extension
> developers now can customize the mobile and desktop login page on the same
> way.
>
> More information can be found in the task, the associated tasks and changes.
>
> Thanks to Jon for making this possible :)
>
> Best,
> Florian
>
> Gesendet mit meinem HTC
>
>
> ___
> 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] Global South = web, Global North = apps

[Jon Robson]

It's worth noting that the 2nd graphic given on
http://thenextweb.com/insider/2015/08/26/how-we-use-our-phones-is-changing-in-a-big-way-heres-the-data-that-proves-it/
tells us that most app usage is on facebook, entertainment(games). I
interpret this as the web is not as engaging as an app. Compare an
addictive RPG mobile game with a blog post / wikipedia article - of
course more time is going to be spent in the former. I don't think you
can compare the two and a lot of these reports bother me since they
seem to forget this.

When I was commuting to school back in the day I invested my time on
my Nokia 3210 on the game snake. When I got WAP I'd read BBC news sans
images. When data was cheaper/faster - blog posts/news articles.  Now
I have apps my options are endless.. Twitter.. Facebook... maps... ahh

My interpretation is people are choosing to invest their internet time
on things such as messaging and entertainment rather than web and that
we need to find ways to engage people in the Wikipedia rabbit
hole/experience, the platform not being relevant.


On Thu, Aug 27, 2015 at 8:26 AM, Tilman Bayer tba...@wikimedia.org wrote:
 .. well, that would be a bit too simplified, but there's food for
 thought in these two reports:

 http://qz.com/466089/the-fastest-growing-mobile-phone-markets-barely-use-apps/
 (In Asia and Africa, websites made up 90% and 96% of mobile
 impressions, respectively, in the second quarter.
 Their habits are a sharp contrast to the US, where apps accounted for
 91% of impressions. Globally, there’s a more even distribution, with
 apps making up 56% of mobile impressions and websites comprising the
 remainder.)

 http://thenextweb.com/insider/2015/08/26/how-we-use-our-phones-is-changing-in-a-big-way-heres-the-data-that-proves-it/
 (According to Yahoo’s data, the use of the browser on smartphones is
 quickly declining [in the US]. From 2013 to 2015, the company saw the
 usage time of the mobile browser drop by over 50 percent as they moved
 to native apps instead.)

 --
 Tilman Bayer
 Senior Analyst
 Wikimedia Foundation
 IRC (Freenode): HaeB

 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 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

Re: [WikimediaMobile] [Talk]: TXJS Jake Archibald on progressive enhancement on the web

[Jon Robson]

Great fun talk. Thanks for sharing. I too have experienced the horrors
of ill-functioning train bathrooms.

On Mon, Aug 17, 2015 at 4:51 AM, Joaquin Oltra Hernandez
jhernan...@wikimedia.org wrote:
 Very interesting and fun talk for those of you interested on progressive
 enhancement on the web, fast web experiences, service worker, etc.

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

 Good food for thought for the future of the experience, it features
 Wikipedia and Jake's offline wikipedia around minute 22, but it is
 recommended to watch the whole talk for context.

 Cheers.

___
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

[Jon Robson]

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 their phones toggle
 back and forth between devices, using whichever is closest at hand
 when opportunity strikes. Another is that screen sizes are getting
 bigger.
 Also has some bits about how book publishers react to this, which may
 of course be less applicable to us.

 [...]
 --
 Tilman Bayer
 Senior Analyst
 Wikimedia Foundation
 IRC (Freenode): HaeB

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




 --
 Corey Floyd
 Software Engineer
 Mobile Apps / iOS
 Wikimedia Foundation

 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 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

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

[Jon Robson]

I added some thoughts on the task. I do think it's something we
explore, even if on a small group of articles to measure the impact.


On Fri, Aug 14, 2015 at 3:27 PM, Magnus Manske
magnusman...@googlemail.com wrote:
 First example that loaded on random item:
 https://www.wikidata.org/wiki/Q6256189

 English:
 Manual description: American politician.
 Automatic description: US-American politician (*1968) ♂

 German:
 Manual description: None.
 Automatic description: Vereinigte Staaten Politiker (*1968) ♂ (yes, would
 need some work on the algorithm, but understandable)

 https://tools.wmflabs.org/autodesc/?q=Q6256189lang=demode=shortlinks=textredlinks=format=jsonfm


 On Fri, Aug 14, 2015 at 11:22 PM Magnus Manske magnusman...@googlemail.com
 wrote:

 On Fri, Aug 14, 2015 at 9:54 PM Gergo Tisza gti...@wikimedia.org wrote:


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

 IMHO the next step is auto-generating short descriptions from the item
 statements, which will be perfectly fine for the vast majority of cases.


 The Wikidata team is not a fan of that idea: T91981

 Yes, sadly. The argument not good enough is a fail IMHO, though. If it's
 bad, improve the algorithm and/or add statements. If it's still bad, THEN
 add a manual description.

 I think the worst possible description is the one that's missing.

 Back-of-the-envelope calculation:
 * We have ~45 million manual descriptions at the moment on Wikidata
 * We have ~18 million items
 * We have ~250 languages
 That means that, as of this moment, less than 1% of all possible
 descriptions are filled in. And the quality of these manual descriptions is
 everyone's best guess; I've seen plenty disambiguation page and category
 page, EVEN IS THAT IS NOT TRUE. Some crappy bot filled those in. No chance
 of quickly fixing this.

 So, 99% descriptions missing, with little chance of them getting filled in
 at all (think: small languages), and a rather dubious track record for the
 ones that are.

 It's like letting people drown in the Mediterranean because the tents to
 house them temporarily are not good enough. Frustrating, seriously.


 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 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] Measuring performance

[Jon Robson]

The reading team are currently focusing energy on speeding up the site
for all our users (https://phabricator.wikimedia.org/T98986 is the
tracking bug where this work can be followed)

Off the back of https://phabricator.wikimedia.org/T105361 I had a
quick chat with Ori to document how the performance team is currently
identifying problems with MediaWiki's code. I'm sharing here, so
anyone who is interested in helping us improve the time our users can
load our content can analyse our data, raise tasks, and submit
patches.

I'm hoping this will be useful for anyone who wants to get involved in
an effort to make our site faster for our users (this is not desktop
specific). If you have anything useful to add please do, after some
discussion or nods I'd love to share some best practices on
mediawiki.org

Tool 1) Use http://webpagetest.org (no credentials necessary)
* Use https://en.wikipedia.org/wiki/Facebook as an example wiki page
* Choose a region of the world and browser
* Select first view only since this is what we are currently
interested in (repeat view is when they load again - and it should be
quicker as it is from cache).
* Capture video can be turned off - I personally find the screenshots
more useful

To shout out some of the advanced settings, the more
interesting/useful features include:
*Chrome  capture dev tools timeline
* Setting speed 3G or 2G
* Script can be used to conditionally turn on things which are not yet
available to everyone e.g. VisualEditor

You can do a lot of this in your Chrome browser locally, but different
browsers may have different behaviours and are in a fixed location so
this does not get captured in this tool. The visual screenshots also
make it easier to see where things get blocked. With the timeline from
advanced tools you can match up white screens with blocking
scripts/styles

Tool 2) Add http://performance.wikimedia.org to your browser
bookmarks. Navigation timing section is probably the most interesting
right now. It points to https://grafana.wikimedia.org (no credentials
needed) which is powered by  http://graphite.wikimedia.org (Access
graphite with your wikitech credentials). This data is sourced from
our users, so is a good representation of how we are doing.

If a graph is missing you can create a new one from data in graphite
by clicking add row or editing an existing graph.

Clicking edit on
https://grafana.wikimedia.org/#/dashboard/db/navigation-timing?panelId=12fullscreenedit
you'll be able to understand where the data comes from on graphite
e.g. metrics/frontend/navtiming/totalPageLoadTime
Note for graphs median data is less sensitive to edge cases so best to
use this as a more realistic indicator.

Folders in graphite, are populated by scripts that live in:
https://github.com/wikimedia/operations-puppet/tree/production/modules/webperf/files

To create a graph, simply go to an existing workboard, save it under a
different name (this clones it) - don't worry you can't mess up and
delete existing workboards.

Tool 3) Speedcurve requires you to setup an account but it gives you
an opiniated view about things you care about and is nicely presented
so could be a good source of inspiration for your own grafana
dashboard.

To oversimplify what it does: each day it will access a page, store
result, allow you to see historic data.
Note the performance team has plans to setup infrastructure to automate this.

Tool 4) is one we are not using - http://sitespeed.io. We might want
to use it for performance regressions test.

In the grand scheme of things it would be great to get to a place
where Jenkins complains if you cause a regression in firstPaint time
but we are  a long way from that but let's work in that direction :-)

Let's live up to the Hawaiian word after which we are named!
Apologies if this is oversimplified, please take this as an
opportunity to share how you/your team/your company test page
performance. I see this mailing list as a good place to share these
sort of things!

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

Re: [WikimediaMobile] [QA] Qualifiers for selecting test articles for vagrant role

[Jon Robson]

On Wed, Jul 22, 2015 at 9:58 AM, Dan Duvall dduv...@wikimedia.org wrote:
 I like this idea for development and manual testing, but I'm not sure it's
 appropriate for automated testing.

Agreed. I was thinking more for manual testing.

 Generally in automated testing, each test case (unit test or integration
 scenario) should be able to set up or guarantee its preconditions whenever
 possible—and otherwise communicate its assumptions—which in the context of
 MediaWiki includes user accounts, user settings, or article content that the
 test case will manipulate or otherwise depend on. Putting this initial
 content in MW-Vagrant, which is orthogonal to MW test suites, creates the
 need for more coupling between test code and test environments and promotes
 more non-deterministic test behavior, something we've been trying very hard
 to reduce.[1][2]

 Also, for development content, we might want to figure out a better place
 for it than in the MW-Vagrant repo itself. Article dumps are likely to build
 up fast, and we risk bloating the project repo itself with big blobs.

 [1]
 https://www.mediawiki.org/wiki/Quality_Assurance/Browser_testing/Environment_abstraction_layer
 [2]
 https://doc.wikimedia.org/rubygems/mediawiki-selenium/index.html#User_Factory


 On Tue, Jul 21, 2015 at 10:25 AM, Jon Robson jdlrob...@gmail.com wrote:

 On 20 Jul 2015 5:56 pm, Greg Grossmeier g...@wikimedia.org wrote:

 Given the topic, let's keep the QA list in the loop on this so the
 MW-Vagrant maintainers can participate/see.

 Great :)


 Also, it looks like the original bug (reported in the MW-Vagrant
 project) covers this specific request from Reading, no? Essentially,

 let's see how far we can get with a general MW-Vagrant (WMF?) testing
 data import instead of a vertical specific reading-web test data set.
 If what the Reading team needs is way too much for this then we can
 break it out, otherwise it seems like a needless distinction.



 It does yup. I've already tagged the bug with it. I'm hoping by tackling
 this we can come up with a common solution. The way I imagine this working
 in future is we have various vagrant roles for stock data e.g.
 reading-web-stock-data, editing-web-stock-data, sad-web-stock-data
 There would also be non team specific stock data that might be a sub role
 of this, for example, the reading web team commonly has to setup the
 wikidata role and manually create articles in the wikidata instance and
 local instance that are tied to each other - this takes a ridiculous amount
 of time and is one I'm keen to automate, given that we are leaning more
 heavily on wikidata descriptions and other data in there.

 Rob - I've setup https://www.mediawiki.org/wiki/Reading/QA/Sample_articles
 as a place we can start to collect and think about these pages.


 Greg

 PS: https://wikitech.wikimedia.org/wiki/Labs_labs_labs

 quote name=Rob Moen date=2015-07-20 time=17:11:07 -0700
  Historically developers have had to setup their own content in
  mediawiki
  and in mediawiki-vagrant.  While this can be done with a simple import,
  getting everyone on the same page is apparently not as easy.  This is
  generally problematic as we would like to test code locally and
  remotely
  with the same content for various reasons.
 
  Slightly more frustrating, there are pages titled 0.4425590476103759
  on
  beta labs.  While trying to sign off on a feature, there is usually a
  struggle when trying to find an article with suitable content.  AFAIK
  this
  won't change beta labs but would provide a nice standard for our
  content on
  test wikis.
 
  We aim to better things by creating a vagrant role for importing a set
  of
  articles for testing purposes.  For more information please see related
  phabricator tasks [1] and [2].
 
  In hopes of making this a nice collection of articles that multiple
  teams
  would use, we would like to get input from our designers and devs on
  what
  types of articles should be in this import.  What qualities should
  these
  articles contain?
 
  1: https://phabricator.wikimedia.org/T104561
  2: https://phabricator.wikimedia.org/T62116
 
 
 
  --
  Rob Moen
  Wikimedia Foundation
  rm...@wikimedia.org

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


 --
 | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
 | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

 ___
 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




 --
 Dan Duvall
 Automation Engineer
 Wikimedia Foundation



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

Re: [WikimediaMobile] Extension Responsibility

[Jon Robson]

+1 to thus
On 21 Jul 2015 4:52 pm, Ryan Kaldari rkald...@wikimedia.org wrote:

 If the MultimediaViewer extension is transferred to Editing (i.e.
Multimedia), TimedMediaHandler should probably go with it, as they are both
mainly for presenting media within pages.

 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.

 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)?

I agree. They should come as a package (fwiw im a little confused why
viewing images and thus multimedia viewer doesn't come under reading).


 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

Re: [WikimediaMobile] [QA] Qualifiers for selecting test articles for vagrant role

[Jon Robson]

On 20 Jul 2015 5:56 pm, Greg Grossmeier g...@wikimedia.org wrote:

 Given the topic, let's keep the QA list in the loop on this so the
 MW-Vagrant maintainers can participate/see.

Great :)


 Also, it looks like the original bug (reported in the MW-Vagrant
 project) covers this specific request from Reading, no? Essentially,

let's see how far we can get with a general MW-Vagrant (WMF?) testing
 data import instead of a vertical specific reading-web test data set.
 If what the Reading team needs is way too much for this then we can
 break it out, otherwise it seems like a needless distinction.



It does yup. I've already tagged the bug with it. I'm hoping by tackling
this we can come up with a common solution. The way I imagine this working
in future is we have various vagrant roles for stock data e.g.
reading-web-stock-data, editing-web-stock-data, sad-web-stock-data
There would also be non team specific stock data that might be a sub role
of this, for example, the reading web team commonly has to setup the
wikidata role and manually create articles in the wikidata instance and
local instance that are tied to each other - this takes a ridiculous amount
of time and is one I'm keen to automate, given that we are leaning more
heavily on wikidata descriptions and other data in there.

Rob - I've setup https://www.mediawiki.org/wiki/Reading/QA/Sample_articles
as a place we can start to collect and think about these pages.


 Greg

 PS: https://wikitech.wikimedia.org/wiki/Labs_labs_labs

 quote name=Rob Moen date=2015-07-20 time=17:11:07 -0700
  Historically developers have had to setup their own content in mediawiki
  and in mediawiki-vagrant.  While this can be done with a simple import,
  getting everyone on the same page is apparently not as easy.  This is
  generally problematic as we would like to test code locally and remotely
  with the same content for various reasons.
 
  Slightly more frustrating, there are pages titled 0.4425590476103759 on
  beta labs.  While trying to sign off on a feature, there is usually a
  struggle when trying to find an article with suitable content.  AFAIK
 this
  won't change beta labs but would provide a nice standard for our content
 on
  test wikis.
 
  We aim to better things by creating a vagrant role for importing a set of
  articles for testing purposes.  For more information please see related
  phabricator tasks [1] and [2].
 
  In hopes of making this a nice collection of articles that multiple teams
  would use, we would like to get input from our designers and devs on what
  types of articles should be in this import.  What qualities should these
  articles contain?
 
  1: https://phabricator.wikimedia.org/T104561
  2: https://phabricator.wikimedia.org/T62116
 
 
 
  --
  Rob Moen
  Wikimedia Foundation
  rm...@wikimedia.org

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


 --
 | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
 | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

 ___
 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

[WikimediaMobile] barry -1s

[Jon Robson]

Just an FYI, a recent change in the selenium gem is causing the bot
Barry to report false positives for MobileFrontend patches. If you see
a -1 from him on your MobileFrontend patch, please read the log in the
mean time - if only 2 tests are failing it's highly likely your patch
is fine.

+2ers please consult the log prior to merging and overriding Barry's
-1 whilst the upstream bug [1] remains unfixed.

QAers the problem seems to be related to a recent change to the
selenium gem that requires a new user for new page creations. Would be
great to fix this...

[1] https://phabricator.wikimedia.org/T106343#1465574

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

Re: [WikimediaMobile] barry -1s

[Jon Robson]

I've managed to find a workaround for time being so Barry should be
+1ing / -1ing correctly again. Let's continue this conversation on the
phabricator task from now on :)

On Mon, Jul 20, 2015 at 11:58 AM, Jon Robson jrob...@wikimedia.org wrote:
 Just an FYI, a recent change in the selenium gem is causing the bot
 Barry to report false positives for MobileFrontend patches. If you see
 a -1 from him on your MobileFrontend patch, please read the log in the
 mean time - if only 2 tests are failing it's highly likely your patch
 is fine.

 +2ers please consult the log prior to merging and overriding Barry's
 -1 whilst the upstream bug [1] remains unfixed.

 QAers the problem seems to be related to a recent change to the
 selenium gem that requires a new user for new page creations. Would be
 great to fix this...

 [1] https://phabricator.wikimedia.org/T106343#1465574

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

Re: [WikimediaMobile] barry -1s

[Jon Robson]

Correction: I didn't find a workaround :)


On Mon, Jul 20, 2015 at 3:50 PM, Jon Robson jrob...@wikimedia.org wrote:
 I've managed to find a workaround for time being so Barry should be
 +1ing / -1ing correctly again. Let's continue this conversation on the
 phabricator task from now on :)

 On Mon, Jul 20, 2015 at 11:58 AM, Jon Robson jrob...@wikimedia.org wrote:
 Just an FYI, a recent change in the selenium gem is causing the bot
 Barry to report false positives for MobileFrontend patches. If you see
 a -1 from him on your MobileFrontend patch, please read the log in the
 mean time - if only 2 tests are failing it's highly likely your patch
 is fine.

 +2ers please consult the log prior to merging and overriding Barry's
 -1 whilst the upstream bug [1] remains unfixed.

 QAers the problem seems to be related to a recent change to the
 selenium gem that requires a new user for new page creations. Would be
 great to fix this...

 [1] https://phabricator.wikimedia.org/T106343#1465574

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

Re: [WikimediaMobile] Performance audit example

[Jon Robson]

cc wikitech - I think this is important for all of us to think about -
not just those working on mobile, since mobile still loads a lot of
what desktop does...

On Mon, Jul 6, 2015 at 8:40 AM, Joaquin Oltra Hernandez
jhernan...@wikimedia.org wrote:
 Hey,

 I saw the other day a performance audit that Paul Irish did for the mobile
 site of reddit.

 It is a great audit and a great example of how to do a performance review of
 a site, I encourage all to carefully read it as we are going to have to do
 something similar in the following sprints in order to enable us to do more
 concrete performance work on the mobile website.

 https://github.com/reddit/reddit-mobile/issues/247

 Awesome stuff.

 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 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

Re: [WikimediaMobile] [video club] RailsConf 2015 - Implementing a Strong Code Review Culture

[Jon Robson]

Thanks for sharing.  It's a good way to think about code review - as
taking the best from each other and learning together.

Particularly the bit about Is style important resonated with me
(The study... found... people who received a lot of style comments on
their code, reviewed those reviewers rather negatively) - I feel much
happier ever since we discussed and introduced style guides e.g. jscs
in many of our projects and it's a reminder when we notice pain in
code review, to think of ways to improve the way we work to minimise
these.

Personally, I will be more mindful about asking questions more than
demanding for changes, to help build a better culture in our team.




On Wed, Jul 1, 2015 at 9:57 PM, Stephen Niedzielski
sniedziel...@wikimedia.org wrote:
 What a great recommendation! Thanks for sharing!


 --stephen

 On Mon, Jun 29, 2015 at 10:51 AM, Toby Negrin tneg...@wikimedia.org wrote:

 Thanks for posting this Sam -- code review is one of the best parts of our
 engineering culture, I'll definitely watch this when I get a chance.

 -Toby

 On Mon, Jun 29, 2015 at 7:59 AM, Sam Smith samsm...@wikimedia.org wrote:

 Hey y'all,

 I watch a lot of talks in my downtime. I even post the ones I like to a
 Tumblr… sometimes [0]. I felt like sharing Derek Prior's Implementing a
 Strong Code Review Culture from RailsConf 2015 in particular because it's
 relevant to the conversations that the Reading Web team are having around
 process and quality. You can watch the talk on YouTube [1] and, if you're
 keen, you can read the paper that's referenced over at Microsoft Research
 [2].

 I particularly like the challenge of providing two paragraphs of context
 in a commit message – to introduce the problem and your solution – and
 trying to overcome negativity bias in written communication* by offering
 compliments whenever possible and asking, not telling, while providing
 critical feedback.

 I hope you enjoy the talk as much as I did.

 –Sam

 [0] http://sometalks.tumblr.com/
 [1] https://www.youtube.com/watch?v=PJjmw9TRB7s
 [2] http://research.microsoft.com/apps/pubs/default.aspx?id=180283

 * The speaker said research has shown but I didn't see a citation

 Notes (width added emphasis)

 Code review isn't for catching bugs
 Expectations, Outcomes, and Challenges of Modern Code Review
 Chief benefits of code review:

 Knowledge transfer
 Increased team awareness
 Finding alternative solutions

 Code review is the discipline of explaining your code to your peers
 Process is more important than the result
 Goes on to define code review as the discipline of discussing your code
 with your peers
 If we get better at code review, then we'll get better at communicating
 technically as a team

 Rules of Engagement

 As an author, provide context

 If content is king, then context is God
 In a pull request (patch set) the code is the content and the commit
 message is the context
 Provide sufficient context - bring the reviewer up to speed with what
 you've been doing in the past X hours
 Challenge: provide at least two paragraphs of context in your commit
 message
 This additional context lives on in the commit history whereas links to
 issue trackers might not

 As a reviewer, ask questions rather than making demands

 Research has shown that there's a negativity bias in written
 communication. Offer compliments whenever you can
 When you need to provide critical feedback, ask, don't tell, e.g.
 extract a service to reduce some of this duplication could be formulated
 as what do you think about extracting a service to reduce some of this
 duplication?

 Did you consider?, can you clarify?
 Why didn't you just... is framed negatively and includes the word just

 Use the Socratic method: asking and answering questions to stimulate
 critical thinking and to illuminate ideas

 Insist on high quality reviews, but agree to disagree

 Conflict is good. Conflict drives a higher standard of coding provided
 there's healthy debate
 Everyone has a minimum bar to entry for quality. Once that bar is met,
 then everything else is a trade-off
 Reasonable people disagree all the time
 Review what's important to you
 SRP (Single Responsibility Principle) (the S from SOLID)

 Naming
 Complexity
 Test Coverage
 ... (whatever else you're comfortable in giving feedback on)

 What about style?

 Style is important
 People who received style comments on their code perceived that review
 negatively
 Adopt a styleguide


 Benefits of a Strong Code Review Culture

 Better code
 Better developers through constant knowledge transfer
 Team ownership of code, which leads to fewer silos
 Healthy debate


 ___
 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] [Web] Outstanding branches

[Jon Robson]

Awww little walk down memory lane.

Photo uploads version 1, experiments with ESI for performance gains,
experiments with dynamically loaded sections, the first version of the
mobile editor and back in the frontend framework days when we were
considering Backbone JS around the conception of oojs ui was being
built.


Nah these are all old and can be removed or preserved in glass jars.

On Mon, Jul 6, 2015 at 8:47 AM, Sam Smith samsm...@wikimedia.org wrote:
 Hey y'all,

 There are a bunch of (stale?) branches open against MobileFrontend. Do we
 need to keep any of the following around?

 esisupport
 photouploads3
 sandbox/jdlrobson/ds
 sandbox/jgonera/backbone
 sandbox/jgonera/backbone-watchlist
 sandbox/jgonera/edit
 sandbox/jgonera/framework

 Ta,

 –Sam




 ___
 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 MediaViewer and the Seattle Japanese Garden

[Jon Robson]

https://phabricator.wikimedia.org/T101718
On 5 Jul 2015 11:51 pm, Pine W wiki.p...@gmail.com wrote:

 English Wikipedia's Seattle Japanese Garden article looks good in the
 Android app, and the MediaViewer-like slideshow feature works well for the
 gallery. However, I'm unable to scroll through the photos in Mobile Web
 like I csn using the Android app. Are there any plans to add the slideshow
 functionality to mobile web?

 Thanks!
 Pine

 ___
 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 web] Phabricating in Q1

[Jon Robson]

Hi Joaquin
I'm still not 100% sure how the query will work for us but I'm all for
trying this out.

A few caveats to be aware of:
* Anyone can edit the priority field. I don't know of any cases of
someone switching from some kind of priority to 'needs triage' ever
happens though so this shouldn't be a problem.
* Some tasks may get lost when they are not filed against an extension.
eg. Adding a card in a sprint but not with the associated extension
https://phabricator.wikimedia.org/maniphest/query/gdeZ0Re2Ekmh/#R
OR Tasks in reading web but not in the extension pages
https://phabricator.wikimedia.org/maniphest/query/BuWVMgcwb1kM/#R
(but I think we can train ourselves to avoid that)
I certainly do the former a lot, since I spend most of my time in the
sprint board. Setting up herald rules [1] for each sprint board seems
rather expensive and a pain but is one solution.

In terms of epics, on the reading web board, I'd love to see us use
though's more often and use only the 'must have', 'could have',
'should have' for those tasks. Any subtasks I'd love to file them in a
'Sub task' column on the basis that it makes the board less noisy and
keeps us focused. Any bugs should either be put in a sprint project or
left on the extension (we can triage them separately there using the
MobileFrontend workboard)

[1] https://www.mediawiki.org/wiki/Topic:Sh94hyx5vqslwf8n

On Tue, Jun 30, 2015 at 1:00 PM, Bahodir Mansurov
bmansu...@wikimedia.org wrote:
 It looks good to me. Thanks for the hard work, Joaquin.

 On Jun 30, 2015, at 2:56 PM, Joaquin Oltra Hernandez
 jhernan...@wikimedia.org wrote:

 Any feedback folks?

 I've been talking to the tech lead and we're considering adopting this and
 adapting as we go along for improvements we could make.

 Cheers

 On Mon, Jun 29, 2015 at 8:14 PM, Bahodir Mansurov bmansu...@wikimedia.org
 wrote:

 On Jun 29, 2015, at 8:34 AM, Joaquin Oltra Hernandez
 jhernan...@wikimedia.org wrote:


 I've mapped the proposed workflow: https://i.imgur.com/Wu7crcB.png


 TLDR ^




 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 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

Re: [WikimediaMobile] Freedom of Panorama banner campaign breaking mobile

[Jon Robson]

cc wikitech
(thanks!)

On Tue, Jun 30, 2015 at 3:05 PM, Jon Robson jrob...@wikimedia.org wrote:
 Thanks for the quick reply! :)
 Yes site notices should be disabled on mobile, but site notices on
 mobile are currently treated different to central notice banners
 (rightly or wrongly) so I can only assume that this is served via
 CentralNotice?

 The campaign has to be set specifically for mobile browsers however...
 without seeing the campaign in Central Notice I'm not able to provide
 much more help but options would be to not target mobile phones, or
 add some additional styles to make it work on mobile (it looks like it
 has a fixed width)


 On Tue, Jun 30, 2015 at 3:00 PM, Legoktm legoktm.wikipe...@gmail.com wrote:
 Hi,

 On 06/30/2015 02:49 PM, Jon Robson wrote:
 I noticed a banner on the mobile site that renders the site unusable:
 http://imgur.com/qVGz3mZ

 I'm not sure who is responsible for Freedom of Panorama in Europe in
 2015 but can someone disable this on mobile asap or make it work on
 mobile?

 The sitenotice been temporarily disabled for other reasons right now.

 Please also reach out to us on the mobile-l mailing list ahead of
 running these campaigns if you are unsure how to test campaigns, we're
 happy to help.

 In InitialiseSettings.php, I see:

 'wmgMFEnableSiteNotice' = array(
 'default' = false,
 ),

 So I assumed that it wouldn't show up on mobile at all. Is that no
 longer the case?

 -- 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] Freedom of Panorama banner campaign breaking mobile

[Jon Robson]

Thanks for the quick reply! :)
Yes site notices should be disabled on mobile, but site notices on
mobile are currently treated different to central notice banners
(rightly or wrongly) so I can only assume that this is served via
CentralNotice?

The campaign has to be set specifically for mobile browsers however...
without seeing the campaign in Central Notice I'm not able to provide
much more help but options would be to not target mobile phones, or
add some additional styles to make it work on mobile (it looks like it
has a fixed width)


On Tue, Jun 30, 2015 at 3:00 PM, Legoktm legoktm.wikipe...@gmail.com wrote:
 Hi,

 On 06/30/2015 02:49 PM, Jon Robson wrote:
 I noticed a banner on the mobile site that renders the site unusable:
 http://imgur.com/qVGz3mZ

 I'm not sure who is responsible for Freedom of Panorama in Europe in
 2015 but can someone disable this on mobile asap or make it work on
 mobile?

 The sitenotice been temporarily disabled for other reasons right now.

 Please also reach out to us on the mobile-l mailing list ahead of
 running these campaigns if you are unsure how to test campaigns, we're
 happy to help.

 In InitialiseSettings.php, I see:

 'wmgMFEnableSiteNotice' = array(
 'default' = false,
 ),

 So I assumed that it wouldn't show up on mobile at all. Is that no
 longer the case?

 -- 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] Freedom of Panorama banner campaign breaking mobile

[Jon Robson]

Of course... I should rephrase, that statement is probably unclear :-):

_If you need help with making your campaigns mobile friendly or are
unsure how to do so_... please do reach out to us on the mobile-l
mailing list ahead of running these campaigns

Basically I worry about 2 things when I see this kind of bug:
1) Those running the campaigns do not understand when/why they need to
make their banners work on mobile
or
2) They do not know what to do to make their banners work on mobile

I want to help with all  these things. :)


On Tue, Jun 30, 2015 at 3:37 PM, Federico Leva (Nemo)
nemow...@gmail.com wrote:
 Jon Robson, 30/06/2015 23:49:

 Please also reach out to us on the mobile-l mailing list ahead of
 running these campaigns


 That's not a reasonable request. Sitenotices run all the time.
 CentralNotices are scheduled on
 https://meta.wikimedia.org/wiki/CentralNotice/Calendar

 Nemo

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

[WikimediaMobile] Freedom of Panorama banner campaign breaking mobile

[Jon Robson]

I noticed a banner on the mobile site that renders the site unusable:
http://imgur.com/qVGz3mZ

I'm not sure who is responsible for Freedom of Panorama in Europe in
2015 but can someone disable this on mobile asap or make it work on
mobile?

Please also reach out to us on the mobile-l mailing list ahead of
running these campaigns if you are unsure how to test campaigns, we're
happy to help.

Jon

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

Re: [WikimediaMobile] [reading-wmf] Improving Privacy Policy on Mobile

[Jon Robson]

On Mon, Jun 29, 2015 at 10:31 AM, Jon Robson jrob...@wikimedia.org wrote:
 Hi Jacob
 I've cc'ed wikitech to get an update on bug
 https://phabricator.wikimedia.org/T483
 The last update here was in February 2015. I personally think this is
 one of our most urgent bugs to fix, but it's not clear who is
 responsible for this, and who has the expertise to help resolve it.

 The fundamental issue this privacy policy hits, is many our editors
 are also hitting - that there is no way to style wikitext content
 differently on a mobile screen. This has been a recurring problem for
 some time now. https://phabricator.wikimedia.org/T483

 The only way to make any progress here currently is the following:
 * Add the nomobile class to an element to hide it
 * Add a reset rule to MediaWiki:Common.css to reset problematic styles
 e.g. https://www.mediawiki.org/w/index.php?title=MediaWiki:Mobile.css

 I'm near positive these very same issues were discussed over a year go
 for the privacy policy on English Wikipedia and I think the conclusion
 was there was little that could be done in current form (if anyone can
 remember where that conversation happened).

 Note: For wikimediafoundation.org it might be acceptable to move all
 inline style rules into
 https://m.wikimediafoundation.org/w/index.php?title=MediaWiki:Mobile.css
 and use media queries to style content differently. Any capable web
 developer should be able to help you with that (I'm not sure who is
 building the privacy policy for you).

 Jon

 On Thu, Jun 25, 2015 at 2:33 PM, Adam Baso ab...@wikimedia.org wrote:
 Moving to mobile-l. Discuss.

 -Adam

 On Wed, Jun 24, 2015 at 10:05 PM, Jon Robson jrob...@wikimedia.org wrote:

 cc. reading-list. You'll get more feedback there :)
 Short reply: There are lots of bugs and larger problems here that need
 to be solved.


 On Wed, Jun 24, 2015 at 5:42 PM, Jacob Rogers jrog...@wikimedia.org
 wrote:
  Hi Jon,
 
  James A suggested you might be the right person to talk with about
  improving
  the readability of the WMF privacy policy on mobile devices. Currently,
  it's
  pretty difficult to look at. It starts with the massive language list,
  the
  disclaimer renders 1-2 words a line, and the blue boxes also render in
  hard
  to read lines as well as pushing the main section to scroll off the
  screen.
 
  If you are the right person, what I'm hoping we can do is make the
  language
  list into an expandable menu, get rid of the blue boxes on the sides if
  necessary, and possibly make the examples into an expandable view rather
  than have everything shown by default.
 
  If you're not the right person to this, could you forward me on to
  someone
  that might be able to help?
 
  Many thanks,
  Jacob
  --
 
  Jacob Rogers
  Legal Counsel
  Wikimedia Foundation
 
  NOTICE: This message might have confidential or legally privileged
  information in it. If you have received this message by accident, please
  delete it and let us know about the mistake. As an attorney for the
  Wikimedia Foundation, for legal/ethical reasons I cannot give legal
  advice
  to, or serve as a lawyer for, community members, volunteers, or staff
  members in their personal capacity. For more on what this means, please
  see
  our legal disclaimer.
 

 ___
 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


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

Re: [WikimediaMobile] [reading-wmf] Improving Privacy Policy on Mobile

[Jon Robson]

Hi Jacob
I've cc'ed wikitech to get an update on bug
https://phabricator.wikimedia.org/T483
The last update here was in February 2015. I personally think this is
one of our most urgent bugs to fix, but it's not clear who is
responsible for this, and who has the expertise to help resolve it.

The fundamental issue this privacy policy hits, is many our editors
are also hitting - that there is no way to style wikitext content
differently on a mobile screen. This has been a recurring problem for
some time now. https://phabricator.wikimedia.org/T483

The only way to make any progress here currently is the following:
* Add the nomobile class to an element to hide it
* Add a reset rule to MediaWiki:Common.css to reset problematic styles
e.g. https://www.mediawiki.org/w/index.php?title=MediaWiki:Mobile.css

I'm near positive these very same issues were discussed over a year go
for the privacy policy on English Wikipedia and I think the conclusion
was there was little that could be done in current form (if anyone can
remember where that conversation happened).

Note: For wikimediafoundation.org it might be acceptable to move all
inline style rules into
https://m.wikimediafoundation.org/w/index.php?title=MediaWiki:Mobile.css
and use media queries to style content differently. Any capable web
developer should be able to help you with that (I'm not sure who is
building the privacy policy for you).

Jon

On Thu, Jun 25, 2015 at 2:33 PM, Adam Baso ab...@wikimedia.org wrote:
 Moving to mobile-l. Discuss.

 -Adam

 On Wed, Jun 24, 2015 at 10:05 PM, Jon Robson jrob...@wikimedia.org wrote:

 cc. reading-list. You'll get more feedback there :)
 Short reply: There are lots of bugs and larger problems here that need
 to be solved.


 On Wed, Jun 24, 2015 at 5:42 PM, Jacob Rogers jrog...@wikimedia.org
 wrote:
  Hi Jon,
 
  James A suggested you might be the right person to talk with about
  improving
  the readability of the WMF privacy policy on mobile devices. Currently,
  it's
  pretty difficult to look at. It starts with the massive language list,
  the
  disclaimer renders 1-2 words a line, and the blue boxes also render in
  hard
  to read lines as well as pushing the main section to scroll off the
  screen.
 
  If you are the right person, what I'm hoping we can do is make the
  language
  list into an expandable menu, get rid of the blue boxes on the sides if
  necessary, and possibly make the examples into an expandable view rather
  than have everything shown by default.
 
  If you're not the right person to this, could you forward me on to
  someone
  that might be able to help?
 
  Many thanks,
  Jacob
  --
 
  Jacob Rogers
  Legal Counsel
  Wikimedia Foundation
 
  NOTICE: This message might have confidential or legally privileged
  information in it. If you have received this message by accident, please
  delete it and let us know about the mistake. As an attorney for the
  Wikimedia Foundation, for legal/ethical reasons I cannot give legal
  advice
  to, or serve as a lawyer for, community members, volunteers, or staff
  members in their personal capacity. For more on what this means, please
  see
  our legal disclaimer.
 

 ___
 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


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

Re: [WikimediaMobile] Skins Usage Data

[Jon Robson]

Can you clarify what active means?
Does that mean users visiting the page on a daily basis or does it relate
to editors or something else?

I'm keen to understand if some of these accounts are dormant and unused or
are frequently logged into.
On 29 Jun 2015 11:16 am, Adam Baso ab...@wikimedia.org wrote:

 Hi,

 I think it was Joaquin, Sam, and Bryan with whom I discussed relative
 skins usage on some popular skins, in the context of which skins Reading is
 on the hook for in the sense of full maintenance or high priority fixes
 (even if only coordinating) when issues arise. Here's that data, based on
 some queries Timo ran recently (thanks, Timo!).

 * en.wikipedia.org, users active since 2015-01-01, skin=cologneblue: 7k
 users.
 * en.wikipedia.org, users active since 2015-01-01, skin=monobook: 193k
 users.
 * en.wikipedia.org, users active since 2015-01-01: 3.1m users.

 * en.wikipedia.org, users active since 2015-03-01, skin=cologneblue: 6k
 users.
 * en.wikipedia.org, users active since 2015-03-01, skin=monobook: 179k
 users.
 * en.wikipedia.org, users active since 2015-03-01: 2.3m users.

 * commons.wikimedia.org, users active since 2015-03-01, skin=cologneblue:
 1k users.
 * commons.wikimedia.org, users active since 2015-03-01, skin=monobook:
 59k users.
 * commons.wikimedia.org, users active since 2015-03-01: 687k users.

 -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

Re: [WikimediaMobile] Skins Usage Data

[Jon Robson]

Timo - so to clarify these are users who have logged in since 2015-01-01 ?

It is possible to get a sense of whether they come back?
e.g. What if someone registered on 2015-01-01, switched to Monobook
and never came back - are they included?


On Mon, Jun 29, 2015 at 2:10 PM, Timo Tijhof ttij...@wikimedia.org wrote:
 I specified that in the original mail but I guess that got lost:

 Active here relates to the MediaWiki user_touched database field. This is
 set whenever the user logs in, as well as after various other actions that
 users can perform.



 — Timo

 On 29 Jun 2015, at 21:47, Adam Baso ab...@wikimedia.org wrote:

 Timo, would you please clarify on the definition of active?

 On Mon, Jun 29, 2015 at 11:30 AM, Jon Robson jdlrob...@gmail.com wrote:

 Can you clarify what active means?
 Does that mean users visiting the page on a daily basis or does it relate
 to editors or something else?

 I'm keen to understand if some of these accounts are dormant and unused or
 are frequently logged into.

 On 29 Jun 2015 11:16 am, Adam Baso ab...@wikimedia.org wrote:

 Hi,

 I think it was Joaquin, Sam, and Bryan with whom I discussed relative
 skins usage on some popular skins, in the context of which skins Reading is
 on the hook for in the sense of full maintenance or high priority fixes
 (even if only coordinating) when issues arise. Here's that data, based on
 some queries Timo ran recently (thanks, Timo!).

 * en.wikipedia.org, users active since 2015-01-01, skin=cologneblue: 7k
 users.
 * en.wikipedia.org, users active since 2015-01-01, skin=monobook: 193k
 users.
 * en.wikipedia.org, users active since 2015-01-01: 3.1m users.

 * en.wikipedia.org, users active since 2015-03-01, skin=cologneblue: 6k
 users.
 * en.wikipedia.org, users active since 2015-03-01, skin=monobook: 179k
 users.
 * en.wikipedia.org, users active since 2015-03-01: 2.3m users.

 * commons.wikimedia.org, users active since 2015-03-01, skin=cologneblue:
 1k users.
 * commons.wikimedia.org, users active since 2015-03-01, skin=monobook:
 59k users.
 * commons.wikimedia.org, users active since 2015-03-01: 687k users.

 -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




-- 
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] Barry the browser bot

[Jon Robson]

Some of you may have noticed a bot [1] providing reviews for the
Mobilefrontend and Gather extensions.

This is a grass routes experiment [2] to see if we can reduce
regressions by running browser tests against every single commit. It's
very crude, and we're going to have to maintain it but we see this as
a crude stop gap solution until we get gerrit-bot taking care of this
for us.

Obviously we want to do this for all extensions but we wanted to get
something good enough that is not scaleable to start exploring this.

So far it has caught various bugs for us and our browser test builds
are starting to finally becoming consistently green, a few beta labs
flakes aside [3].

Running tests on beta labs is still useful but now we can use it to
identify tests caused by other extensions. We were finding too often
our tests were failing due to us neglecting them.

In case others are interested in how this is working and want to set
one up themselves I've documented this here:
https://www.mediawiki.org/wiki/Reading/Setting_up_a_browser_test_bot

Please let me now if you have any questions and feel free to edit and
improve this page. If you want to jump into the code that's doing this
and know Python check out:
https://github.com/jdlrobson/Barry-the-Browser-Test-Bot
(Patches welcomed and apologies in advance for the code)

[1] 
https://gerrit.wikimedia.org/r/#/q/reviewer:jdlrobson%252Bbarry%2540gmail.com+status:open,n,z
[2] https://phabricator.wikimedia.org/T100293
[3] 
https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFrontend-SmokeTests-linux-chrome-sauce/

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

Re: [WikimediaMobile] [Update] Browser tests per patch

[Jon Robson]

I haven't been able to use verified yet - I think this is a permission
that Barry doesn't have.
I'm experimenting with him doing no score reviews right now rather
than +1s for good patches. The -1s are worth being as visible as
possible.

I'm hoping to send an update on the status quo but I've updated him so
that he can be run in a script:
https://github.com/jdlrobson/Barry-the-Browser-Test-Bot/blob/master/barrybot.py
If you want him to re-review code simply remove him from the list of
reviewers - the bot currently works out what it needs to review based
on which patches he is currently not a reviewer for.


On Wed, Jun 24, 2015 at 5:36 AM, florian.schmidt.wel...@t-online.de
florian.schmidt.wel...@t-online.de wrote:
 How does it affect jenkins if something/somebody sets verified to -1 for
 example? Would it block it from merging?



 Any -1/-2 in the verified column blocks submitting a change (even, if other
 reviewers add a +1 in verified), so if Barry wouldn't be happy, you can't
 merge. A workaround is to remove BarryBot as a reviewer (which would remove
 the vote, too, and allows jenkins to submit the change).



 Freundliche Grüße
 Florian Schmidt







 -Original-Nachricht-

 Betreff: Re: [WikimediaMobile] [Update] Browser tests per patch

 Datum: Wed, 24 Jun 2015 14:07:23 +0200

 Von: Joaquin Oltra Hernandez jhernan...@wikimedia.org

 An: florian.schmidt.wel...@t-online.de
 florian.schmidt.wel...@t-online.de







 Baha I agree with you, but instead of staying silent just commenting a
 BarryBot is happy! Browser tests passed without setting any +1 would be
 good to know they run.

 I also agree with Florian, if we could set Verified +1 or -1 that could be
 interesting. How does it affect jenkins if something/somebody sets verified
 to -1 for example? Would it block it from merging?

 On Wed, Jun 24, 2015 at 1:53 PM, florian.schmidt.wel...@t-online.de
 florian.schmidt.wel...@t-online.de wrote:

 Or, maybe, it should be possible for the bot to set the verified flag,
 instead of the code review (it's not a code review, so a minus one is
 misleading, too).



 Freundliche Grüße
 Florian Schmidt







 -Original-Nachricht-

 Betreff: Re: [WikimediaMobile] [Update] Browser tests per patch

 Datum: Wed, 24 Jun 2015 13:47:39 +0200

 Von: Bahodir Mansurov bmansu...@wikimedia.org

 An: Jon Robson jdlrob...@gmail.com







 May I suggest that Barry should not +1 patches. It gives a false
 impression that the code is alright even though the code may not be covered
 at all. Can we have it just -1 when there is a problem, and stay silent
 otherwise?


 On Jun 18, 2015, at 8:55 PM, Jon Robson jdlrob...@gmail.com wrote:

 So far I'm seeing some extremely positive results. The tests are
 running super fast (in phantomjs the smoke tests are taking less than
 3 minutes...).

 I've been manually running him whilst I do code review in parallel and
 he's already generated some interesting conversation on this patchset:
 https://gerrit.wikimedia.org/r/#/c/219249/

 If you want to pair and get this to be less hacky I'm more than happy!


 On Thu, Jun 18, 2015 at 5:41 PM, Dan Duvall dduv...@wikimedia.org wrote:

 Nice work, Jon.

 I've opened a task for defining a JJB builder/template and getting
 something
 like this into CI sooner rather than later.[1] I think your setup proves
 that a set of well-groomed MW-Selenium integration tests can be stable
 enough for this purpose, and we can start with an even smaller subset of
 core tests for a pre-merge build. Of course this isn't something that we
 planned to do 'now' now—sometimes 'then' suddenly becomes 'now' so
 'soon'—but we can start with an experiment on Gather or MobileFrontend
 tests, since their health has greatly improved, and see how it goes.

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

 On Thu, Jun 18, 2015 at 11:03 AM, Jon Robson jdlrob...@gmail.com wrote:


 So the script that actually runs the browser test is not in a generic
 useful form but it is:
 https://gist.github.com/jdlrobson/32b607f8009e897ee80c

 It uses the GerritCommandLine tool to do grabbing and reviewing
 https://github.com/jdlrobson/GerritCommandLine

 Ideally if we can use labs-tools-gerrit-to-redis for identifying
 patches and then pulling them down we wouldn't need the
 GerritCommandLine tool since the code to submit a review is pretty
 trivial and captured in this function:
 https://github.com/jdlrobson/GerritCommandLine/blob/master/gerrit.py#L277

 I've also put this in the task
 https://phabricator.wikimedia.org/T101069#1379462

 We'll probably want an instance per extension, to simplify having to
 worry about dependencies (we can just run a git update on all
 extensions after each checkout)

 On Thu, Jun 18, 2015 at 4:32 AM, Joaquin Oltra Hernandez
 jhernan...@wikimedia.org wrote:

 Awesome Jon! I'm so happy to finally see this developing :DD

 Loving the : `Browserbot happy!`

 I've noticed it can report either the name of the failing test or the
 full
 log. What

Re: [WikimediaMobile] [Update] Browser tests per patch

[Jon Robson]

So far I'm seeing some extremely positive results. The tests are
running super fast (in phantomjs the smoke tests are taking less than
3 minutes...).

I've been manually running him whilst I do code review in parallel and
he's already generated some interesting conversation on this patchset:
https://gerrit.wikimedia.org/r/#/c/219249/

If you want to pair and get this to be less hacky I'm more than happy!


On Thu, Jun 18, 2015 at 5:41 PM, Dan Duvall dduv...@wikimedia.org wrote:
 Nice work, Jon.

 I've opened a task for defining a JJB builder/template and getting something
 like this into CI sooner rather than later.[1] I think your setup proves
 that a set of well-groomed MW-Selenium integration tests can be stable
 enough for this purpose, and we can start with an even smaller subset of
 core tests for a pre-merge build. Of course this isn't something that we
 planned to do 'now' now—sometimes 'then' suddenly becomes 'now' so
 'soon'—but we can start with an experiment on Gather or MobileFrontend
 tests, since their health has greatly improved, and see how it goes.

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

 On Thu, Jun 18, 2015 at 11:03 AM, Jon Robson jdlrob...@gmail.com wrote:

 So the script that actually runs the browser test is not in a generic
 useful form but it is:
 https://gist.github.com/jdlrobson/32b607f8009e897ee80c

 It uses the GerritCommandLine tool to do grabbing and reviewing
 https://github.com/jdlrobson/GerritCommandLine

 Ideally if we can use labs-tools-gerrit-to-redis for identifying
 patches and then pulling them down we wouldn't need the
 GerritCommandLine tool since the code to submit a review is pretty
 trivial and captured in this function:
 https://github.com/jdlrobson/GerritCommandLine/blob/master/gerrit.py#L277

 I've also put this in the task
 https://phabricator.wikimedia.org/T101069#1379462

 We'll probably want an instance per extension, to simplify having to
 worry about dependencies (we can just run a git update on all
 extensions after each checkout)

 On Thu, Jun 18, 2015 at 4:32 AM, Joaquin Oltra Hernandez
 jhernan...@wikimedia.org wrote:
  Awesome Jon! I'm so happy to finally see this developing :DD
 
  Loving the : `Browserbot happy!`
 
  I've noticed it can report either the name of the failing test or the
  full
  log. What do you think if we show that, and a url with the pasted log
  somewhere publicly to not put too much noise on the comments but still
  be
  able to see it? Something like
  https://phabricator.wikimedia.org/paste/...
 
  +1 to where is the source.
  +1 to documenting how you've set it all up on wiki somewhere.
 
  I also think we need a catchy phrase for the -1s!
 
  Thanks for you work on this, we'll get more focused time for it soon.
 
  On Thu, Jun 18, 2015 at 11:33 AM, Sam Smith samsm...@wikimedia.org
  wrote:
 
  I agree with Florian everything that you've written should be in a
  public
  version control system.
 
  Second, I'd ask that you document your experiences so far in getting
  this
  set up and how it works so that other members of the vertical can help
  to
  maintain it moving forward.
 
  Third, great work!!1
 
  3
 
  –Sam
 
  On Thu, Jun 18, 2015 at 7:09 AM, florian.schmidt.wel...@t-online.de
  florian.schmidt.wel...@t-online.de wrote:
 
 
   It's currently working via a script that you can find here:
   /srv/mediawiki/extensions/Gather/tests/browser/Barry.sh
 
  It would be great to have the script in a public version control
  system
  (e.g. github?), especially for people, e.g. volunteers, who can't ssh
  to
  gather-browser-tests.eqiad.wmflabs[1]
 
  [1] all people, who're not members of
  https://wikitech.wikimedia.org/wiki/Nova_Resource:Mobile-smoketests
 
  Best,
  Florian
 
  -Original-Nachricht-
  Betreff: [WikimediaMobile] [Update] Browser tests per patch
  Datum: Thu, 18 Jun 2015 03:27:32 +0200
  Von: Jon Robson jrob...@wikimedia.org
  An: QA (software quality assurance) for Wikimedia projects.
  q...@lists.wikimedia.org, mobile-l mobile-l@lists.wikimedia.org
 
  Background: mobile wants to gain more confidence in its browser tests
  by running a subset of browser tests on a case by case basis [0].
 
  Good news: I've got a proof of concept running and Barry the browser
  test bot has given some legitimate helpful reviews to Gather [1].
 
  Even better news: It's proving itself valuable already [2].
  As you can see in the messages the bot has posted on [3] we have a
  couple of options on display option format for his reviews.
 
  So.. hopefully this short experience has sold you all already.
 
  This script is currently a manual job and needs a bit of tweaking
  before we can put it in a cron job/run it always - it needs to watch
  for new commits and then run a modification of the above script on a
  per case basis (if two versions of it run in parallel we have an
  issue).
 
  Definitely something we should push for next sprint!
 
  Long live Barry bot!
 
  Devs... (everyone else now of what

[WikimediaMobile] [Update] Browser tests per patch

[Jon Robson]

Background: mobile wants to gain more confidence in its browser tests
by running a subset of browser tests on a case by case basis [0].

Good news: I've got a proof of concept running and Barry the browser
test bot has given some legitimate helpful reviews to Gather [1].

Even better news: It's proving itself valuable already [2].
As you can see in the messages the bot has posted on [3] we have a
couple of options on display option format for his reviews.

So.. hopefully this short experience has sold you all already.

This script is currently a manual job and needs a bit of tweaking
before we can put it in a cron job/run it always - it needs to watch
for new commits and then run a modification of the above script on a
per case basis (if two versions of it run in parallel we have an
issue).

Definitely something we should push for next sprint!

Long live Barry bot!

Devs... (everyone else now of what follows is likely to be useful):
I got the labs instance up and running on:
http://gather-browser-tests.wmflabs.org/wiki/Main_Page

Most of you in readership team should be able to ssh
gather-browser-tests.eqiad.wmflabs
Let me know if you have no access.

It's currently working via a script that you can find here:
/srv/mediawiki/extensions/Gather/tests/browser/Barry.sh

[0] https://phabricator.wikimedia.org/T100293
[1] 
https://gerrit.wikimedia.org/r/#/q/reviewer:jdlrobson%252Bbarry%2540gmail.com+status:open,n,z
[2] https://gerrit.wikimedia.org/r/#/c/218731/

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

Re: [WikimediaMobile] [reading-wmf] [Web] Reverting commits

[Jon Robson]

Sounds great Sam. I think the tricky thing is defining what a regression
means. For instance, if you are fixing a regression and introducing a less
important regression then what? Master is technically undeployable in both
states.

Real world example:
Fixed to https://phabricator.wikimedia.org/T98498 caused
https://phabricator.wikimedia.org/T102215

Also is it a regression if the tests do not pick it up?
It seems that if we pick up a regression 2 weeks later, it's not almost the
less sensible/feasible to revert it but I'm not sure.

Just stuff to think about. I agree in principle we need to be more diligent
and extreme when regressions happen.


On Fri, Jun 12, 2015 at 8:38 AM, Adam Baso ab...@wikimedia.org wrote:

 Moving to mobile-l.

 On Friday, June 12, 2015, Sam Smith samsm...@wikimedia.org wrote:

 Hey web slingers,

 If there is a regression introduced by a patch, then please revert that
 patch as soon as you've identified it and let the team know via
 Phabricator, email, or both. Reverting the commit will often be cheaper to
 do than fixing the regression in a follow-on patch, but there'll
 undoubtedly be exceptions, which we'll deal with (and learn from) as a team.

 Fixing the regression in a follow-on patch means that:

- *master won't be deployable* until the patch has been reviewed,
tested, and merged, which should be communicated to the Release 
 Engineering
team
- reviewers might have to drop what they're working on in order to
get it reviewed
   - what if the original patch was lower priority?
   - we should be cognisant of the cost of context switching
- the commit history will be dirty

 *Master should always be depoyable.*

 –Sam


 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 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

Re: [WikimediaMobile] Task/bug naming conventions

[Jon Robson]

It might be easier to tag enhancements with enh: given that anyone can
create tasks and will not necessarily adhere to our standards. This would
at least solve confusion in whether things are bugs or enhancements.


On Mon, Jun 8, 2015 at 10:52 AM, Jon Katz jk...@wikimedia.org wrote:

 Good call, Gergo, and for calling out crap when you see it.  I know I am
 to blame on a lot of these (including the above example).  I think the
 language solution you described is pretty good.

 restating suggested rules for those who don't read prose:

- bugs--explain bad state in present tense (and desired state in
description if nec). Users screen goes blank
- enhancement--explain desired state as imperative Make it so users
can.. or Users should be able to...

 I think we could go a step further and call out bugs with the prefix
 bug: for more clarity.

 -J


 On Mon, Jun 8, 2015 at 10:38 AM, Jeff Hobson jhob...@wikimedia.org
 wrote:

 +1, also any bugs should have clear repro steps in description and wanted
 features should have a clear UX path/outlined steps.

 Thanks,

 Jeff Hobson
 On Jun 8, 2015 1:33 PM, Gergo Tisza gti...@wikimedia.org wrote:

 Hi all,

 I would like to recommend a naming convention that clearly
 differentiates between existing and wanted behavior. This is something that
 has been confusing for me for a while - bugs and tasks are both in the
 indicative so I often have trouble deciding whether a ticket describes a
 situation that exists but should not or one that does not exist but should.

 Random example from current sprint board: Anon users can access public
 view from main menu with the associated description being When anonymous
 and I click collections I am taken to the public view. Does this mean that
 anonymous users should not be able to access the public view but somehow
 they can, or is this the description of a wanted feature? I can figure it
 out by digging up context, of course, but that takes time; ideally, this
 should be clear from just the task title (which I might be seeing in a list
 or on a workboard).

 I think it would be clearer if the title of the task would always
 reflected the situation at the time of creating the task, and titles
 describing a wanted but not currently existing state were phrased as
 imperatives. So if anons can see the public view right now and that's a bug
 the title would say anons can access public view; if they cannot access
 it currently but that's a feature we want, the title would say anons
 should be able to access public view or make anons able to access public
 view.

 Thoughts?

 ___
 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




-- 
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] Reader's Watchstar habits

[Jon Robson]

MobileWebWatching schema has been active for some time now, I'm happy to
now reveal the results:

These are the number of clicks to the watchstar per funnel across the site
in stable:
page 61627
watchlist 1635
search 3105
nearby 279

and across all mobile modes:
page 63928
nearby 333
search 3357
watchlist 1890


As can be seen traffic to watchstars outside the current page is low. I
would suggest we therefore stop showing the watch star in search, nearby
results and Special:EditWatchlist and just focus on the funnel from the
page itself.

If interested I generated this data using:
select event_funnel, count(*) from MobileWebWatching_11761466 group by
event_funnel

It's also worth pointing out 8,025/12,964 ([1,2]) of the unique users using
the watch star had an edit count of 0.

[1] select count(distinct event_userId) from MobileWebWatching_11761466
where event_mobileMode = 'stable'
[2] select count(distinct event_userId) from MobileWebWatching_11761466
where event_mobileMode = 'stable'  and event_userEditCount = 0
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Analytics] killed a lot of queries on analytics-store

[Jon Robson]

Is there a task on Phabricator for this?


On Tue, May 12, 2015 at 4:32 PM, Dan Andreescu dandree...@wikimedia.org
wrote:

 Who's best to make updates?


 If you're just going to try to convert the queries to the old timeboxing
 style, then anyone that's familiar with that.  If you'd like to use the
 reportupdater timeboxing, probably one of us would have to at least show it
 to you.  Here's an example that's running for the visual editor data:


 https://github.com/wikimedia/analytics-limn-edit-data/blob/master/edit/config.yaml#L55

 The tradeoff is that working with us might be slower.

 ___
 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] Removing upload interface code from MobileFrontend

[Jon Robson]

A while back we disabled the mobile uploads interface in mobile. It's been
sitting in our codebase dormant so people can enable it via user js if
necessary but it's broken a few times and doesn't seem to be getting the
attention it needs.

Given there is now an editing team and from what I understand UploadWizard
is being refactored into oojs ui (which will lead to it being less bulky
and more mobile friendly) I'd like to suggest we abandon the code in
MobileFrontend and help support that effort. Note this effort is likely to
take a long long time, since that extension suffers from much technical
debt and makes use of jquery ui, which is not available on mobile, so to
set expectations we're not going to be in a state where we can enable this
on mobile (if we wanted to which again is highly questionable) any time
soon (think in units of a year rather than weeks/months).

The downside of this is any 3rd parties who are using this uploads code
(it's turned on by default) will lose this feature and there is no
available alternative.

I've written a patch to remove it [1] but I just wanted to post this here
to give people the chance to voice any concerns/disagree with this approach.

Note: We can always restore the code later on if necessary. I argue this
will be easier than fixing/maintaining the existing code. Someone could
also put it into a separate extension if they wanted to use it.

See also: https://phabricator.wikimedia.org/T97169
[1] https://gerrit.wikimedia.org/r/#/c/210084/
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Skynet is winning the battle on IRC

[Jon Robson]

+1 can we do that then? Seems like consensus. All bots to wikimedia-dev
I actually thing this also gains more as it gives more visibility to
changes to other devs and more visibility to core changes to mobile
devs.


On Fri, May 1, 2015 at 4:45 AM, Jeff Hobson jhob...@wikimedia.org wrote:
 +1 My main use for the bot messages so far has been to ping a reviewer on
 IRC before they get the gerrit email anyways.

 Thanks,

 Jeff Hobson

 On May 1, 2015 5:46 AM, Sam Smith samsm...@wikimedia.org wrote:

 I'm in favour of moving the bots to another channel (or back to
 #wikimedia-dev) too.

 –Sam

 On Thu, Apr 30, 2015 at 11:00 PM, Monte Hurd mh...@wikimedia.org wrote:

 +1

  On Apr 30, 2015, at 10:29 AM, Joaquin Oltra Hernandez
  jhernan...@wikimedia.org wrote:
 
  Hi!
 
  I've been feeling that the signal to noise ratio on #wikimedia-mobile
  since the addition of wikibugs and our new apps engineers (more grrrit-wm
  spam) is turning to be 0 (that is, no signal because of too much noise).
 
  It is really difficult to talk about anything when somebody else is
  working (and that is what we do, so...).
 
  I would like to propose moving the machines to a different channel,
  maybe a couple of them ( #wikimedia-mobile-web-bots 
  #wikimedia-mobile-apps-bots for example ) so that they continue to be 
  useful
  but in a different channel, and so that we can read again the chats with
  just the conversations.
 
  What do you think?
 
  Cheers.
  ___
  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




-- 
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

Re: [WikimediaMobile] Skynet is winning the battle on IRC

[Jon Robson]

Bug setup for this https://phabricator.wikimedia.org/T97798 to close
this thread.

On Fri, May 1, 2015 at 10:03 AM, Jon Robson jdlrob...@gmail.com wrote:
 +1 can we do that then? Seems like consensus. All bots to wikimedia-dev
 I actually thing this also gains more as it gives more visibility to
 changes to other devs and more visibility to core changes to mobile
 devs.


 On Fri, May 1, 2015 at 4:45 AM, Jeff Hobson jhob...@wikimedia.org wrote:
 +1 My main use for the bot messages so far has been to ping a reviewer on
 IRC before they get the gerrit email anyways.

 Thanks,

 Jeff Hobson

 On May 1, 2015 5:46 AM, Sam Smith samsm...@wikimedia.org wrote:

 I'm in favour of moving the bots to another channel (or back to
 #wikimedia-dev) too.

 –Sam

 On Thu, Apr 30, 2015 at 11:00 PM, Monte Hurd mh...@wikimedia.org wrote:

 +1

  On Apr 30, 2015, at 10:29 AM, Joaquin Oltra Hernandez
  jhernan...@wikimedia.org wrote:
 
  Hi!
 
  I've been feeling that the signal to noise ratio on #wikimedia-mobile
  since the addition of wikibugs and our new apps engineers (more grrrit-wm
  spam) is turning to be 0 (that is, no signal because of too much noise).
 
  It is really difficult to talk about anything when somebody else is
  working (and that is what we do, so...).
 
  I would like to propose moving the machines to a different channel,
  maybe a couple of them ( #wikimedia-mobile-web-bots 
  #wikimedia-mobile-apps-bots for example ) so that they continue to be 
  useful
  but in a different channel, and so that we can read again the chats with
  just the conversations.
 
  What do you think?
 
  Cheers.
  ___
  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




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



-- 
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

Re: [WikimediaMobile] API Phabricator cards, list threads, other

[Jon Robson]

master x ~/git/core/extensions/MobileFrontend $ ag 'FIXME:.*API'

javascripts/modules/editor/EditorApi.js

67: // FIXME: MediaWiki API, seriously?

73: // FIXME: API - missing is set to empty string (face palm)

183: // FIXME: AbuseFilter should have more consistent API responses


javascripts/modules/gallery/PhotoListApi.js

76: // FIXME: [API] have to request timestamp since api returns an object

116: // FIXME: [API] in an ideal world imageData would be a sorted array

124: // FIXME: API I hate you.


javascripts/modules/nearby/NearbyApi.js

144: // FIXME: API bug 48512

153: // FIXME: API returns object when array would make much sense


javascripts/modules/uploads/PhotoApi.js

253: // FIXME: API doesn't return this information on duplicate images...


resources/mobile.mediaViewer/ImageApi.js

54: // FIXME: API


resources/mobile.startup/PageApi.js

148: // FIXME: [API] the API sometimes returns an object and sometimes an array

211: // FIXME: API returns an object when a list makes much more sense

215: // FIXME: || [] wouldn't be needed if API was more consistent

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

[WikimediaMobile] Anonymous editing impact on mobile

[Jon Robson]

Anonymous editing was enabled on mobile web on 30th March 2015 to all users
(previous it was available in an experimental mode of the site). Now we
have almost a month's worth of data I thought it would be a good time to
check the impact... it's a little disappointing to be honest... but it
depends what we are optimising and consider the most important.

Quick summary:
* All edits up 154%
* Edits from logged in users down 152%
* Errors up 600%
* No noticeable impact on the new active editor graph [0] (editors that hit
5 edits in the month period)
* First edits by logged in users down 176% (although this could arguably be
said to  be compensated by anonymous edits)
* New account creation up by 192%

Follow ups
* Aaron H, it would be great if you could report back with some findings on
the quality of the edits during this same period.
* Can anyone provide theories why registrations jumped so much? This might
be related to the change or because of something else

Details on the queries I ran:
In March for a 26 day period before the change:
* 170,948 total edits [1]
* 169,845 non-anonymous edits [6]
** by 40,658 distinct users [7]
* 26,617 users completely their first ever edit [11]
* 9,528 errors [8]
* 219,012 accounts created on mobile [12]

For a similar 26 day period in April
* 263,986 total edits [2]
* 136,079 non-anonymous edits [4]
** by 26,823 distinct users [5]
* 15,109 users completely their first ever edit [10]
* 58,394 errors [9]
* 419,976 accounts created on mobile [13]

[0]  http://mobile-reportcard.wmflabs.org/
[1] select count(*) from MobileWebEditing_8599025 where event_action =
'success' and timestamp  2015030100 and timestamp  2015032700
[2] select count(*) from MobileWebEditing_8599025 where event_action =
'success' and timestamp  2015040100 and timestamp  2015042700
[3] https://phabricator.wikimedia.org/T97494
[4] select count(*) from MobileWebEditing_8599025 where event_action =
'success' and timestamp  2015040100 and timestamp  2015042700 and
event_username is NOT NULL
[5] select count(distinct event_username) from MobileWebEditing_8599025
where event_action = 'success' and timestamp  2015040100 and timestamp
 2015042700 and event_username is NOT NULL
[6] select count(*) from MobileWebEditing_8599025 where event_action =
'success' and timestamp  2015030100 and timestamp  2015032700 and
event_username is NOT NULL
[7] select count(distinct event_username) from MobileWebEditing_8599025
where event_action = 'success' and timestamp  2015030100 and timestamp
 2015032700 and event_username is NOT NULL
[8] select count(*) from MobileWebEditing_8599025 where event_action =
'error' and timestamp  2015030100 and timestamp  2015032700
[9] select count(*) from MobileWebEditing_8599025 where event_action =
'error' and timestamp  2015040100 and timestamp  2015042700
[10] select count(*) from MobileWebEditing_8599025 where event_action =
'success' and timestamp  2015040100 and timestamp  2015042700 and
event_userEditCount = 0
[11] select count(*) from MobileWebEditing_8599025 where event_action =
'success' and timestamp  2015030100 and timestamp  2015032700 and
event_userEditCount = 0
[12] select count(*) from ServerSideAccountCreation_5487345 where
event_displayMobile = 1 and timestamp  2015030100 and timestamp 
2015032700
[13] select count(*) from ServerSideAccountCreation_5487345 where
event_displayMobile = 1 and timestamp  2015040100 and timestamp 
2015042700
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Inconsistent editable key in the mobileview API

[Jon Robson]

+ anomie he might have ideas.
On 28 Apr 2015 5:32 pm, Dan Garry dga...@wikimedia.org wrote:

 I've noticed something a little strange about the editable key that the
 mobileview API returns. It seems it's either true or the empty string if
 the page is editable, or either false or absent from the response if the
 page is not editable. Whether it goes for the empty string/absent or
 true/false approach seems to vary from wiki to wiki.

 Examples (make sure you're not logged in on an admin account when you
 click these, because admin accounts can edit almost all pages):

- Foo @ testwiki

 https://test.wikipedia.org/w/api.php?action=mobileviewpage=Fooprop=editable
  -
response is the empty string on an editable page
- Protected page @ testwiki

 https://test.wikipedia.org/w/api.php?action=mobileviewpage=Protected_pageprop=editable
  -
response is absent on a protected page
- Manchester @ enwiki

 https://en.wikipedia.org/w/api.php?action=mobileviewpage=Manchesterprop=editable
  -
response is true on an editable page
- Barack Obama @ enwiki

 https://en.wikipedia.org/w/api.php?action=mobileviewpage=Barack%20Obamaprop=editable
  -
response is false on a protected page

 Does anyone know why this is? It'd be nice if this could be changed,
 because it's a pain to deal with things like this in a strongly-typed
 language like Java.

 Thanks,
 Dan

 --
 Dan Garry
 Product Manager, Search and Discovery
 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

Re: [WikimediaMobile] [Wikitech-l] Anonymous editing impact on mobile

[Jon Robson]

In the same period during March where 219,012 accounts were created on
mobile there were 228,723 accounts created on desktop [0]
In the same period during April where 419,976 accounts were created on
mobile there were 195,359 accounts created on desktop [1]
The ServerSideAccountCreation event logging schema captures all accounts
being created.
I really have no idea what drove these accounts being created to surpass
desktop. Could be mobile apps or mobile web - not sure. I'd encourage
anyone interested who knows SQL to get access to the database and run some
queries.

Any community members interested in helping out here? I'm very sad the
increase in errors wasn't picked up sooner... :-/

[0] select count(*) from ServerSideAccountCreation_5487345 where
event_displayMobile = 0 and timestamp  2015030100 and timestamp 
2015032700
[1] select count(*) from ServerSideAccountCreation_5487345 where
event_displayMobile = 0 and timestamp  2015040100 and timestamp 
2015042700

On Tue, Apr 28, 2015 at 8:13 PM, Risker risker...@gmail.com wrote:

 How can edits from logged-in users be down 152%?  The maximum decrease
 should be 100% - and that would mean no edits from logged-in users.  Same
 for first edits by logged-in users.

 I seriously wonder about the number of accounts created on mobile - are
 we really adding 0.05% of all of the current existing accounts every single
 month just on mobile?  Or does that include accounts that already existed
 on a WMF site?

 Risker/Anne



 On 28 April 2015 at 20:00, Jon Robson jrob...@wikimedia.org wrote:

  Anonymous editing was enabled on mobile web on 30th March 2015 to all
 users
  (previous it was available in an experimental mode of the site). Now we
  have almost a month's worth of data I thought it would be a good time to
  check the impact... it's a little disappointing to be honest... but it
  depends what we are optimising and consider the most important.
 
  Quick summary:
  * All edits up 154%
  * Edits from logged in users down 152%
  * Errors up 600%
  * No noticeable impact on the new active editor graph [0] (editors that
 hit
  5 edits in the month period)
  * First edits by logged in users down 176% (although this could arguably
 be
  said to  be compensated by anonymous edits)
  * New account creation up by 192%
 
  Follow ups
  * Aaron H, it would be great if you could report back with some findings
 on
  the quality of the edits during this same period.
  * Can anyone provide theories why registrations jumped so much? This
 might
  be related to the change or because of something else
 
  Details on the queries I ran:
  In March for a 26 day period before the change:
  * 170,948 total edits [1]
  * 169,845 non-anonymous edits [6]
  ** by 40,658 distinct users [7]
  * 26,617 users completely their first ever edit [11]
  * 9,528 errors [8]
  * 219,012 accounts created on mobile [12]
 
  For a similar 26 day period in April
  * 263,986 total edits [2]
  * 136,079 non-anonymous edits [4]
  ** by 26,823 distinct users [5]
  * 15,109 users completely their first ever edit [10]
  * 58,394 errors [9]
  * 419,976 accounts created on mobile [13]
 
  [0]  http://mobile-reportcard.wmflabs.org/
  [1] select count(*) from MobileWebEditing_8599025 where event_action =
  'success' and timestamp  2015030100 and timestamp  2015032700
  [2] select count(*) from MobileWebEditing_8599025 where event_action =
  'success' and timestamp  2015040100 and timestamp  2015042700
  [3] https://phabricator.wikimedia.org/T97494
  [4] select count(*) from MobileWebEditing_8599025 where event_action =
  'success' and timestamp  2015040100 and timestamp  2015042700
 and
  event_username is NOT NULL
  [5] select count(distinct event_username) from MobileWebEditing_8599025
  where event_action = 'success' and timestamp  2015040100 and
 timestamp
   2015042700 and event_username is NOT NULL
  [6] select count(*) from MobileWebEditing_8599025 where event_action =
  'success' and timestamp  2015030100 and timestamp  2015032700
 and
  event_username is NOT NULL
  [7] select count(distinct event_username) from MobileWebEditing_8599025
  where event_action = 'success' and timestamp  2015030100 and
 timestamp
   2015032700 and event_username is NOT NULL
  [8] select count(*) from MobileWebEditing_8599025 where event_action =
  'error' and timestamp  2015030100 and timestamp  2015032700
  [9] select count(*) from MobileWebEditing_8599025 where event_action =
  'error' and timestamp  2015040100 and timestamp  2015042700
  [10] select count(*) from MobileWebEditing_8599025 where event_action =
  'success' and timestamp  2015040100 and timestamp  2015042700
 and
  event_userEditCount = 0
  [11] select count(*) from MobileWebEditing_8599025 where event_action =
  'success' and timestamp  2015030100 and timestamp  2015032700
 and
  event_userEditCount = 0
  [12] select count(*) from

[WikimediaMobile] Gather Sprint Greatest Hits kicked off

[Jon Robson]

The team responsible for the Gather extension [0] kicked off their new
sprint yesterday. sprint `Greatest Hits` [1] after finishing sprint
`Forward` completing 33.5 story points (3.5 more than we planned).

As well as the usual polish, this sprint we will be doing lots of
thinking around the topics of flagging [2] and subscribing [3] for the
backend for the Gather feature. These will help steer our architecture
in the right direction. Please join the conversation.

In addition to this we are planning to make some changes to target
some of our users and encourage them to opt into our beta site to grow
our audience there for beta testing so we can reach more users than we
have historically been able to [2].

[0] https://www.mediawiki.org/wiki/Extension:Gather
[1] https://phabricator.wikimedia.org/tag/gather_sprint_greatest_hits/
[2] https://phabricator.wikimedia.org/T96282
[3] https://phabricator.wikimedia.org/T94243
[4] https://phabricator.wikimedia.org/T96286

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

Re: [WikimediaMobile] Collections is more popular than watchlist... so far ; -)

[Jon Robson]

The data doesn't seem to back that up.

3645 [1] unique users switched from the list view to feed view.
Since 1563 [2] clicked links in the list view and 1413 [1] clicking
links in the feed that suggests to me all those users are finding both
sides of the feature (someone could do more complicated queries to
verify if any users didn't discover it if they really want). I'm thus
not worried about this being a problem.

On top of this 1173 [4] unique users also switched back from the feed
view to the list view, so people are jumping between them and finding
use in both views it seems.

[1] select count(distinct event_username) from
MobileWebWatchlistClickTracking_10720361 where timestamp 
2015040100 and event_name = 'watchlist-a-z-switch';
[2] select count(distinct event_username) from
MobileWebWatchlistClickTracking_10720361 where timestamp 
2015040100 and event_name = 'watchlist-a-z-view';
[3] select count(distinct event_username) from
MobileWebWatchlistClickTracking_10720361 where timestamp 
2015040100 and event_name = 'watchlist-feed-view';
[4] select count(distinct event_username) from
MobileWebWatchlistClickTracking_10720361 where timestamp 
2015040100 and event_name = 'watchlist-feed-switch';

On Tue, Apr 21, 2015 at 10:54 PM, Federico Leva (Nemo)
nemow...@gmail.com wrote:
 Jon Robson, 15/04/2015 20:25:

 1117 known users have used the watchlist as a bookmarking tool for
 jumping to pages [1] whereas 1090 have used it to get to diffs, so
 there is thus mounting evidence to show there is a need for a reader
 version of the watchlist.


 ...or that users are confused and don't manage to get to the *actual*
 watchlist, which requires two clicks instead of one as usual.
 https://phabricator.wikimedia.org/T88270

 Nemo



-- 
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

Re: [WikimediaMobile] Mobile Newsletter?

[Jon Robson]

Transparency is a good thing and I think it's great that we're doing this.
The main problem in my opinion with comms is people complain about
missing announcements so we need to make sure such a newsletter gets
posted in all the channels .e.g. all the necessary village pumps...
mobile-l... mediawiki.org etc. etc..

On 15 Apr 2015 3:21 am, Moushira Elamrawy melamr...@wikimedia.org wrote:

 Sounds very reasonable.  A lot of changes happen in mobile, some are tangent 
 to desktop experiences, and pro-actively sharing those updates while in 
 planning or early stage, is a good practice.  In addition, keeping the 
 community updated and aware of what is happening in mobile, helps present the 
 bigger picture of why stuff are being built/modified, and helps get more 
 interest and suggestions or objections to what is being done.  Similarly for 
 new comers or readers community on mobile, understanding/learning more about 
 what is being done and what is coming next, could be a step forward towards 
 further engagement.   Makes sense?  If so, then the next question should be, 
 where would this live? VP, email newsletter, MW, etc..:)



 On Wed, Apr 15, 2015 at 11:58 AM, Amir E. Aharoni 
 amir.ahar...@mail.huji.ac.il wrote:

 Who is the target audience?

 If I understand correctly, the target audience for the weekly Tech news and 
 the monthly VE news is experienced active editing Wikipedians (I don't know 
 if it was ever designated, but I am making an educated guess of the actual 
 practice).

 But what is it for the mobile newsletter?
 Active editing Wikipedians don't do it much on mobile AFAIK, although it may 
 be defined as the newsletter's goal to increase this number.

 Wikipedia readers? There are many millions of those on mobile, but do they 
 read the newsletters? Certainly not on Village Pumps. Maybe it could be 
 delivered as a notification in the mobile web or in the apps?

 What else?

 New editors?
 Projects' JS and CSS maintainers?
 Gadget lovers?
 Twitter aficionados?
 Somebody else?

 This target audience should be defined before starting to publishing it.

 (N.B.: I didn't mention translation!!! :) )


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

 2015-04-15 12:41 GMT+03:00 Moushira Elamrawy melamr...@wikimedia.org:

 Hello Mobile fans :)

 Florian and and myself earlier created a draft for a Mobile Newsletter: 
 https://www.mediawiki.org/wiki/Mobile/Newsletter  -- it is currently a bit 
 outdated since it has been around for a while. Given the comments on phab 
 ticket.  https://phabricator.wikimedia.org/T93529, it is likely that this 
 needs to be streamlined with other newsletters, however, meanwhile the 
 coordination, please check and let me know:
 1. What would be the best approach to create it --agree on sections (new 
 features, testing, etc) where volunteers, PMs and CL add details to?
 2. This format is too detailed? Too brief?  What else do we need to see on 
 a newsletter for mobile?

 Obviously, it has to be made mobile friendly, as well. :)

 Comments, suggestions, thoughts?

 Many Thanks!
 Moushira

 ___
 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] Commons Reloaded

[Jon Robson]

There seems to be two things in conflict when dealing with anything upload
related.
1) uploading from a mobile phone is easy - that's a good thing
2) uploading useful content to commons is difficult for most people

Remember we made it super easy on web and we even limited who could see it
but people still uploaded selfies and copyvios. IMO the copyvios were an
attempt to be helpful.

So I ask you what's more important - 1 or 2? The only really the commons
app was a roaring success was the lack of its brand value as Amir says most
muggles don't know what it is so this serves as a filter for people that
use the app. Folding this functionality into a Wikipedia app would make you
hit problem 2 and all the moderation problems associated with it.
On 15 Apr 2015 4:54 am, Amir E. Aharoni amir.ahar...@mail.huji.ac.il
wrote:

  An Android Commons mobile app is probably the mandatory catalisator for
 hundreds of millions of people to participate to Commons. If you have only
 300 unique users a month with an official Commons app, IMO the only thing
 it tells you is: the app is not good enough!

 Muggles (no offense, honestly) don't know what Commons is.

 Either we need to educate the world that Commons is an awesome repository
 of media that can compete with Flickr and Instagram, or we need to bundle
 it with the Wikipedia app, which a lot of people do have.

 Facebook unbundled the Messenger app from the Facebook app, and millions
 hate it, but the same millions use it because they are hooked too strongly,
 and Facebook has a super-strong interest in hooking people to the Messenger
 (the most popular explanation is that they want to transition it to a
 payment processing app).

 We are not in the business of hooking people, but in the business of
 sharing knowledge. I'd actually love the first thing to happen - to
 popularize the Commons as a truly free competitor to Flickr, etc. But at
 this point in time this appears to be a much higher-hanging fruit than
 adding easy image sharing functionality to the Wikipedia app.

  But, these numbers are not a surprise to me. I have tested Commons *in
 real conditions* a year ago in Africa and the result was: almost impossible
 to upload picture to Commons (but no problem to upload the same pictures to
 Tumblr).

 I'm not sure that I understood: Is it because of server problems that we
 can fix, or because there is no app?

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


 ___
 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] Collections is more popular than watchlist... so far ; -)

[Jon Robson]

In beta on enwiki, there were 400 clicks on watchlist compared to 587
on collections since we launched it. It will be interesting how it
holds out, as I suspect it is new feature curiosity but it adds more
value to the idea that people use the watchlist for things other than
editing. It's even more popular than nearby at current time.

That said It still fails to compete with our most popular 'features'
home, random and settings.

Result of SQL Query [1]:
Home Random Nearby Watchlist Uploads Settings Profile Logout Login Collections
1308 851 500 400 0 1188 258 99 373 587

[1]SELECT
  sum(if(event_name = 'home', 1, 0)) as Home,
  sum(if(event_name = 'random', 1, 0)) as Random,
  sum(if(event_name = 'nearby', 1, 0)) as Nearby,
  sum(if(event_name = 'watchlist', 1, 0)) as Watchlist,
  sum(if(event_name = 'uploads', 1, 0)) as Uploads,
  sum(if(event_name = 'settings', 1, 0)) as Settings,
  sum(if(event_name = 'profile', 1, 0)) as Profile,
  sum(if(event_name = 'logout', 1, 0)) as Logout,
  sum(if(event_name = 'login', 1, 0)) as Login,
  sum(if(event_name = 'collections', 1, 0)) as Collections
FROM
  MobileWebMainMenuClickTracking_11568715
WHERE
event_mobileMode = 'beta'
and wiki = 'enwiki'

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

Re: [WikimediaMobile] [Web] Existing MF data series in Graphite/on gdash

[Jon Robson]

It would be good to get desktop and mobile in the same graph so we can
compare the two.
If I'm reading correctly this is all rather depressing - we are pretty
much the same as desktop despite being an environment which should
explicitly do better?


On Wed, Apr 15, 2015 at 7:02 AM, Sam Smith samsm...@wikimedia.org wrote:
 Hey y'all,

 As part of Mobile Web Sprint 45: Snakes on a Plane, the Readership team
 picked up a spike to investigate what data, if any, we were logging around
 site speed [0], given the existence of the mobile graphs over at WMF stats
 [1].

 After a little poking around I found that all of the NavigationTiming data
 that's collected by the eponymous extension is already separated out into
 desktop and mobile series in Graphite [2]. Any or all of these series can be
 graphed in gdash by defining our own graphs [3].

 With this in mind I've closed the tasks to design and implement our own
 event logging for site speed as invalid – don't you just love it when work's
 already done for you?

 Furthermore, if we find, some time in the future, that we want do refine the
 data that's being collected, then we have a clearly defined workflow: design
 the schema with the help of analytics, instrument the schema, and then
 define a graph. You'll note that only the first step requires collaboration
 (i.e. synchronisation) with another team. Woo!

 –Sam

 [0] https://phabricator.wikimedia.org/T95296
 [1] https://gdash.wikimedia.org/dashboards/frontend/
 [2] https://graphite.wikimedia.org – have a good look around frontend -
 navtiming
 [3]
 https://github.com/wikimedia/operations-puppet/tree/production/files/gdash/dashboards

 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 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

Re: [WikimediaMobile] Commons Reloaded

[Jon Robson]

On Wed, Apr 15, 2015 at 9:05 AM, Brian Gerstle bgers...@wikimedia.org wrote:
 Because Commons is afraid of the massive influx of selfies that will then
 have to be deleted, binding admin time and upsetting the uploader (who is,
 likely, not aware of the Commons policies).



 As was said before in this thread, some filtering at the source
 (smartphone) will have to be implemented to keep everyone sane (YMMV).


 I understand apps are focusing on readership at the moment, but are there
 any investigations figuring out how to scale contribution workflows and/or
 moderation?  I appreciate that this is a difficult problem, and I hope we're
 putting earnest effort into figuring out how to mitigate or solve it.

 I'm just troubled by some of the language used here, and elsewhere, which
 describes a fear of more users. I can't help but wonder how many companies
 or services would readily welcome a massive influx of users.  How will
 Wikipedia or Commons succeed if we're afraid growth?

+1. How we change this culture is the holy grail of Wikimedia's
future. Unless we change this, our project will die imo. I was really
saddened to see mobile uploads disappear from web - we had a lot of
spam yes but we also had people posting never before available photos
of diseases [1]. Our communities reaction seems to be to push back on
influxes of new edits which makes me feel we should be spending more
time on moderation tools - but so far I don't see any hint that this
will become a focus. This is a bigger problem than web and apps but so
far we see this more than most... I think this is something we'd have
to convince Lila is a good use of our time...

[1] http://wikimedia-l.wikimedia.narkive.com/AihmOoNe/mobile-image-upload


 Also, aren't we dealing with this to a certain extent with
 Wikidata/Wikigrok?


 On Wed, Apr 15, 2015 at 11:23 AM, Jon Robson jdlrob...@gmail.com wrote:

 There seems to be two things in conflict when dealing with anything upload
 related.
 1) uploading from a mobile phone is easy - that's a good thing
 2) uploading useful content to commons is difficult for most people

 Remember we made it super easy on web and we even limited who could see it
 but people still uploaded selfies and copyvios. IMO the copyvios were an
 attempt to be helpful.

 So I ask you what's more important - 1 or 2? The only really the commons
 app was a roaring success was the lack of its brand value as Amir says most
 muggles don't know what it is so this serves as a filter for people that
 use the app. Folding this functionality into a Wikipedia app would make you
 hit problem 2 and all the moderation problems associated with it.

 On 15 Apr 2015 4:54 am, Amir E. Aharoni amir.ahar...@mail.huji.ac.il
 wrote:

  An Android Commons mobile app is probably the mandatory catalisator for
  hundreds of millions of people to participate to Commons. If you have only
  300 unique users a month with an official Commons app, IMO the only thing 
  it
  tells you is: the app is not good enough!

 Muggles (no offense, honestly) don't know what Commons is.

 Either we need to educate the world that Commons is an awesome repository
 of media that can compete with Flickr and Instagram, or we need to bundle it
 with the Wikipedia app, which a lot of people do have.

 Facebook unbundled the Messenger app from the Facebook app, and millions
 hate it, but the same millions use it because they are hooked too strongly,
 and Facebook has a super-strong interest in hooking people to the Messenger
 (the most popular explanation is that they want to transition it to a
 payment processing app).

 We are not in the business of hooking people, but in the business of
 sharing knowledge. I'd actually love the first thing to happen - to
 popularize the Commons as a truly free competitor to Flickr, etc. But at
 this point in time this appears to be a much higher-hanging fruit than
 adding easy image sharing functionality to the Wikipedia app.

  But, these numbers are not a surprise to me. I have tested Commons *in
  real conditions* a year ago in Africa and the result was: almost 
  impossible
  to upload picture to Commons (but no problem to upload the same pictures 
  to
  Tumblr).

 I'm not sure that I understood: Is it because of server problems that we
 can fix, or because there is no app?

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


 ___
 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




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



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

Re: [WikimediaMobile] Commons Reloaded

[Jon Robson]

On 15 Apr 2015 11:34 am, Jan Ainali jan.ain...@wikimedia.se wrote:

 Perhaps some serious thought should go into guiding the user in what an
appropriate upload is rather than just make it super easy to upload the
very first time?
We tried. This is a very very hard problem. Explaining copyright law is
difficult and no matter how many barriers we put in place the instant
gratification of having contributed something valuable overruled that.

Didn't mobile web have around ~80% {{speedy}} and ~10% rightfully
successful deletion requests?

 If I understand correctly Wikigrok will not be direct editing on
Wikidata, but rather collecting data to see if it gets a good enough
validity that there is a coherence on the data before a bot does the edit.
How about trying something similar for images? Mobile upload to a staging
area, where other app users can tag it as useful/spam/out-of-scope and
perhaps even add categories to it before the actual upload to Commons
happen?


Yeh this is definitely an option but we don't have infrastructure for this
for images...
 Med vänliga hälsningar,
 Jan Ainali

 Verksamhetschef, Wikimedia Sverige
 0729 - 67 29 48


 Tänk dig en värld där varje människa har fri tillgång till mänsklighetens
samlade kunskap. Det är det vi gör.
 Bli medlem.


 2015-04-15 20:16 GMT+02:00 Jon Robson jdlrob...@gmail.com:

 On Wed, Apr 15, 2015 at 9:05 AM, Brian Gerstle bgers...@wikimedia.org
wrote:
  Because Commons is afraid of the massive influx of selfies that will
then
  have to be deleted, binding admin time and upsetting the uploader
(who is,
  likely, not aware of the Commons policies).
 
 
 
  As was said before in this thread, some filtering at the source
  (smartphone) will have to be implemented to keep everyone sane (YMMV).
 
 
  I understand apps are focusing on readership at the moment, but are
there
  any investigations figuring out how to scale contribution workflows
and/or
  moderation?  I appreciate that this is a difficult problem, and I hope
we're
  putting earnest effort into figuring out how to mitigate or solve it.
 
  I'm just troubled by some of the language used here, and elsewhere,
which
  describes a fear of more users. I can't help but wonder how many
companies
  or services would readily welcome a massive influx of users.  How
will
  Wikipedia or Commons succeed if we're afraid growth?

 +1. How we change this culture is the holy grail of Wikimedia's
 future. Unless we change this, our project will die imo. I was really
 saddened to see mobile uploads disappear from web - we had a lot of
 spam yes but we also had people posting never before available photos
 of diseases [1]. Our communities reaction seems to be to push back on
 influxes of new edits which makes me feel we should be spending more
 time on moderation tools - but so far I don't see any hint that this
 will become a focus. This is a bigger problem than web and apps but so
 far we see this more than most... I think this is something we'd have
 to convince Lila is a good use of our time...

 [1] http://wikimedia-l.wikimedia.narkive.com/AihmOoNe/mobile-image-upload

 
  Also, aren't we dealing with this to a certain extent with
  Wikidata/Wikigrok?
 
 
  On Wed, Apr 15, 2015 at 11:23 AM, Jon Robson jdlrob...@gmail.com
wrote:
 
  There seems to be two things in conflict when dealing with anything
upload
  related.
  1) uploading from a mobile phone is easy - that's a good thing
  2) uploading useful content to commons is difficult for most people
 
  Remember we made it super easy on web and we even limited who could
see it
  but people still uploaded selfies and copyvios. IMO the copyvios were
an
  attempt to be helpful.
 
  So I ask you what's more important - 1 or 2? The only really the
commons
  app was a roaring success was the lack of its brand value as Amir
says most
  muggles don't know what it is so this serves as a filter for people
that
  use the app. Folding this functionality into a Wikipedia app would
make you
  hit problem 2 and all the moderation problems associated with it.
 
  On 15 Apr 2015 4:54 am, Amir E. Aharoni 
amir.ahar...@mail.huji.ac.il
  wrote:
 
   An Android Commons mobile app is probably the mandatory
catalisator for
   hundreds of millions of people to participate to Commons. If you
have only
   300 unique users a month with an official Commons app, IMO the
only thing it
   tells you is: the app is not good enough!
 
  Muggles (no offense, honestly) don't know what Commons is.
 
  Either we need to educate the world that Commons is an awesome
repository
  of media that can compete with Flickr and Instagram, or we need to
bundle it
  with the Wikipedia app, which a lot of people do have.
 
  Facebook unbundled the Messenger app from the Facebook app, and
millions
  hate it, but the same millions use it because they are hooked too
strongly,
  and Facebook has a super-strong interest in hooking people to the
Messenger
  (the most popular explanation is that they want to transition

Re: [WikimediaMobile] Removing MobileFrontend from Gather dependencies

[Jon Robson]

Exactly.  Purely technical. From an outsiders perspective it makes
little difference - the feature will still look and behave the same..
To be honest the easiest thing to do would be to package our code and
put it in core, which is what VisualEditor did with oojs ui - but
having two libraries side by side would confuse people.

To be honest, I'm still not 100% sure it's the right thing to do. I
think a better strategy would be to slowly rewrite to oojsui until a
point we can simply depend on components in the oojs ui library that
is in core. It's just this is a long long long long long way away and
I'm desperate to find some sort of middle ground :(

tdlr:
Benefits:
* As Joaquin says - forces us to work out what code is MF is important
as a base library
* Forces us to coordinate releases between Wikigrok, MobileFrontend
and Gather as if extensions are on a different submodule version,
stuff can break dramatically.
* Having the code in a separate space makes it easier for us to
rewrite it in oojs ui
* Will save us time trying to explain to people that Gather is not
mobile only - which seems to be a common theme, from people seeing the
extension depends on MobileFrontend... which is simply not true. We've
wasted a lot of man hours arguing this point.

I'm talking to people about working to break VisualEditor mobile
experience out of MobileFrontend and move it into VisualEditor. I
think this will be very catalysing and help us in many ways, hopefully
with this dependency on the long term.


On Wed, Apr 15, 2015 at 11:29 AM, Joaquin Oltra Hernandez
jhernan...@wikimedia.org wrote:
 I think it is a technical detail Moiz and Dan, no decoupling from the
 wikipedia ecosystem.

 The idea (I think) is to make Gather more independent of Mobile frontend so
 that it can work seamlessly in Desktop when the time comes and in the way
 extract valuable common code into library/core so that other extensions can
 benefit from it too and MobileFrontend becomes leaner, cleaner and more
 focused.

 Gather will still be embedded on mediawiki as a extension and will use
 mobilefrontend and core as it needs.

 Correct me Jon If I'm wrong.

 On Wed, Apr 15, 2015 at 8:13 PM, Dan Garry dga...@wikimedia.org wrote:

 Given that your target audience for this project right now is Wikipedia
 readers, what are the advantages to those users of removing the
 MobileFrontend dependency from Gather? I'm unclear on this point right now.

 Dan

 On 13 April 2015 at 12:10, Jon Robson jrob...@wikimedia.org wrote:

 I did a quick spike [1] to work out how Gather could stop depending on
 MobileFrontend.

 Essentially problems come into 2 categories:

 1) Finding a place for Gather in the desktop skin and addressing
 styling issues in desktop skins (I am working on these and don't see
 any major blockers here).
 I think to fix this we simply need to provide Gather as a desktop beta
 feature.
 This is tracked here: https://phabricator.wikimedia.org/T95227 and I
 see no issues with doing this.

 2) frontend code standardisation
 The main problem with the hard dependency is that MobileFrontend uses
 a library that was built around the same time as OOJSUI. Migrating
 MobileFrontend to use OOJSUI is a big task and although has happened
 somewhat (the codebase now uses OOJS for class inheritance) it is by
 no means complete.

 Gather current depends on a variety of MobileFrontend modules which
 mainly include: API, overlay, user and user setting code, EventLogging
 schema code, notifications code. We also have a method
 mw.mobileFrontend.require and mw.mobileFrontend.define for defining
 modules. OOJS ui does this differently writing class names to the OO
 global variable object.

 ==The long term fix===
 ... is obviously to migrate all the code to OOJS UI which I believe
 would require the following steps:
 * https://phabricator.wikimedia.org/T88559 which as an end result will
 rewrite overlay code in oojs ui
 * Rewriting mw.util.notify as an oo js ui component and folding the
 mobile toast notification into it. -
 https://phabricator.wikimedia.org/T66565
 * Core should have a way to store user settings in localStorage rather
 than using $.cookie (similar to M.require( 'settings' ) ) - something
 akin to https://phabricator.wikimedia.org/T67008
 * EventLogging Schema.js should be ported to oojs ui and moved into core.
 * We only use user for the getEditCount function - it would be trivial
 to rewrite using mw.user

 == the short term fix==
 We could split out the frontend library MobileFrontend uses to allow
 us to share it between Gather and MobileFrontend.

 The way I see this working is to merge all the shared generic JS code
 into its own project just like oojs ui and slowly rewrite it there
 till it is pure oo js ui. This would take everything in the
 javascripts/common/ folder except application.js and bundle it into
 one file.

 We could include this as a submodule in both projects, both extensions
 conditionally adding a RL module for it when

Re: [WikimediaMobile] Commons Reloaded

[Jon Robson]

If we could store images in a safe temporary place - e.g. a draft
namespace or similar, I could imagine harnessing Wikigrok to crowd
source the moderation problem.

Is this image a copyright violation? link to explanation

Yes / No / No idea.


On Wed, Apr 15, 2015 at 1:05 PM, Brian Gerstle bgers...@wikimedia.org wrote:
 Not to silence ideas (which are great), but similar to the image cropping
 in gather thread, can we figure out what the extent of this problem is and
 decide whether or not we want to solve it?  Designing a solution for this
 should involve prototyping anyway, IMO. Put another way:

 What's the ROI for more moderation tools, specific for images?
 What features will be improved/enabled by these kinds of tools?
 If we decide we should build something, how should we scope it? What's the
 ideal solution?


 On Wed, Apr 15, 2015 at 3:59 PM, Jan Ainali jan.ain...@wikimedia.se wrote:

 2015-04-15 20:51 GMT+02:00 Jon Robson jdlrob...@gmail.com:


 On 15 Apr 2015 11:34 am, Jan Ainali jan.ain...@wikimedia.se wrote:
 
  Perhaps some serious thought should go into guiding the user in what an
  appropriate upload is rather than just make it super easy to upload the 
  very
  first time?
 We tried. This is a very very hard problem. Explaining copyright law is
 difficult and no matter how many barriers we put in place the instant
 gratification of having contributed something valuable overruled that.

 Did we ever try a non-skippable video? I guess if the comms team and legal
 team got involved such a video could be usable in a lot of other use cases
 too.

 /Jan Ainali

 

  Tänk dig en värld där varje människa har fri tillgång till
  mänsklighetens samlade kunskap. Det är det vi gör.
  Bli medlem.
 
 
  2015-04-15 20:16 GMT+02:00 Jon Robson jdlrob...@gmail.com:
 
  On Wed, Apr 15, 2015 at 9:05 AM, Brian Gerstle
  bgers...@wikimedia.org wrote:
   Because Commons is afraid of the massive influx of selfies that
   will then
   have to be deleted, binding admin time and upsetting the uploader
   (who is,
   likely, not aware of the Commons policies).
  
  
  
   As was said before in this thread, some filtering at the source
   (smartphone) will have to be implemented to keep everyone sane
   (YMMV).
  
  
   I understand apps are focusing on readership at the moment, but are
   there
   any investigations figuring out how to scale contribution workflows
   and/or
   moderation?  I appreciate that this is a difficult problem, and I
   hope we're
   putting earnest effort into figuring out how to mitigate or solve
   it.
  
   I'm just troubled by some of the language used here, and elsewhere,
   which
   describes a fear of more users. I can't help but wonder how many
   companies
   or services would readily welcome a massive influx of users.  How
   will
   Wikipedia or Commons succeed if we're afraid growth?
 
  +1. How we change this culture is the holy grail of Wikimedia's
  future. Unless we change this, our project will die imo. I was really
  saddened to see mobile uploads disappear from web - we had a lot of
  spam yes but we also had people posting never before available photos
  of diseases [1]. Our communities reaction seems to be to push back on
  influxes of new edits which makes me feel we should be spending more
  time on moderation tools - but so far I don't see any hint that this
  will become a focus. This is a bigger problem than web and apps but so
  far we see this more than most... I think this is something we'd have
  to convince Lila is a good use of our time...
 
  [1]
  http://wikimedia-l.wikimedia.narkive.com/AihmOoNe/mobile-image-upload
 
  
   Also, aren't we dealing with this to a certain extent with
   Wikidata/Wikigrok?
  
  
   On Wed, Apr 15, 2015 at 11:23 AM, Jon Robson jdlrob...@gmail.com
   wrote:
  
   There seems to be two things in conflict when dealing with anything
   upload
   related.
   1) uploading from a mobile phone is easy - that's a good thing
   2) uploading useful content to commons is difficult for most people
  
   Remember we made it super easy on web and we even limited who could
   see it
   but people still uploaded selfies and copyvios. IMO the copyvios
   were an
   attempt to be helpful.
  
   So I ask you what's more important - 1 or 2? The only really the
   commons
   app was a roaring success was the lack of its brand value as Amir
   says most
   muggles don't know what it is so this serves as a filter for
   people that
   use the app. Folding this functionality into a Wikipedia app would
   make you
   hit problem 2 and all the moderation problems associated with it.
  
   On 15 Apr 2015 4:54 am, Amir E. Aharoni
   amir.ahar...@mail.huji.ac.il
   wrote:
  
An Android Commons mobile app is probably the mandatory
catalisator for
hundreds of millions of people to participate to Commons. If you
have only
300 unique users a month with an official Commons app, IMO the
only thing it
tells you is: the app is not good

Re: [WikimediaMobile] Removing MobileFrontend from Gather dependencies

[Jon Robson]

No. Explicitly not. This would just be folding our code out into a sub
module. The point is to remove dependencies! :)

We dismantled it because code for templating when into core.
On 13 Apr 2015 12:41 pm, Bahodir Mansurov bmansu...@wikimedia.org wrote:

 Essentially, does that mean we want to re-create Mantle? If so, we should
 consider the reasons why we dismantled it.

  On Apr 13, 2015, at 3:10 PM, Jon Robson jrob...@wikimedia.org wrote:
 
  I did a quick spike [1] to work out how Gather could stop depending on
  MobileFrontend.
 
  Essentially problems come into 2 categories:
 
  1) Finding a place for Gather in the desktop skin and addressing
  styling issues in desktop skins (I am working on these and don't see
  any major blockers here).
  I think to fix this we simply need to provide Gather as a desktop beta
 feature.
  This is tracked here: https://phabricator.wikimedia.org/T95227 and I
  see no issues with doing this.
 
  2) frontend code standardisation
  The main problem with the hard dependency is that MobileFrontend uses
  a library that was built around the same time as OOJSUI. Migrating
  MobileFrontend to use OOJSUI is a big task and although has happened
  somewhat (the codebase now uses OOJS for class inheritance) it is by
  no means complete.
 
  Gather current depends on a variety of MobileFrontend modules which
  mainly include: API, overlay, user and user setting code, EventLogging
  schema code, notifications code. We also have a method
  mw.mobileFrontend.require and mw.mobileFrontend.define for defining
  modules. OOJS ui does this differently writing class names to the OO
  global variable object.
 
  ==The long term fix===
  ... is obviously to migrate all the code to OOJS UI which I believe
  would require the following steps:
  * https://phabricator.wikimedia.org/T88559 which as an end result will
  rewrite overlay code in oojs ui
  * Rewriting mw.util.notify as an oo js ui component and folding the
  mobile toast notification into it. -
  https://phabricator.wikimedia.org/T66565
  * Core should have a way to store user settings in localStorage rather
  than using $.cookie (similar to M.require( 'settings' ) ) - something
  akin to https://phabricator.wikimedia.org/T67008
  * EventLogging Schema.js should be ported to oojs ui and moved into core.
  * We only use user for the getEditCount function - it would be trivial
  to rewrite using mw.user
 
  == the short term fix==
  We could split out the frontend library MobileFrontend uses to allow
  us to share it between Gather and MobileFrontend.
 
  The way I see this working is to merge all the shared generic JS code
  into its own project just like oojs ui and slowly rewrite it there
  till it is pure oo js ui. This would take everything in the
  javascripts/common/ folder except application.js and bundle it into
  one file.
 
  We could include this as a submodule in both projects, both extensions
  conditionally adding a RL module for it when it does not exist.
 
  What do people think about taking this approach on the short term?
 
  [1] https://phabricator.wikimedia.org/T94100
 
  ___
  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] MobileFrontend and module deprecation

[Jon Robson]

I like this. This would mean changing what define returns but it's
clean and doesn't pollute how define currently works. Florian what do
you think?


On Wed, Apr 8, 2015 at 6:01 AM, Joaquin Oltra Hernandez
jhernan...@wikimedia.org wrote:
 What if the module exports just a function, or data? Or if it exports
 something that had a property named 'deprecated'? Polluting the exported
 data of a module doesn't seem the most reliable solution to me, so I'm not
 convinced about 3.

 IMO version 2 is as simple and effective as 3, but doesn't pollute the
 exported thingy from the module. The API is a bit ugly though, we could have
 some syntax sugar to make it prettier (to avoid asking yourself wtf is that
 boolean and that other string):

 M.define( 'new/location/Hola', Hola )
   .deprecate( 'old/location/HolaViejo' )

 I like my syntax sugar. Pretty expressive and clear. Let's call it option 4
 (option 2 + syntax sugar)


 On Tue, Apr 7, 2015 at 6:28 PM, Jon Robson jrob...@wikimedia.org wrote:

 For a bit of background, rather than pollute mw or a variable like
 mw.mobileFrontend we have functions require and define that exposure
 pieces of functionality. This is akin to var EventEmitter =
 OO.EventEmitter; for those familiar with oojs\
  M = mw.mobileFrontend;
  M.define( 'Foo', FooClass' );
  var FooClass = M.require( 'Foo', FooClass' );

 essentially what Florian is talking about is dealing when we do this:
  // left for backwards compatibility
  M.define( 'Foo', FooClass' );
  M.define( 'FooNew', FooClass' );
 and want to discourage use of 'Foo'

 so mw.deprecate currently allows you to deprecate a function but
 doesn't work in this case as the define function is not what has been
 deprecated.

 As I see it we have several options and I'm not sure what is the right
 place to do this.
 1) Make it possible to deprecate methods where parameters have changed
 (e.g. I see places where a parameter changes from a string to say a
 class but we do type checking and allow both)
 In this example we could use withParams as a parameter checker
  mw.deprecate( mw.mobileFrontend, 'define' ).withParams( function () {
  return args[0] === 'Foo' } )

 2) Just bake this into M.define itself as an explicit parameter (using
 Florian's method)

 3) Bake into M.require and handle deprecation like so:
  M.define( 'Foo', FooClass.extend( { deprecated: true } ) );
  var x = M.require( 'Foo' )
  Foo module name is deprecated.

 Personally I like the third example here since it is cleanest. 1
 however would be useful in various other locations.


 On Tue, Apr 7, 2015 at 9:07 AM, Florian Schmidt
 florian.schmidt.wel...@t-online.de wrote:
  Recently i noticed, that Jon wants to deprecate a module (he moved it to
  another location and changed the module name)[1], so I thought about a
  better way of deprecating a module (like core functions with a visible
  deprecation warning in the browser console, e.g.). So I uploaded a
  change
  for review[2] to extend module.js to support the definition of a
  deprecated
  module (it will log a warning every time someone access the module with
  M.require). Jon already posted, that he don’t know, if this is the right
  approach and suggested to extend core’s mw.log.deprecate. I’m not sure,
  if
  it’s a better approach to extend a core module in this way, so I hope
  for
  some feedback on this mailing list: What do you think? :)
 
 
 
  [1]
 
  https://gerrit.wikimedia.org/r/#/c/202053/3/javascripts/ContentOverlay.js
 
  [2] https://gerrit.wikimedia.org/r/#/c/202069/
 
 
 
  Best,
 
  Florian
 
 
  ___
  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] MobileFrontend and module deprecation

[Jon Robson]

For a bit of background, rather than pollute mw or a variable like
mw.mobileFrontend we have functions require and define that exposure
pieces of functionality. This is akin to var EventEmitter =
OO.EventEmitter; for those familiar with oojs\
 M = mw.mobileFrontend;
 M.define( 'Foo', FooClass' );
 var FooClass = M.require( 'Foo', FooClass' );

essentially what Florian is talking about is dealing when we do this:
 // left for backwards compatibility
 M.define( 'Foo', FooClass' );
 M.define( 'FooNew', FooClass' );
and want to discourage use of 'Foo'

so mw.deprecate currently allows you to deprecate a function but
doesn't work in this case as the define function is not what has been
deprecated.

As I see it we have several options and I'm not sure what is the right
place to do this.
1) Make it possible to deprecate methods where parameters have changed
(e.g. I see places where a parameter changes from a string to say a
class but we do type checking and allow both)
In this example we could use withParams as a parameter checker
 mw.deprecate( mw.mobileFrontend, 'define' ).withParams( function () { return 
 args[0] === 'Foo' } )

2) Just bake this into M.define itself as an explicit parameter (using
Florian's method)

3) Bake into M.require and handle deprecation like so:
 M.define( 'Foo', FooClass.extend( { deprecated: true } ) );
 var x = M.require( 'Foo' )
 Foo module name is deprecated.

Personally I like the third example here since it is cleanest. 1
however would be useful in various other locations.


On Tue, Apr 7, 2015 at 9:07 AM, Florian Schmidt
florian.schmidt.wel...@t-online.de wrote:
 Recently i noticed, that Jon wants to deprecate a module (he moved it to
 another location and changed the module name)[1], so I thought about a
 better way of deprecating a module (like core functions with a visible
 deprecation warning in the browser console, e.g.). So I uploaded a change
 for review[2] to extend module.js to support the definition of a deprecated
 module (it will log a warning every time someone access the module with
 M.require). Jon already posted, that he don’t know, if this is the right
 approach and suggested to extend core’s mw.log.deprecate. I’m not sure, if
 it’s a better approach to extend a core module in this way, so I hope for
 some feedback on this mailing list: What do you think? :)



 [1]
 https://gerrit.wikimedia.org/r/#/c/202053/3/javascripts/ContentOverlay.js

 [2] https://gerrit.wikimedia.org/r/#/c/202069/



 Best,

 Florian


 ___
 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] No one cares about browser tests [Re: [QA] MobileFrontend QA job]

[Jon Robson]

Personally, I think one team needs to get this completely right and
demonstrate the difference e.g. fewer bugs, iterating fast, quicker
code review time etc..

Talks can come off the back of that.
The majority of people I speak to seem to advocate a TDD approach but
I think we don't make life easy enough for them to do that and we lack
the discipline to do that. We need to work on both of those two.

I'm confident if we do a survey we'll identify and prioritise the pain
points. For me my top priority would be getting the infrastructure in
place on all our existing codebases in a consistent way that make
adding tests effortless and prevent code merging when it breaks those
tests but there may be more important things we need to sort out
first!


On Tue, Mar 31, 2015 at 1:16 AM, Sam Smith samsm...@wikimedia.org wrote:
 Dan, Jon,

 I got caught up in meetings yesterday – you'll see this email a lot during
 Q4 ;) – so I delayed sending this email, so forgive the repetitions of some
 of Dan's points/questions:

 Here are a few ways I can think of:

 include feedback on browser tests – or lack thereof – during code review

 make browser test failures even more visible than they currently are – but
 maybe not the success reports, eh?

 can these reports be made to point at a bunch of candidate changes that
 may have broken 'em?

 hold a browser-test-athon with the team and any volunteers at the
 {Lyon,Wikimania} hackathon

 make it trivial to run 'em, if it isn't already

 From what little experience I have of trying to establish team practices,
 I'd say that it's best to advocate for practice and demonstrate its
 value*, rather than criticise. I'd love to see you funnel your passion for
 browser testing into a talk or series of talks for the mobile team – the
 org, maybe? – or maybe you've got some recommended reading or talks you'd
 like to share that'll inspire.

 –Sam

 * If you'd like to hear my opinions about browser testing, then insert one
 beer and wind me up a little


 On Mon, Mar 30, 2015 at 8:47 PM, Dan Duvall dduv...@wikimedia.org wrote:

 https://phabricator.wikimedia.org/T94472

 On Mon, Mar 30, 2015 at 12:39 PM, Dan Duvall dduv...@wikimedia.org
 wrote:
  On Mon, Mar 30, 2015 at 10:30 AM, Jon Robson jdlrob...@gmail.com
  wrote:
  It really saddens me how very few engineers seem to care about browser
  tests. Our browser tests are failing all over the place. I just saw
  this bug
  [1] which has been sitting around for ages and denying us green tests
  in
  Echo one of our most important features.
 
  How can we change this anti-pattern?
 
  That's exactly what I'd like to explore with you and other like minds.
 
  Dan Duval, would it make sense to do a survey as you did with Vagrant
  to
  understand how our developers think of these? Such as who owns them...
  who
  is responsible for a test failing... who writes them... who doesn't
  understand them.. why they don't understand them etc...?
 
  Great idea! I suspect that the number of false positives in a given
  repo's test suite is inversely related to the number of developers on
  the team actually writing tests, and the affordance by managers to do
  so. If you're not regularly writing tests, you're probably not going
  to feel comfortable troubleshooting and refactoring someone else's. If
  TDD isn't factored in to your team's velocity, you may feel like the
  investment in writing tests (or learning to write them) isn't worth it
  or comes at the risk of missing deadlines.
 
  A survey could definitely help us to verify (or disprove) these
  relationships.
 
  Some other questions I can think of:
 
   - How valuable are unit tests to the health/quality of a software
  project?
   - How valuable are browser tests to the health/quality of a software
  project?
   - How much experience do you have with TDD?
   - Would you like more time to learn or practice TDD?
   - How often do you write tests when developing a new feature?
 - What kinds of test? (% of unit test vs. browser test)
   - How often do you write tests to verify a bugfix?
 - What kinds of test? (% of unit test vs. browser test)
   - When would you typically write a unit test? (before implementation,
  after implementation, when stuff breaks)
   - When would you typically write a browser test? (during conception,
  before implementation, after implementation, when stuff breaks)
   - What are the largest barriers to writing/running unit tests? (test
  framework, documentation/examples, execution time, CI, structure of my
  code, structure of code I depend on)
   - What are the largest barriers to writing/running browser tests?
  (test framework, documentation/examples, execution time, CI)
   - What are the largest barriers to debugging test failure? (test
  framework, confusing errors/stack traces, documentation/examples,
  debugging tools)
 
  I'll create a Phab task to track it. :)
 
  --
  Dan Duvall
  Automation Engineer
  Wikimedia Foundation



 --
 Dan Duvall

Re: [WikimediaMobile] iOS Engineering Review Meeting

[Jon Robson]

We have the developer pow wow for the mobile web team where we get together
every month and share tools, best practices, ideas. We've been doing this
since the end of January. (See Team session notes from Joaquin for notes
on the first one). I thoroughly recommend this practice it's been super
useful so far.


On Tue, Mar 31, 2015 at 3:00 PM, Tomasz Finc tf...@wikimedia.org wrote:

 This is a great practice.

 Gather  WikiGrok, are you already doing something similar to stay in sync?

 --tomasz

 On Fri, Mar 27, 2015 at 2:54 PM, Brian Gerstle bgers...@wikimedia.org
 wrote:
  Hey everyone,
 
  The iOS engineers had our regular review meeting today, where we
 discuss
  team practices and topics in the industry.  We've started taking minutes
 for
  future reference, and of course to keep in touch with all of you!
 
  The main page for the meeting is
 
  Wikimedia_Apps/Team/iOS/Engineering_Review
 
  and today's minutes can be found at
 
  Wikimedia_Apps/Team/iOS/Engineering_Review/March_27_2015.
 
  Topics discussed were: system dependencies being installed via the
 Makefile
  and our code review practices.
 
  Have a great weekend!
 
  Brian
 
  --
  EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
  IRC: bgerstle
 
  ___
  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] No one cares about browser tests [Re: [QA] MobileFrontend QA job]

[Jon Robson]

It really saddens me how very few engineers seem to care about browser
tests. Our browser tests are failing all over the place. I just saw this
bug [1] which has been sitting around for ages and denying us green tests
in Echo one of our most important features.

How can we change this anti-pattern?

Dan Duval, would it make sense to do a survey as you did with Vagrant to
understand how our developers think of these? Such as who owns them... who
is responsible for a test failing... who writes them... who doesn't
understand them.. why they don't understand them etc...?

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

On Thu, Mar 26, 2015 at 5:54 PM, Dan Duvall dduv...@wikimedia.org wrote:

 On Thu, Mar 26, 2015 at 3:38 PM, Jon Robson jdlrob...@gmail.com wrote:
  The lack of replies from any mobile team members seems to suggest I'm the
  only one watching this. In that case I'd rather we split up the big
  MobileFrontend job into various jobs based on certain features. How can
 we
  get more people caring about browser tests? Naming and shaming?

 We have a couple projects in the works that will hopefully help.[1][2]
 They don't go so far as to name and shame (we'll leave that up to you
 :), but they should promote more ownership over browser tests, better
 communication of failure, and analysis of failure over time and by
 test function (feature vs smoke vs regression).

 If many of these browser tests are serving as regression/smoke tests,
 it might be worthwhile to not only separate them out, but to remove
 some of the layers of abstraction to make tests more maintainable. I
 often try to think about tests in terms of a value-to-debt ratio (i.e.
 How likely is it that I'll have to fix or refactor this test down the
 road and is it worth it?) and, while I find quite a bit of value in
 Cucumber for the sake of acceptance(-esque) testing (it keeps me
 mindful of the UX),[3] it introduces quite a bit of debt in its layers
 of abstraction and indirection (it's always a red flag when you have
 to grep to find your test implementation). Even its creators believe
 the value of Cucumber lies in its collaboration/planning capacities,
 not in its function as a test runner.[4]

 It's entirely possible, as of the 1.0.0 release, to use MW-Selenium
 without Cucumber, so perhaps we could experiment with simple RSpec
 examples for these types of tests.

 Tooling aside, there are broader discussions that need to take place
 among those that are practicing or have practiced TDD/BDD in the
 organization and how we might (or might not) promote theses practices
 among others. I'll be trying to form such a group next quarter (will
 it be a 'guild'?, a 'league'?, no need for tough decisions just
 yet[5]), so let's maintain a dialogue on that front if you're
 interested and willing.

 [1] https://phabricator.wikimedia.org/T88706
 [2] https://phabricator.wikimedia.org/T89375
 [3]
 https://gerrit.wikimedia.org/r/#/c/196492/10/features/role_settings.feature
 [4]
 https://cukes.info/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool
 [5] https://www.youtube.com/watch?v=6KSiyaqnZYs

  Practically, the current big job [1] we have has far too many false
  positives and it is just noise to me. I was paying attention to the smoke
  tests [2] but I was told that was an upstream bug and haven't been
 watching
  it since. Any idea why that has been failing recently? Nothing has broken
  here...
 
  [1]
 
 https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/
  [2]
 
 https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFrontend-SmokeTests-linux-chrome-sauce/
 

 Have you tried to reproduce these failures by executing the tests
 locally, against either Beta or your local MW? I'll be in the office
 tomorrow if you want advice on how to best go about it.

 Dan

 --
 Dan Duvall
 Automation Engineer
 Wikimedia Foundation




-- 
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

Re: [WikimediaMobile] Gather - owner

[Jon Robson]

I've replied on the bug with some ideas... let's continue the conversation
there :-)
On 29 Mar 2015 2:50 pm, Amir E. Aharoni amir.ahar...@mail.huji.ac.il
wrote:

 Hi,

 I am translating Gather, and I feel very uncomfortable about the term
 Owner.

 It's challenging to translate, because in the languages I care about -
 Hebrew and Russian - it requires gender. Now gender can be added without
 too much technical effort, but there's still the general feeling of
 discomfort - owner is a strong word in the Wikimedia world, which should
 usually be avoided without a good reason.

 Was this word chosen intentionally, to show that lists are, in fact,
 owned, and privately curated?

 Maybe it could be changed to something like maintainer, curator or
 something else? Or simply User?

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

 ___
 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] [QA] MobileFrontend QA job

[Jon Robson]

The lack of replies from any mobile team members seems to suggest I'm the
only one watching this. In that case I'd rather we split up the big
MobileFrontend job into various jobs based on certain features. How can we
get more people caring about browser tests? Naming and shaming?

Practically, the current big job [1] we have has far too many false
positives and it is just noise to me. I was paying attention to the smoke
tests [2] but I was told that was an upstream bug and haven't been watching
it since. Any idea why that has been failing recently? Nothing has broken
here...

[1]
https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/
[2]
https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFrontend-SmokeTests-linux-chrome-sauce/

On Thu, Mar 26, 2015 at 3:32 AM, Antoine Musso hashar+...@free.fr wrote:

 On 25/03/15 21:37, Greg Grossmeier wrote:

 Does the mobile team have the browser test pass/failure announcements
 sent to it's IRC channel now?


 The MobileFrontend jobs send emails to chris and qa-alerts . It is
 configured JJB integration/config.git /jjb/browsertests.yaml via YAML
 aliases [1].

 The project 'MobileFrontend' has:

   recipients: *emails-qa

 One would need to define a new alias for Mobile at the top of the file.
 Maybe the mobile team as an alert


 IRC notifications are only send to #wikimedia-releng. It needs a bit more
 work to get make it customizable.


 [1] https://git.wikimedia.org/blob/integration%2Fconfig/
 0b91d99/jjb%2Fbrowsertests.yaml


 --
 Antoine Musso


 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 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

Re: [WikimediaMobile] Versioning MobileFrontend

[Jon Robson]

Looks like the awesome Katie made it so that works for me. As long as the
release schedule is owned by someone and documented on wiki I'm happy for
us to go ahead with this.
On 25 Mar 2015 3:49 am, Bahodir Mansurov bmansu...@wikimedia.org wrote:

 That’s great Florian. Jon, does that address your concern?

 On Mar 25, 2015, at 2:46 AM, florian.schmidt.wel...@t-online.de wrote:

 Hint:
 For a better wiki-formatted output (e.g. with {{git}} and {{phabricator}}
 we could reuse mediawiki-tools-release[1]. With the following command
 (e.g.) you can create a new changelog of MF:


 $ cd /var/www/.../extensions/MobileFrontend/
 $../../../mediawiki-release/make-deploy-notes/make-deploy-notes
 origin/wmf/1.25wmf20 origin/wmf/1.25wmf21
 (depends on where you cloned mediawiki-tools-release)


 The output would be: https://phabricator.wikimedia.org/P431
 (== Core == are the changes of MobileFrontend, the exceptions and errors
 are, because the script isn't designed to run from an extension dir, but we
 could ignore them, or rewrite the script).


 That's how we create the changelogs for wmf-versions[2].


 [1] https://github.com/wikimedia/mediawiki-tools-release
 [2] https://www.mediawiki.org/wiki/Category:WMF_Releases


 Freundliche Grüße / Kind regards
 Florian Schmidt




 -Original-Nachricht-
 Betreff: Re: [WikimediaMobile] Versioning MobileFrontend
 Datum: Tue, 24 Mar 2015 18:42:48 +0100
 Von: Sam Smith samsm...@wikimedia.org
 An: Jon Robson jrob...@wikimedia.org, mobile-l 
 mobile-l@lists.wikimedia.org







 Seems sensible, but knowing history I don't think it will be updated
 correctly.


 We're a different team now. Whaddya say we give it a try?


 I think the updating of VERSION.txt really needs to be automated. Can we
 have a script that can be run bumps the version number and  generates these
 logs by searching for keywords e.g. 'Bug:' 'Feature:' and generates this
 list. I think without this, this is a nice idea but will be disastrous.


 https://github.com/tj/git-extras/wiki/Commands#git-changelog is one of
 the many solutions to this turned up by a quick Google :)

 –Sam


 ___
 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: Versioning MobileFrontend

[Jon Robson]

My biggest concern is blocking merges on badly formatted release notes. I
see this all the time with core and the merge conflicts associated due to
multiple people editing the text file.

If we can have a tool that generates these consistently I'm all for release
notes. Versioning seems like a no brainer but I'd rather have no release
notes than bad release notes.


On Tue, Mar 24, 2015 at 10:42 AM, Sam Smith samsm...@wikimedia.org wrote:

 Seems sensible, but knowing history I don't think it will be updated
 correctly.


 We're a different team now. Whaddya say we give it a try?


 I think the updating of VERSION.txt really needs to be automated. Can we
 have a script that can be run bumps the version number and  generates these
 logs by searching for keywords e.g. 'Bug:' 'Feature:' and generates this
 list. I think without this, this is a nice idea but will be disastrous.


 https://github.com/tj/git-extras/wiki/Commands#git-changelog is one of
 the many solutions to this turned up by a quick Google :)

 –Sam

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

Re: [WikimediaMobile] Restoring anon editing on all mobile sites by March

[Jon Robson]

Some questions
1) How would anonymous users get to their 'talk pages' on mobile? (note
talk pages are /enabled/ just not surfaced in the UI) and do we have any
evidence anons read them?
2) The majority of MobileFrontend developers are wrapping up projects in
the last two weeks (Extension:Gather and Extension:Wikigrok). To meet this
March release date who will be responsible for enabling this feature and
the work that involves?
3) What does success/failure look like? i.e. under what circumstances could
the feature be disabled. It's good to make this clear so there is no
confusion about when to do this.
4) To be clear, it seems from the feedback you gave me on the meta wiki
proposal talk page that there are no plans at present to enrich the feature
in any way. This is simply a case of turning the feature on. Can you
confirm this? New feature development = time for code review, so I want to
be sure this is not going to become a strain on the development team I am
part of.

Please be sure to enable this feature correctly. With Italian Wikipedia a
cache flush was required and this shouldn't be needed and will not be
allowed on English Wikipedia and other larger projects.

Note: The talk page did not help upload errors in past. Only logged in
users could upload and they had easy access to their talk pages via Echo
notifications.
On 20 Mar 2015 1:01 am, Federico Leva (Nemo) nemow...@gmail.com wrote:

 See https://phabricator.wikimedia.org/T93210 for details.

 Quoting from the discussion: «As of today, there is broad consensus in
 support of the proposal, as discussed by an ample spectrum of users active
 in multiple wikis. Several users stressed that: talk page access is
 crucial, to ensure communication with mobile users; errors of the past,
 like the mobile uploads campaign, must not be repeated; local and global
 effects in terms of (un)productive contributions will be under constant
 monitoring and re-evaluation per the usual processes.»

 Nemo

 ___
 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] Readability of the first sentence on Wikipedia articles

[Jon Robson]

On 7 Mar 2015 09:13, Magnus Manske magnusman...@googlemail.com wrote:

 May I use this as a shameless plug for my automatic description API:
 http://magnusmanske.de/wordpress/?p=265

 It scores a 9 in the Hemmingway app for Nietzsche, as opposed to the 22
for the English Wikipedia initial paragraph:

Thanks Magnus
Was hoping this would be the case and you would confirm that :-)

I personally would be very keen to get this into Wikidata via a bot. What
are the blockers for doing that? What has the discussion been around that
so far?


https://tools.wmflabs.org/autodesc/?q=Q9358lang=mode=longlinks=textredlinks=format=htmlget_infobox=yesinfobox_template=


 On Sat, Mar 7, 2015 at 8:38 AM Federico Leva (Nemo) nemow...@gmail.com
wrote:

 What's the scientific background of hemingwayapp? I don't see anything
 on their website. There is no one-size-fits-all readability algo for
 English, as far as I know.

 Nemo

 ___
 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] FYI: Testing Wikidata infoboxes on beta labs

[Jon Robson]

You can now test them using this url:
http://en.m.wikipedia.beta.wmflabs.org/wiki/Albert_Einstein?mobileaction=alpha

The edits save to wikidata beta labs instance. Feel free to test.

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

Re: [WikimediaMobile] Fwd: [Wikidata-l] descriptions in mobile app

[Jon Robson]

Bad wikidata descriptions will hopefully lead to a bunch of edits from
people like myself who can't stand badly worded sentences. Do it. Create a
new editing path! :) it's easier to correct something in my opinion then to
write something new from scratch.
On 9 Feb 2015 13:52, Dmitry Brant dbr...@wikimedia.org wrote:

 Sure, I won't deny that it would still need a lot of work, but I still see
 it as a logical next step.


 On Mon, Feb 9, 2015 at 11:41 AM, Max Semenik maxsem.w...@gmail.com
 wrote:

 Eh, please don't - have you tried it for languages other than English?
 09 февр. 2015 г. 5:55 пользователь Dmitry Brant dbr...@wikimedia.org
 написал:

 Awesome! I would love to see the output of AutoDesc be returned by the
 API, when a manual description is not available.
 I would also be a strong proponent of fully auto-generated descriptions
 for all articles. (The data is right there!)


 On Mon, Feb 9, 2015 at 5:44 AM, Erik Moeller e...@wikimedia.org wrote:

 See https://tools.wmflabs.org/autodesc for the new API described in
 the post. Interesting at least as a fallback to human-written
 descriptions...

 -- Forwarded message --
 From: Magnus Manske magnusman...@googlemail.com
 Date: Mon, Feb 9, 2015 at 2:41 AM
 Subject: Re: [Wikidata-l] descriptions in mobile app
 To: Discussion list for the Wikidata project. 
 wikidat...@lists.wikimedia.org


 Manual descriptions are, in the vast majority of cases, a waste of
 volunteer time. Alternative:
 http://magnusmanske.de/wordpress/?p=265


 On Sun Feb 08 2015 at 17:37:42 Gerard Meijssen 
 gerard.meijs...@gmail.com wrote:

 Hoi,
 How does that help ? The point is exactly that there is no point to
 descriptions. Why iterate on a dog it will still be a mutt.
 Thanks,
 GerardM

 On 8 February 2015 at 14:07, Amir E. Aharoni 
 amir.ahar...@mail.huji.ac.il wrote:

 I'd rather see it not as something terribly disappointing, but as an
 opportunity to find a way to fill item descriptions more efficiently.

 Basically, to find some cycles to resolve
 https://phabricator.wikimedia.org/T64695
 בתאריך 8 בפבר 2015 10:33, ‏Gerard Meijssen 
 gerard.meijs...@gmail.com כתב:

 Hoi,
 I understand that item descriptions are going to be used in a mobile
 app. In my opinion that is seriously disappointing because it is not
 realistic to expect enough coverage in any language. Particularly in the
 small languages it will not be really useful.

 My question is: we have had automated descriptions for a long time.
 What is it that they makes that they are not used.?

 Thanks,
  GerardM

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


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


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


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




 --
 Erik Möller
 VP of Product  Strategy, 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



 ___
 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] Visual Editor / Mobile

[Jon Robson]

I've setup T88559 to kick this off. This seems like the first logical step
and has a clear this is done step. We will work out the other bugs as we
go along.

https://phabricator.wikimedia.org/T88559

On Wed, Jan 28, 2015 at 4:30 PM, Jeff Hobson jhob...@wikimedia.org wrote:

 Jumping in here from experience: it was pretty weird to get proper hash
 routing (with back-button support) working with OOUI. Not *impossible*,
 but not incredibly obvious from the get-go since you still register routes
 via MFE, but also have to override teardowns of dialogs (the only component
 I'm familiar with, anyways). A quick example of some needed workarounds
 from the ZeroOverlay module in the ZeroBanner extension (sorry for no
 syntax highlighting):

 45 ProcessDialog.prototype.getTeardownProcess = function ( data ) {
 46 // Parent method
 47 return ProcessDialog.super.prototype.getTeardownProcess.call( this,
 data )
 48 .first( function () {
 49 if ( window.location.hash.indexOf('#/zerosite')  -1 ||
 50  window.location.hash.indexOf('#/zerofile')  -1 ) {
 51 history.replaceState('', document.title,
 window.location.pathname + location.search);
 52 }
 53 }, this );
 54 };


 In addition, there were some minor CSS overrides needed and I think a few
 other issues I can't recall at the moment.

 Thanks,

 Jeff Hobson

 On Wed, Jan 28, 2015 at 1:06 PM, Bartosz Dziewoński 
 bdziewon...@wikimedia.org wrote:

 On Tue, 27 Jan 2015 11:12:27 -0800, Maryana Pinchuk 
 mpinc...@wikimedia.org wrote:

  Ed  Bartosz, how much additional support would you need from a MFE
 frontend dev to make a standalone VE on mobile + MF -- OOUI widget
 conversion happen? 100%? A bit of help here and there? None?


 I don't know, I'm not a mobile developer. What does mobile need that OOUI
 doesn't have? As far as I can tell everything should just work out of the
 box.


 ___
 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] Collections storage/api spike

[Jon Robson]

Indeededy.
I think this will be good enough for a first stab and to get us moving.
The main place I'm worried about race conditions is speed unwatching /
speed adding articles. Storing in separate sub pages won't help with this.

I think this is a huge flaw in this approach and I imagine at some point we
will have to switch over to a database but right now I think it's more
important to get something in front of people. In short I imagine we won't
be using user pages by the end of the quarter.



On Wed, Feb 4, 2015 at 9:36 AM, Sam Smith samsm...@wikimedia.org wrote:

 I've left some comments on PS8.

 The race condition is a result of the way the data is structured and
 stored: the entire collection and its metadata is stored in one wiki page
 as a JSON blob, which can't be updated without reading and writing the
 complete manifest.

 In the example you've provided, you create and manipulate two new
 collections simultaneously. If the requests are processed at roughly the
 same time, then both fail to load the user's collections, create a new one
 and attempt to write a manifest with a single collection in it. Both API
 requests will succeed but only one collection will exist. Only if there's a
 significant delay – longer than it takes to process a single request, say –
 in the processing of one of the requests, *or the requests are ordered*,
 then the first request will successfully create a manifest with a single
 collection in it and then the second request will add a new collection to
 the manifest.

 An alternative implementation, which AFAICT you've already considered, is
 to use sub-pages to store collections, e.g.
 User:Phuedx/Collections/Favourite_Post-metal_Albums, where the
 User:Phuedx/Collections page acts as a manifest but you never explicitly
 update it. Don't worry about auto-incrementing IDs, just map the name of
 the collection to the title of the sub-page. A nice consequence of this is
 that the URLs are human-readable. Better still, the Title class can do
 all of the heavy lifting (see Title::makeTitleSafe and Title#getSubPages).

 Note that you may still see race conditions at the collection level, if,
 say, the user is editing the collection of their favourite post-metal
 albums* in multiple windows or tabs or across multiple devices.

 –Sam

 * Got any suggestions?


 On Tue, Feb 3, 2015 at 9:26 PM, Jon Robson jdlrob...@gmail.com wrote:

 I explored using User pages as a storage mechanism for the minimal
 viable product for the collections work the mobile team is doing. The
 goal is to prove the success of the feature and then feed our findings
 into the multiple lists in core RFC.

 I completed a proof of concept patch for storing collections as lists.
 Essentially it stores all the meta data associated with a users
 collection as a page at User:username/MobileWebCollections.json

 You can test it out by:
 1) checking out: https://gerrit.wikimedia.org/r/#/c/188225/
 2) visiting Special:MobileCollections
 3) refreshing page and seeing a collection with 2 items in it

 Whilst doing this I have discovered that potentially race conditions
 could be an issue with this approach. The sample code carries out
 various transactions and the end state can differ based on which
 finish first. I'm not much of a PHP expert so I'm not sure how to
 remedy this problem. It may not be a problem based on the fact that we
 only anticipate one user managing these lists at a given time.

 Apart from the race condition it seems to work nicely. I imagine the
 API could also be used to handle watchlist watch and unwatch actions
 so that we wouldn't have nasty special cased code for watching
 articles.

 Currently the API is only designed to work on private lists for the
 current user. I would expect a user parameter to be added later.

 Let me know if you have any questions.

 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 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] Collections storage/api spike

[Jon Robson]

I explored using User pages as a storage mechanism for the minimal
viable product for the collections work the mobile team is doing. The
goal is to prove the success of the feature and then feed our findings
into the multiple lists in core RFC.

I completed a proof of concept patch for storing collections as lists.
Essentially it stores all the meta data associated with a users
collection as a page at User:username/MobileWebCollections.json

You can test it out by:
1) checking out: https://gerrit.wikimedia.org/r/#/c/188225/
2) visiting Special:MobileCollections
3) refreshing page and seeing a collection with 2 items in it

Whilst doing this I have discovered that potentially race conditions
could be an issue with this approach. The sample code carries out
various transactions and the end state can differ based on which
finish first. I'm not much of a PHP expert so I'm not sure how to
remedy this problem. It may not be a problem based on the fact that we
only anticipate one user managing these lists at a given time.

Apart from the race condition it seems to work nicely. I imagine the
API could also be used to handle watchlist watch and unwatch actions
so that we wouldn't have nasty special cased code for watching
articles.

Currently the API is only designed to work on private lists for the
current user. I would expect a user parameter to be added later.

Let me know if you have any questions.

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

Re: [WikimediaMobile] Developer tools and workflows

[Jon Robson]

In future it would be great to include other team members/volunteers
outside the mobile web team in these discussions. It was really
interesting seeing how different people work and I already feel more
productive with some of my learnings.

Please let us know if that interests you. We are planning to get
together once a month.

Thanks Joaquin for getting this documented!
Jon


On Tue, Feb 3, 2015 at 6:53 AM, Sam Smith samsm...@wikimedia.org wrote:
 Nice job Joaquin!

 I've already started tweaking my workflow with all of the tips and tricks
 from last time.

 –Sam

 On Tue, Feb 3, 2015 at 11:32 AM, Joaquin Oltra Hernandez
 jhernan...@wikimedia.org wrote:

 Hi!

 The mobile web team and contributors met while in San Francisco and had a
 session on tools, workflows, and useful things to know when developing that
 was pretty awesome.

 We took notes, and I've structured and published them in the Dev sessions
 page (https://www.mediawiki.org/wiki/Mobile_web/Team/Dev_sessions)

 I've probably missed something we talked about, so if I missed something,
 please complete it.

 We plan on having this session monthly, so hopefully we'll keep on filling
 that list.

 If you try any of the items and have any doubts do not hesitate and ask on
 the talk page or via email to mobile-l.

 Cheers!

 ___
 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] Florian for +2 on MobileFrontend?

[Jon Robson]

I've proposed that Florian gets +2 on the MobileFrontend repository.
Florian has been an extremely active MobileFrontend developer (he is
our 5th most active contributor).

It would be great to have him helping out with merging patches. He
also is based in Europe so it would strengthen our ability to get
regressions fixed on different timezones quicker!

You can support this by voting using the {{support}} template on:
https://www.mediawiki.org/wiki/Gerrit/Project_ownership#.2B2_for_Florian_Schmidt_on_mediawiki.2Fextensions.2FMobileFrontend

Please show your {{support}} on the wiki page to make this happen!

(In the words of Spiderman with great power comes great reponsibility)

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

Re: [WikimediaMobile] tmi (too many images)

[Jon Robson]

No, the main reason this got abandoned was it also tried to do ajax
page loading (lazy loading) and there were not enough people
developing on it.

Yes an image would not be loaded if you go offline but if it's hidden
behind a section I think this is acceptable.

Basically the tdlr is: Let's reduce what we serve to our users in that
initial page load and get things snappy :-)
Sam and I have been fiddling with this already here:
https://gerrit.wikimedia.org/r/#/c/187062/

On Tue, Jan 27, 2015 at 12:58 PM, Bahodir Mansurov
bmansu...@wikimedia.org wrote:

 On Jan 27, 2015, at 10:39 AM, Jon Robson jrob...@wikimedia.org wrote:

 We previously explored this
 but it didn't get enough support and I think it is worth revisiting
 now the MobileFrontend code is in a stronger place.


 I was not part of the previous conversation, but I guess one of the reasons
 against it was that we wanted users to be able to view images when they go
 offline. How can we solve this problem if we delay loading images?

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

[WikimediaMobile] Increasing mobile beta audience

[Jon Robson]

One of the frustrations I have heard so far is that the audience there
is too small to get meaningful data around various experiments.
Currently people have to opt in by going to
https://en.m.wikipedia.org/wiki/Special:MobileOptions which is hidden
away in the mobile interface. They can do this whilst anonymous or
logged in.

Have we thought about automatically opting people into beta mode e.g.
a sample of our users in a certain geographic region / certain zero
enabled area/ all users in a certain bucket based on their user id ?

How many users could beta actually handle?
Is this technically possible?
If someone was bucketed into beta would they be able to opt out into
stable again under any of the above situations?

Jon

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

Re: [WikimediaMobile] Visual Editor / Mobile

[Jon Robson]

This will be a part time activity that will happen on the side managed
via phabricator bugs. I do not anticipate this being a drastic amount
of work, especially given the prior cleanup we have done in the
MobileFrontend extension.


On Tue, Jan 27, 2015 at 11:12 AM, Maryana Pinchuk
mpinc...@wikimedia.org wrote:
 Sounds good – but let's talk about who's going to be doing this work and
 when :)

 This quarter, we're planning to launch WikiGrok at 100% on enwiki and
 release a new pilot feature (Collections) on mobile web. Jon R will also be
 away for the month of February.

 Jon: are you saying you want to commit to this work now, given what needs to
 get done on Collections + the experimental infobox editing stuff you've been
 doing in 20% time + your vacation time?

 Ed  Bartosz, how much additional support would you need from a MFE frontend
 dev to make a standalone VE on mobile + MF -- OOUI widget conversion
 happen? 100%? A bit of help here and there? None?

 My gut says that if the VE team needs more than limited ad hoc support from
 MFE engineers for this project, we should spend Q3 creating the backlog and
 do the work in Q4.

 On Tue, Jan 27, 2015 at 10:22 AM, Ed Sanders esand...@wikimedia.org wrote:

 That pretty much sums it up Jon, thanks for that.

 My vision is that ideally VE standalone would work in mobile on it's own,
 and so the MW integration would be as light as possible: connecting up the
 load/save APIs and placing the VE instance in the right place.

 Converting MF to OOUI widgets is also a great goal, and will make moving
 code between the the extensions a lot easier.

 I'm CCing in Bartosz as he's doing great work on OOUI at the moment, and
 it would be great if he could work with mobile to make sure we have all the
 widgets and browser support tricks we need for touch devices.

 On 27 January 2015 at 10:00, Jon Robson jrob...@wikimedia.org wrote:


 Ideally all the existing code should live in VisualEditor and be based
 on OOJS UI. In the future we could also imagine the wikitext editor in
 mobile becoming part of the VisualEditor tool itself.




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




 --
 Maryana Pinchuk
 Product Manager, Wikimedia Foundation
 wikimediafoundation.org

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