Mobile-l March 2014

mobile-l@lists.wikimedia.org

44 participants
79 discussions

Your input needed: project management/bug reporting/code management/etc tools
by Arthur Richards 31 Mar '14

31 Mar '14

Everyone, there is some lively discussion happening right now around trying to unify the various tools in our workflow - at the team levels as well as at the org/project level. The idea is to try and find a way to minimize and/or eliminate the fact that we use 23872394 different tools to manage bugs, plan our work, track our work, manage/review code changes/etc - and that those tools are not even necessarily consistent across teams. The growing consensus appears to be around using Phabricator as The Tool to Rule them All - it would replace bugzilla, gerrit, mingle/trello/your (least) favorite PM tool/etc. Especially for those of you that are frustrated by Mingle/BZ/Gerrit/etc - you should spend some time playing with some of the tools being proposed and weigh in on the discussion. Relevant links are: * https://www.mediawiki.org/wiki/Project_management_tools/Review/Options * https://www.mediawiki.org/wiki/Requests_for_comment/Project_management_tool… My personal view at the moment is that Phabricator seems really cool but lacks some of the power and flexibility we get with Mingle in terms of organizing our work, viewing cards, planning, controlling workflows, etc (in some respects, I would say it is much closer to how Trello works), however these features are currently in Beta and may evolve for greater flexibility. -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687

4 4

QA tests: "Main Page" vs. "Main_Page"
by Chris McMahon 31 Mar '14

31 Mar '14

So as you probably know, some of our tests that pass in Firefox fail in Chrome. One issue is that in a number of places the tests accept a string to look for in a URL that is defined as "Main Page". But in the browser, the URL ultimately will contain the string "Main_Page". I committed a change such that the test would check that *at some point* the URL will contain the string "Main Page" as specified in the test. In hindsight, this was probably a bad idea, because the original tests just care that we land on the correct URL, not that we handle spaces correctly. https://gerrit.wikimedia.org/r/#/c/119878 Jon committed a change that invisibly munges the input string to replace the first (and only the first) space character with an underline character. This is probably also not a great idea, because it secretly changes test inputs without the user (or maintainer) knowing. https://gerrit.wikimedia.org/r/#/c/120564 After thinking it over, I think what we should do to make the tests perform the way the tests were intended to perform is to revert the two changes I mentioned above, and to simply change every occurrence of "Main Page" in the features to be "Main_Page". That will not only satisfy Firefox and Chrome, but it will also satisfy the intent of the tests themselves. I suspect that using "Main Page" was essentially a typo that propagated through the test suite over time. -Chris

5 13

App feedback - show my password
by Jon Robson 28 Mar '14

28 Mar '14

I downloaded the Android app for Wikipedia and had a play around with it. One particular bit gave me a bad experience/first impression, so here's some feedback for you. I was completely puzzled yesterday when I tried logging into the Wikipedia app for the first time. I added my login, password and then hit the checkbox to remember my login.. only then to realise my password was not visible in plaintext and that the label did not say remember my login [1]. Now this password I use on a couple of sites (I know that's bad but it's the case here). I never write it anywhere, it's engrained in my memory. So to see it there in plain text freaked me out and I was suddenly weary that I was in a public space where people could see over my shoulder and to be honest I felt really violated. I've now changed that password. This was a really nasty experience for me. I'm trained to check those remember login checkboxes, just as on a signup form I'm trained to uncheck the add me to your mailing list box (which some forms abuse) and check the i agree to terms and conditions boxes. I never read the label. I don't really get the need for such a feature though. No login forms on the web in website or app form that I know of have such an option as `show password` (please point me at some if they exist). It's not clear to me what this achieves. It doesn't help me remember it for example... all it seems to achieve is to give the impression that the password is not important and can be shared. [1] http://imgur.com/Rfc5QF9

4 4

Wikivoyage: Tweaks to Special:Nearby
by Jon Robson 28 Mar '14

28 Mar '14

Recently we upped the radius for searches on Wikivoyage to 20km. This still isn't probably enough for certain towns. Is there anyway we can increase the maximum radius here (what is the highest we can safely go to?) and incrementally increase it when no search results are found. e.g. search within 20km, then within 30km, then within 40km all the way to 50km? There is some cool discussion going on here: https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Tweaks_to_Speci… it will be great to help out the Wikivoyage community.

5 12

#footer-places-terms-use
by Amir E. Aharoni 28 Mar '14

28 Mar '14

