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