Hi, I was translating the recently added licensing messages: Mobile-frontend-editor-licensing-with-terms Mobile-frontend-photo-licensing-with-terms I noticed that they have "link to license" as $1. I wondered how does it work exactly, because this may affect the translation and needs to be documented in more detail. I checked the code. Looks like it clones the $( '#footer-places-terms-use' ) element. This is theoretically reasonable, but when I tried grepping for footer-places-terms-use, I couldn't find where is it used. Either I am missing something or this feature is so fresh that it's not complete :) In any case, the qqq should be updated to make it clear how are those terms inserted. In some languages it may need more than just inserting $1, for example - it may or may not need {{GRAMMAR}}. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

1 1

Mobile and CheckUser (Was [mobile-l][Analytics] Wikipedia App User Agents)
by Yuvi Panda 28 Mar '14

28 Mar '14

Forking since I think there are two conversations - one about the format of UA for the mobile apps and one about CheckUser requirements for anything that does edits. Having them separate would be useful. For those who do not know what CheckUser means, I recommend reading https://en.wikipedia.org/wiki/Wikipedia:CheckUser. IP address and UA are amongst the two most important pieces of info CUs have in helping prevent abuse. IP is already sortof useless with mobile networks - a lot of providers do NAT and similar things that mean that we can not remotely close to reasonably assume 1 IP = 1 User, or anything remotely similar to that. UA provides more fingerprinting ability, but CU isn't the only thing that consumes UA - other parts of the infrastructure do as well. So what we need, is a way to preserve the ability to fingerprint only users making edits (no read actions!) for CU. I am sure that can be implemented without having to have a very fingerprintable UA, with simple hooks on both the App's side and on Extension:CheckUser. We could generate a simple fingerprint that's unique per device (and disconnected completely from every other device identifier) that we send only with edits (and other 'POST' actions) as a separate header. This can be processed by CU (perhaps with a hook that Extension:MobileApp can hook into) and then used by CheckUsers. This data will be treated with the same data retention / privacy policy that applies to CUs now, and regular UA data can be consumed by other consumers without too much fingerprinting concerns. I talked to hoo and he said the CU hook shouldn't be too much of a problem, and the app side of the issue is rather simple too. Deskana (speaking solely as a volunteer CU) says that this solution is acceptable to him. Thoughts other people? On Thu, Mar 27, 2014 at 10:43 PM, Oliver Keyes <okeyes(a)wikimedia.org> wrote: > Repost, because filtering; there might be a point of confusion here that's > causing the problem. As I understand it, the user agent sanitisation is > expected to apply to EventLogging data, and data in the Analytics pipeline, > but not data streaming into MediaWiki proper - namely, the cu_changes table. > Nuria, is that the case? > > > On 27 March 2014 08:16, Nuria Ruiz <nuria(a)wikimedia.org> wrote: >> >> >Rather than having an ethical debate over it, we could always test the >> > actual usefulness with Science. That way we'd be able to see how much >> > granularity each additional component adds to the data. >> I kind of feel we are going backwards as we throughly discussed this >> point, technical info and references regarding entropy and user agents and >> fingerprinting can be found here: >> https://www.mediawiki.org/wiki/EventLogging/UserAgentSanitization >> >> >> >> On Thu, Mar 27, 2014 at 3:49 PM, Oliver Keyes <okeyes(a)wikimedia.org> >> wrote: >>> >>> +1. I'm totally down for keeping less information around, but if it gets >>> in the way of people doing their job? >>> >>> Rather than having an ethical debate over it, we could always test the >>> actual usefulness with Science. That way we'd be able to see how much >>> granularity each additional component adds to the data. >>> >>> >>> On 27 March 2014 07:15, Aaron Halfaker <ahalfaker(a)wikimedia.org> wrote: >>>>> >>>>> Including more information on the UA, while being covered by legal >>>>> under the new privacy policy, really goes agains the wishes of the community >>>>> as they do not wish to be finger printed. >>>> >>>> >>>> I don't think that "the wishes of the community" have been established >>>> and the whole point of checkuser is that it allows for fingerprinting. >>>> >>>> >>>> On Thu, Mar 27, 2014 at 4:20 AM, Nuria Ruiz <nuria(a)wikimedia.org> wrote: >>>>> >>>>> >>>>> >As a checkuser, user agents are an important part of my workflow for >>>>> > identifying that multiple accounts are owned by the same person. >>>>> > So I'm going to have to argue for including more information in the >>>>> > user agent. >>>>> >>>>> Including more information on the UA, while being covered by legal >>>>> under the new privacy policy, really goes agains the wishes of the community >>>>> as they do not wish to be finger printed. >>>>> See: >>>>> https://www.mediawiki.org/wiki/Talk:EventLogging/UserAgentSanitization or >>>>> https://meta.wikimedia.org/wiki/Talk:Privacy_policy >>>>> There has been plenty more discussions about this on analytics e-mail >>>>> list. >>>>> >>>>> >>>>> >Your proposed user agent would basically mean that every single person >>>>> > using the most up-to-date version of the app on a particular platform would >>>>> > >be indistinguishable from each other. This would, unfortunately, lead to >>>>> > lots of innocent users getting blocked as sockpuppets. >>>>> >>>>> However, note that the UA " WikipediaApp/<version> >>>>> <OS>/<form-factor>/<version>" clearly satisfies the use case of the mobile >>>>> team. It provides as much information as they need from their user without >>>>> sending any private data. >>>>> >>>>> Can you please list what is your use case? Namely how are you >>>>> identifying "false" accounts. Perhaps relying on the user agent to do so is >>>>> not the best strategy going forward. Have in mind that with the old privacy >>>>> policy UA data needed to be discarded after 90 days. With the new policy >>>>> there is more legal room but given community feedback analytics team is >>>>> planning on aggregating all UA information in the future. This means that UA >>>>> data will not be stored (or reported) per user or request but rather >>>>> agreggated (as in "4% of users use iPhone"). >>>>> >>>>> We gathered recently information from all teams as to use cases >>>>> pertaining UA data collection: >>>>> >>>>> https://office.wikimedia.org/wiki/Analytics/Internal/EventLogging/PrivateDa…. >>>>> >>>>> Let's talk about your use case and add it to the document that already >>>>> exists describing usages of user agent data, this document was sent out to >>>>> all teams couple months ago but there is no description of your use case >>>>> there: >>>>> >>>>> https://docs.google.com/a/wikimedia.org/document/d/1bp6qrvYi0Mh7l0s1psGnXEE… >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Mar 26, 2014 at 11:20 PM, Dan Garry <dgarry(a)wikimedia.org> >>>>> wrote: >>>>>> >>>>>> Hey Yuvi, >>>>>> >>>>>> As a checkuser, user agents are an important part of my workflow for >>>>>> identifying that multiple accounts are owned by the same person. So I'm >>>>>> going to have to argue for including more information in the user agent. >>>>>> Your proposed user agent would basically mean that every single person using >>>>>> the most up-to-date version of the app on a particular platform would be >>>>>> indistinguishable from each other. This would, unfortunately, lead to lots >>>>>> of innocent users getting blocked as sockpuppets. >>>>>> >>>>>> Here's an example of a user agent from an iPhone using Safari: >>>>>> Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_1 like Mac OS X; zh-tw) >>>>>> AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8G4 >>>>>> Safari/6533.18.5 >>>>>> >>>>>> Look at all of that wonderful information! ;-) In general, the more >>>>>> information you can include without breaching the user's privacy, the >>>>>> better. >>>>>> >>>>>> I'd be happy to work with you on this. >>>>>> >>>>>> Thanks, >>>>>> Dan >>>>>> >>>>>> P.S. You may also want to consult with the legal team, to ensure that >>>>>> an unacceptable levels of private information are not given out. They would >>>>>> also make a complement for me; I would likely be pulling in the direction of >>>>>> "MOAR INFORMATION!", whereas they would likely be pulling in the direction >>>>>> of "LESS INFORMATION!". :-) >>>>>> >>>>>> >>>>>> On 26 March 2014 15:00, Yuvi Panda <yuvipanda(a)gmail.com> wrote: >>>>>>> >>>>>>> Add Analytics to cc, as I think they'll be interested as well :) >>>>>>> >>>>>>> On Thu, Mar 27, 2014 at 3:20 AM, Yuvi Panda <yuvipanda(a)gmail.com> >>>>>>> wrote: >>>>>>> > Hello! >>>>>>> > >>>>>>> > We are getting closer to a general release of the Wikipedia Android >>>>>>> > and iOS apps, and I think we should standardize on a User-Agent >>>>>>> > format. The old app just appended an identifier in front of the >>>>>>> > phone's default UA[1] but I think we can do better, to avoid >>>>>>> > privacy >>>>>>> > concerns[2]. >>>>>>> > >>>>>>> > How about: >>>>>>> > >>>>>>> > WikipediaApp/<version> <OS>/<form-factor>/<version> >>>>>>> > >>>>>>> > This gives us all the info we need (App version, OS, Form Factor >>>>>>> > (Tablet / Phone) and OS version) without giving away too much. It >>>>>>> > is >>>>>>> > also fairly simple to construct and parse. >>>>>>> > >>>>>>> > For the latest alpha, my Nexus 4 would generate >>>>>>> > >>>>>>> > WikipediaApp/32 Android/Phone/4.4 >>>>>>> > >>>>>>> > While an iOS device might generate >>>>>>> > >>>>>>> > WkipediaApp/2.0 iOS/Phone/7.1 >>>>>>> > >>>>>>> > form-factor would just be Phone|Tablet for now, and can be expanded >>>>>>> > later if necessary. >>>>>>> > >>>>>>> > Thoughts? >>>>>>> > >>>>>>> > [1]: https://www.mediawiki.org/wiki/Mobile/User_agents#Apps >>>>>>> > [2]: >>>>>>> > https://www.mediawiki.org/wiki/EventLogging/UserAgentSanitization >>>>>>> > -- >>>>>>> > Yuvi Panda T >>>>>>> > http://yuvi.in/blog >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Yuvi Panda T >>>>>>> http://yuvi.in/blog >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Analytics mailing list >>>>>>> Analytics(a)lists.wikimedia.org >>>>>>> https://lists.wikimedia.org/mailman/listinfo/analytics >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Dan Garry >>>>>> Associate Product Manager for Platform >>>>>> Wikimedia Foundation >>>>>> >>>>>> _______________________________________________ >>>>>> Analytics mailing list >>>>>> Analytics(a)lists.wikimedia.org >>>>>> https://lists.wikimedia.org/mailman/listinfo/analytics >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Analytics mailing list >>>>> Analytics(a)lists.wikimedia.org >>>>> https://lists.wikimedia.org/mailman/listinfo/analytics >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Analytics mailing list >>>> Analytics(a)lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/analytics >>>> >>> >>> >>> >>> -- >>> Oliver Keyes >>> Research Analyst >>> Wikimedia Foundation >>> >>> _______________________________________________ >>> Analytics mailing list >>> Analytics(a)lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/analytics >>> >> >> >> _______________________________________________ >> Analytics mailing list >> Analytics(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/analytics >> > > > > -- > Oliver Keyes > Research Analyst > Wikimedia Foundation -- Yuvi Panda T http://yuvi.in/blog

5 5

Re: [WikimediaMobile] Mobile and CheckUser (Was [mobile-l] Wikipedia App User Agents)
by ENWP Pine 28 Mar '14

28 Mar '14

I got the impression from this discussion that the mobile apps aren't currently in use so the CUs have had no experience working with them. It sounds like I was mistaken. Toby, what UA data do CUs currently see from edits made through the mobile apps? CUs, is the information that you're currently getting from edits from the new mobile apps a good balance the concerns raised previously in this discussion? Pine > Date: Thu, 27 Mar 2014 15:36:16 -0700 > From: Toby Negrin <tnegrin(a)wikimedia.org> > To: "A mailing list for the Analytics Team at WMF and everybody who > has an interest in Wikipedia and analytics." > <analytics(a)lists.wikimedia.org> > Cc: mobile-l <mobile-l(a)lists.wikimedia.org>, Oliver Keyes > <ironholds(a)gmail.com>, Yuvi Panda <yuvipanda(a)gmail.com> > Subject: Re: [Analytics] [WikimediaMobile] Mobile and CheckUser (Was > [mobile-l] Wikipedia App User Agents) > Message-ID: > <CAAjh0EyqpFDke3P6Q5FxecOnE5yc7uSs_VS9HcB5khoxZ6-Yng(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hey folks -- we aren't considering changing any of the data that goes into > checkuser. That tool will be unchanged. > > This discussion only concerns backend logging EventLogging and page view > analytics. > > thanks, > > -Toby >

3 5

Wikipedia Android app Alpha 2014-03-26 out!
by Yuvi Panda 27 Mar '14

27 Mar '14

Hello! I'm going to start sending out notifications whenever an Android app alpha goes out, and one went out just now! (See http://lists.wikimedia.org/pipermail/mobile-l/2014-March/006642.html for how to get the Alpha) What's new in this alpha: 1. Uses OTRS for getting feedback from users 2. CSS fixes for long links 3. General stability fixes 4. Has a 'My Contributions' page! 5. Localization updates. I'll probably be consistently making a build a week on alpha now. Do try out and give feedback! Thanks to Sage Ross, Alice Fleabite, Luis Villa, Reedy & Liangent for feedback from the last alpha! -- Yuvi Panda T http://yuvi.in/blog

2 1

Auditing beta and alpha features in mobile
by Jon Robson 27 Mar '14

27 Mar '14

As Kenan pointed out during the last estimation meeting we have not been keeping https://www.mediawiki.org/wiki/Mobile/Release_history up to date. How can we ensure we do a better job of this? Should someone be responsible for it?

2 1

QA Tests: Waiting for things to disappear
by Jon Robson 27 Mar '14

27 Mar '14

The VE tests are failing due to the longstanding cookie error. The wikitext editor tests are failing on the "I should not see the wikitext editor overlay" The overlay takes time to disappear and the test doesn't keep this in mind and just sees it and declares it having failed. Should we introduce a wait step to get round this or there is a more elegant way?

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l March 2014