Re: [WikimediaMobile] [Commons-l] Fwd: [Wikimedia-l] Pebble smartwatch tool for finding Wikipedia photo opportunities

[Luis Villa]

Someone created a web page on labs somewhere that does exactly this, and I
used it to improve my neighborhood, but I can't find it now :(

On Sat, Nov 5, 2016, 9:04 PM Rehman Abubakr 
wrote:

> This is great! It would be really cool if someone could write a similar
> Android mobile app...
>
>
>
> Thanks and regards,
>
> User:Rehman 
>
>
> --
> *From:* Commons-l  on behalf of
> Pine W 
> *Sent:* 06 November 2016 08:17
> *To:* mobile-l; Wikimedia Commons Discussion List
> *Subject:* [Commons-l] Fwd: [Wikimedia-l] Pebble smartwatch tool for
> finding Wikipedia photo opportunities
>
> Forwarding
>
> Pine
>
>
> -- Forwarded message --
> From: *Sage Ross* 
> Date: Sat, Nov 5, 2016 at 3:29 PM
> Subject: [Wikimedia-l] Pebble smartwatch tool for finding Wikipedia photo
> opportunities
> To: Wikimedia Mailing List 
>
>
> Hi folks!
>
> I made something that I think is pretty cool: a watchface for Pebble
> smartwatches that shows you the nearest unphotographed Wikipedia
> article. I've been using it for about a month, and I'm really happy
> with how it's turned out. I've taken a lot of photos for articles that
> I wouldn't have otherwise.
>
> It's called "Diderot". If you have a Pebble, check it out:
> https://apps.getpebble.com/en_US/application/57dc94602a6ea66551f0
>
> A few neat things about it:
>
> * You can configure it for a number of different language versions of
> Wikipedia
> * It uses a wmflabs API by Albin Larrson which filters out articles
> that have only a png or svg illustration, so you still see the
> articles that have a map or logo but lack a real photograph.
>
> -Sage
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: wikimedi...@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
> ___
> Commons-l mailing list
> common...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/commons-l
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Some interesting stuff from Google

[Luis Villa]

On Mon, Oct 12, 2015 at 12:50 PM, Volker Eckl <ve...@wikimedia.org> 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.
>

FWIW, Google appears to be serious about this:
http://searchengineland.com/google-amp-coming-rank-fast-238046

Luis


> On Fri, Oct 9, 2015 at 6:43 PM, Jon Katz <jk...@wikimedia.org> 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 <lvi...@wikimedia.org> wrote:
>>
>>> On Thu, Oct 8, 2015 at 5:39 PM, Toby Negrin <tneg...@wikimedia.org>
>>> 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 g

Re: [WikimediaMobile] Some interesting stuff from Google

[Luis Villa]

On Thu, Oct 8, 2015 at 5:39 PM, Toby Negrin <tneg...@wikimedia.org> 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 on Google would
be even better, but that's not in the cards at this point unless Mozilla
wakes up.



>
>
>
>
>
>
>
> On Thu, Oct 8, 2015 at 2:02 PM, Luis Villa <lvi...@wikimedia.org> wrote:
>
>> Toby -
>>
>> I'm generally 1000% on-board with slow follower for anything user-facing.
>> The only reason I might make an exception here is because the competitors
>> you mention are all pretty awful for the web generally, and this has uptake
>> already from Google and Twitter. (Two isn't great, but two + slim
>> opportunity for growth is way better than the guaranteed
>> never-greater-than-1 we'll see from FB's option.)
>>
>> The other reason this intrigues me is that if Google builds in some
>> analytics, it might give us a better sense of their current usages for us
>> than we currently have. Not much, obviously, but at least something.
>> (Remember that in this scenario - direct access from Google properties -
>> they already have all that information, the only question is whether it
>> gets shared with us so that we can do something useful with it.)
>>
>> That said, if implementing it is non-trivial, it doesn't make sense to
>> spend a huge number of cycles to fast-follow. Hopefully some of the
>> improvements Bryan mentions will make it easier in the future - it
>> certainly doesn't look like we're in a world where the number of front ends
>> is going to get smaller any time soon.
>>
>> Luis
>>
>> On Thu, Oct 8, 2015 at 1:25 PM, Toby Negrin <tneg...@wikimedia.org>
>> wrote:
>>
>>> Thanks Bryan and Pine.
>>

Re: [WikimediaMobile] Some interesting stuff from Google

[Luis Villa]

Best big-picture article I saw on it last night was 
http://www.niemanlab.org/2015/10/get-ampd-heres-what-publishers-need-to-know-about-googles-new-plan-to-speed-up-your-website/

On Thu, Oct 8, 2015 at 8:05 AM, Jon Katz <jk...@wikimedia.org> wrote:

> FYI. Google just announced an open source project to create a speedier 
> framework for mobile browsing.  It might be worth looking at what they're 
> doing:
>
> From:
>
> http://tech.slashdot.org/story/15/10/08/035200/googles-effort-to-speed-up-the-mobile-web?utm_source=rss1.0mainlinkanon_medium=feed
>
>
> Google has officially taken the wraps off its AMP project — Accelerated 
> Mobile Pages <https://www.ampproject.org/> — which aims to speed up the 
> delivery of web content to mobile devices 
> <https://www.ampproject.org/how-it-works/>. They say, "We began to 
> experiment with an idea: could we develop a restricted subset of the things 
> we'd use from HTML, that's both fast and expressive, so that documents 
> would always load and render with reliable performance?" That subset is now 
> encapsulated in AMP, their proof-of-concept. They've posted the code to 
> GitHub <https://github.com/ampproject/amphtml> and they're asking for 
> help from the open source community to flesh it out. Their conclusions are 
> familiar to the Slashdot crowd: "One thing we realized early on is that 
> many performance issues are caused by the integration of multiple 
> JavaScript libraries, tools, embeds, etc. into a page. This isn't saying 
> that JavaScript immediately leads to bad performance, but once arbitrary 
> JavaScript is in play, most bets are off because anything could happen at 
> any time and it is hard to make any type of performance guarantee. With 
> this in mind we made the tough decision that AMP HTML documents would not 
> include any author-written JavaScript, nor any third-party scripts." 
> They're seeing speed boosts anywhere from 15-85%, but they're also looking 
> at pre-rendering options to make some content capable of loading 
> instantaneously. Their FAQ <https://www.ampproject.org/faq/> has a few 
> more details.
>
> Google blog announcement:
>
> https://googleblog.blogspot.com/2015/10/introducing-accelerated-mobile-pages.html
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>


-- 
Luis Villa
Sr. Director of Community Engagement
Wikimedia Foundation
*Working towards a world in which every single human being can freely share 
in the sum of all knowledge.*___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Some interesting stuff from Google

[Luis Villa]

Toby -

I'm generally 1000% on-board with slow follower for anything user-facing.
The only reason I might make an exception here is because the competitors
you mention are all pretty awful for the web generally, and this has uptake
already from Google and Twitter. (Two isn't great, but two + slim
opportunity for growth is way better than the guaranteed
never-greater-than-1 we'll see from FB's option.)

The other reason this intrigues me is that if Google builds in some
analytics, it might give us a better sense of their current usages for us
than we currently have. Not much, obviously, but at least something.
(Remember that in this scenario - direct access from Google properties -
they already have all that information, the only question is whether it
gets shared with us so that we can do something useful with it.)

That said, if implementing it is non-trivial, it doesn't make sense to
spend a huge number of cycles to fast-follow. Hopefully some of the
improvements Bryan mentions will make it easier in the future - it
certainly doesn't look like we're in a world where the number of front ends
is going to get smaller any time soon.

Luis

On Thu, Oct 8, 2015 at 1:25 PM, Toby Negrin <tneg...@wikimedia.org> wrote:

> Thanks Bryan and Pine.
>
> My feeling is that there are many many new interfaces and form factors
> emerging right now and we should be cautious about adoption. For example
> Facebook's instant articles, apple news and even snapchat have similar
> offerings the AMP.
>
> They all seem to be focusing on article speed in a landscape where most
> pages are larded up with a variety of trackers, ads and other scripts
> (which we don't have, although we have our own challenges on performance)
> with the ultimate goal of owning the delivery platform.
>
> I'm nervous about picking winners in such a landscape although I'm excited
> about prototypes like things like the Apple Watch app that came out of the
> Lyon hackathon. I feel like a slow follower model where we see which
> solution if any becomes widely used is more appropriate for us.
>
> -Toby
>
>
> On Thursday, October 8, 2015, Pine W <wiki.p...@gmail.com> wrote:
>
>> Hi Bryan,
>>
>> Ah, I was thinking of the 2 different mobile web editing experiences (not
>> 2 different apps) for Android depending on form factor. My understanding is
>> that tablets have VE enabled on mobile web now (I have yet to try it) while
>> phones do not have VE enabled on mobile web yet.
>>
>> Pine
>> On Oct 8, 2015 12:56 PM, "Bryan Davis" <bd...@wikimedia.org> wrote:
>>
>>> On Thu, Oct 8, 2015 at 1:32 PM, Pine W <wiki.p...@gmail.com> wrote:
>>> > We currently have at least 6 channels, I believe:
>>> >
>>> > 1. Desktop Web
>>> > 2. Mobile Web
>>> > 3. Android phone
>>> > 4. Android tablet
>>>
>>> I don't think that we have separate native apps for the phone and
>>> tablet form factors.
>>>
>>> > 5. IPhone
>>> > 6. Legacy Android phone
>>> >
>>> > I'm no expert on mobile developmemt, but perhaps WMF could experiment
>>> with
>>> > Google's idea on just one channel to start?
>>>
>>> AMP would only be appropriate for the mobile web channel from the list
>>> above. Implementing it would be a matter of placing some sort of
>>> translating proxy between MediaWiki and the requesting user agent that
>>> downgraded the HTML produced by MediaWiki to AMP's restricted HTML
>>> dialect. That sort of translation might be possible in MobileFrontend
>>> but it would likely be accomplished much more easily using some other
>>> tech stack that had good support for manipulation of HTML like a
>>> node.js service. It might be an interesting prototype project for a
>>> volunteer to experiment with a frontend app that consumed the RESTBase
>>> provided Parsoid HTML (e.g.
>>> https://en.wikipedia.org/api/rest_v1/page/html/NOFX) and spit out AMP
>>> compliant documents.
>>>
>>> The only other option really to produce alternate HTML from MediaWiki
>>> would require swapping out the existing layer that translates an
>>> article's wikitext to HTML with a version that spoke AMP instead. That
>>> would be related to https://phabricator.wikimedia.org/T114194.
>>>
>>> Bryan
>>> --
>>> Bryan Davis  Wikimedia Foundation<bd...@wikimedia.org>
>>> [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
>>> irc: bd808v:415.839.6885 x6855
>>>
>>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>


-- 
Luis Villa
Sr. Director of Community Engagement
Wikimedia Foundation
*Working towards a world in which every single human being can freely share
in the sum of all knowledge.*
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Android Wikipedia beta app release (2.0.110-beta-2015-08-31)

[Luis Villa]

On Mon, Aug 31, 2015 at 3:25 PM, Stephen Niedzielski <
sniedziel...@wikimedia.org> wrote:

>   * Autoscroll to URL fragment for redirected pages
>

Woot. This is small and silly but has bothered me for ages ;) Thanks to all
of you for your continued hard work on this!

Luis


-- 
Luis Villa
Sr. Director of Community Engagement
Wikimedia Foundation
*Working towards a world in which every single human being can freely share
in the sum of all knowledge.*
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [reading-wmf] Wikipedia article previews in Kindle app

[Luis Villa]

FWIW, they are also doing basically the same thing in the e-ink hardware
Kindles.

On Fri, Jun 5, 2015 at 8:25 AM, Dmitry Brant dbr...@wikimedia.org wrote:

 +mobile-l


 On Fri, Jun 5, 2015 at 11:23 AM, Adam Baso ab...@wikimedia.org wrote:

 Okay to move this to mobile-l?


 On Friday, June 5, 2015, Brian Gerstle bgers...@wikimedia.org wrote:

 While they strip out links/citations, they do preserve text formatting
 (italics  bold).

 On Fri, Jun 5, 2015 at 10:39 AM, Bernd Sitzmann be...@wikimedia.org
 wrote:

 Nice find. I also like being able to swipe those cards left/right
 between different information sources. Looks like depending on the selected
 words it's: Dictionary, Wikipedia, Translation

 On Thu, Jun 4, 2015 at 10:45 PM, Dmitry Brant dbr...@wikimedia.org
 wrote:

 I was using the Kindle app on the plane today, and I noticed a few
 interesting things, including this:
 ​
  device-2015-06-04-225651.png
 https://docs.google.com/a/wikimedia.org/file/d/0BzcksMsMNpY1SzA3bHY4WF9hM1U/edit?usp=drive_web
 ​
 When highlighting a word or phrase, the user is presented with a
 definition of the word from Wikipedia. The content is presented in a 
 native
 component, with only the first section of text shown (all links,
 references, infoboxes, etc. are stripped out). (I wonder what API they're
 using?)

 It looks very similar to the link preview prototypes we've been
 developing in our apps, and it's very telling that the Kindle app has such
 a feature, since it helps emphasize the usefulness of this feature in any
 kind of reader app.  Perhaps, in addition to link previews, we may also
 want to think about allowing users to highlight words and show definitions
 (from Wiktionary?), pronunciations, translations, etc...


 p.s. I was able to get the Kindle app to crash by clicking a link
 inside one of the Wikipedia previews that wasn't stripped out correctly.
 In other words, no app is safe from the edge cases of wikitext!


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



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




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


 ___
 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




-- 
Luis Villa
Sr. Director of Community Engagement
Wikimedia Foundation
*Working towards a world in which every single human being can freely share
in the sum of all knowledge.*
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Moderation tools [was Re: Commons Reloaded]

[Luis Villa]

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

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


Lila is convinced it is a good use of time; that's why tools for community
needs was in the Call To Action. And that's why we announced the creation
of a Community Tech team yesterday (see wikimedia-l). Details and
prioritization are still to be fleshed out (they can't tackle everything at
once!) but moderation tools are definitely one of the things the team could
tackle.

Luis

-- 
Luis Villa
Sr. Director of Community Engagement
Wikimedia Foundation
*Working towards a world in which every single human being can freely share
in the sum of all knowledge.*
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] WikiGrok deployed

[Luis Villa]

This is terrific- congrats to everyone. I'm a little curious how/when this
is supposed to trigger- I went to a few pages with beta turned on and got
nothing. :/ Under what conditions *should* we be seeing it?

Luis

On Mon, Nov 3, 2014 at 3:52 PM, Tomasz Finc tf...@wikimedia.org wrote:

 Congrats Max and team. Eager to see how our users interact with this.

 On Mon, Nov 3, 2014 at 2:16 PM, Max Semenik maxsem.w...@gmail.com wrote:
  Hi, WikiGrok[0] has been successfully deployed to the English Wikipedia.
  Along with it a first campaign[1] was deployed. Now database is being
 slowly
  populated with suggestions:
 
  MariaDB [enwiki_p] select page_title, pp_value from page, page_props
 where
  pp_page=page_id and pp_propname='wikigrok_questions_v1' limit 100;
 
 +-+--+
  | page_title  | pp_value
  |
 
 +-+--+
  | Richard_Branson |
 
 a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
  |
  | Tina_Fey|
 
 a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
  |
  | Jon_Stewart |
 
 a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
  |
  | Bill_Maher  |
 
 a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
  |
  | Jeff_Foxworthy  |
 
 a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
  |
  | Evadne_Price|
 
 a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
  |
  | Dominic_Guard   |
 
 a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
  |
  | Dilsa_Demirbag_Sten |
 
 a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
  |
  | J._Douglas_MacMillan|
 
 a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
  |
  | Carol_Bowman|
 
 a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
  |
  | Lianella_Carell |
 
 a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
  |
  | G._K._Reddy |
 
 a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
  |
  | Liù_Bosisio |
 
 a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
  |
  | Matilde_Rodríguez_Cabo  |
 
 a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
  |
 
 +-+--+
  14 rows in set (0.42 sec)
 
  Pages are getting updated when edited (null edit works, but not
  action=purge). According to estimations made with WikiData Query[2], the
  number of potentially affected pages is approximately 33,000. If really
  needed, we could whip up a script to null-edit these pages from server
 side
  in a controlled manner, but I would like to have more data on performance
  and memory consumption first.
 
  == Monitoring ==
  * Graphite: MediaWiki - WikiGrok
  * Exceptions from WikiData: type:mobile in Logstash.
 
  == Firefighting ==
  Most of potentially performance-scary/error causing code with can be
  disabled by commenting out $wgWikiGrokSlowCampaigns in
  wmf-config/mobile.php. If shit hits fan really hard, whole extension can
 be
  disabled through the usual means, with $wmgUseWikiGrok.
 
  == Next steps ==
  I'm working on DB storage for questions[3] which will allow us to avoid
  abusing page_props and give features such as find me pages that could
 use
  this type of fixes and find me a random page to fix.
 
 
  
  [0] https://www.mediawiki.org/wiki/Extension:WikiGrok
  [1] https://gerrit.wikimedia.org/r/#/c/170453/
  [2] http://wdq.wmflabs.org/
  [3] https://gerrit.wikimedia.org/r/170263
 
  --
  Best regards,
  Max Semenik ([[User:MaxSem]])
 
  ___
  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




-- 
Luis Villa
Deputy General Counsel
Wikimedia Foundation
415.839.6885 ext. 6810

*This message may be confidential or legally privileged. If you have
received it 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

Re: [WikimediaMobile] Wikipedia App (iOS) beta tester numbers and feedback

[Luis Villa]

Friendly reminder - people probably assume that this feedback is
private[1]; try to crop out their names before posting their feedback
publicly.

Luis

[1] And I am curious about the TestFlight privacy policy, which is
currently 404: https://testflightapp.com/privacy/

On Wed, Sep 17, 2014 at 10:07 AM, Monte Hurd mh...@wikimedia.org wrote:

 In the last 2 days we went from 110 signups to 336!

 Of these, 143 people have actually installed the latest beta, up from a
 previous high of 20.

 I've also received multiple feedback emails through the testflight system.

 Dan, I've added you as a leader in testflight so hopefully these
 feedback emails will go to you as well. Is this ok?



 Other thoughts on where to forward feedback email? In the mean time,
 here's the feedback from yesterday:


 -


 I went to Article History and tried to click on an article Editor's name
 to see articles they have also edited, and this functionality is not yet
 there.

 I have no understandable way to Mark an article for watching (for web WP
 usage) - will this be implemented?

 I also do not see articles i am already watching from The web WP

 Are These saved for offline use articles somehow saved to web WP?

 I think the top-right article summary button could show The amount of
 languages The article is available in and allow to choose when 26 other
 languages is tapped, f.ex.

 Editing a segment of an article could allow for a toolbar above The
 editor, having The usual set of functionality or a subset of them (link
 with text, bold, list, reference generation)

 Tapping on this:
 ↑ a b Yle, uutiset viitat
 (Am referring to a and b) should modify Back-button functionality so that
 can get back to references by tapping on Back.
 Also, i am seeing hugely garbled text pasted now, see attached screenshot

 I.e. Would be nice to get a non-formatted copy-to-clipboard out of WP

 Share button on lower-right could have AirPrint? Hmm.

 I will attach two crashlogs that occurred while searching for a WP article
 in the next Mail.

 Sent from some iDevice. Written by Esa.


 


 Great update,

 Can i translate the app into arabic language ?

 Feras Younis Qrinawi


 


 Hey I have the TestFlight iOS 8 app how could I transfer the Wikipedia App
 inside the TestFlight App?


 


 Just from using this to view 2 articles, Infobox placement is a bit
 problematic. On an iPod 5, the page Carboxynorspermidine decarboxylase is
 split up by the Infobox; half the equation seems to be on either side of it.


 (Note: ^ this last one is from the previous beta)




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




-- 
Luis Villa
Deputy General Counsel
Wikimedia Foundation
415.839.6885 ext. 6810

*This message may be confidential or legally privileged. If you have
received it 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
https://meta.wikimedia.org/wiki/Wikimedia_Legal_Disclaimer.*
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Creating a shell app to house Wikidata games

[Luis Villa]

On Wed, Aug 13, 2014 at 11:51 AM, Maryana Pinchuk mpinc...@wikimedia.org
wrote:

 And that's just the Product/Design piece – in addition to implementing
 visual design/UI improvements, I imagine there would also be some technical
 hurdles like doing a spike around Magnus's codebase to ensure we didn't
 melt a game by sending (potentially) hundreds of thousands of people into
 it all at once; finding a way to hook into CentralAuth/OAuth to ensure
 these edits are attributed to logged-in users; etc.


I hate to chime in with a me too but a reminder that legal also has some
concerns around the TOU/CC here as well- how are they presented? when are
they agreed to? if we build a standard shell that many people can
use/experiment with, how do we make sure the fun/new/cool stuff maintains
the same licensing integrity people expect from the main website/existing
apps?

Nothing we can't resolve (and hopefully nothing we can't resolve quickly!)
but please do keep in mind as people are experimenting and thinking about
things.

Luis wet blanket Villa


-- 
Luis Villa
Deputy General Counsel
Wikimedia Foundation
415.839.6885 ext. 6810

*This message may be confidential or legally privileged. If you have
received it 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
https://meta.wikimedia.org/wiki/Wikimedia_Legal_Disclaimer.*
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Nearby

[Luis Villa]

On Sat, May 10, 2014 at 1:04 PM, Prateek Saxena psax...@wikimedia.orgwrote:

 On Sun, May 11, 2014 at 12:56 AM, Russell Nelson russnel...@gmail.com
 wrote:
  I just read the whole Nearby card. Why is OSM privacy situation is a
 bit of
  a mess?

 I don't know about legal stuff, CC'd Luis to clarify.


Specifically, they have no privacy policy for the OSM tileserver and
geocoding server, and they have no legal resources to improve things at
this time. Real improvements to the level we expect would probably also
require engineering resources, which are also scarce resources at this
point.

Under normal circumstances we'd engage with them to improve their terms-
we're required to negotiate with third-party providers by our new privacy
policy! But given the short timeline on our side and the scarce resources
on their side, and given that this is just a limited-deployment beta which
will run off our own servers when it is deployed at scale, it probably just
makes more sense to inform beta testers of the problem.

Hope that clarifies-
Luis


-- 
Luis Villa
Deputy General Counsel
Wikimedia Foundation
415.839.6885 ext. 6810

NOTICE: *This message may be confidential or legally privileged. If you
have received it 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.*
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Commons picture-of-the-day background changer for Android

[Luis Villa]

FYI that someone has written a plugin for Muzei (a popular minimalist
background switching app on Android) that switches your background among
random recent Commons Picture of the Days every few hours.

I've really enjoyed seeing a variety of beautiful Commons-y things on my
phone since I've started using it; so I thought I might share here.

Code:
https://github.com/ebraminio/WikimediaCommonsForMuzei

You can get it through F-Droid:
https://f-droid.org/repository/browse/?fdid=org.wikimedia.commons.muzei

Muzei, the parent app, which is really quite simple and beautiful itself- a
nice model in what a pleasant-to-use Android app can be:

https://play.google.com/store/apps/details?id=net.nurik.roman.muzei

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

Re: [WikimediaMobile] Wikimedia-mobile-copyrightwarning text

[Luis Villa]

On Sat, Feb 1, 2014 at 4:03 AM, Amir E. Aharoni 
amir.ahar...@mail.huji.ac.il wrote:

 Thanks a lot for this answer, Luis.

 I'm glad that you plan to make a through rewording of the legal strings.

To be clear, just of the ToU/CC-related stuff (at least for now) - i.e.,
the stuff you see when you edit.

 When you get around to it, please ask Language Engineering - we'd love to
 help making not only readable, but easier to translate as well.

I'm curious - what's the normal process for that in Foundation software?
i.e., whose responsibility is it, when is the best time to start thinking
about that, etc.? It is not something Legal has been involved in much in
the past, so I don't know much about the process (though I've been involved
with it for other open source projects for many years, so I am familiar
with many of the concepts).

Luis



 בתאריך 30 בינו 2014 21:51, מאת Luis Villa lvi...@wikimedia.org:


 On Thu, Jan 30, 2014 at 11:38 AM, James Alexander 
 jalexan...@wikimedia.org wrote:



 I'm not sure what to suggest.. IANAL either and no one else seems to
 be engaging in this conversation :-S
 Kenan / Juliusz (I think you follow this list) - might be worth you
 following up with legal and raising a bug if necessary? Or maybe Amir,
 you should raise a bug and we could get someone from legals' opinion/


 [Was not previously a list subscriber; have done that now. Thanks to
 James Alexander for bringing this to my attention.]

 Kenan and I (along with other members of product and design) have been
 looking at this language for a while to try to improve it. #1 on my list is
 definitely to say agree to irrevocably release instead of irrevocably
 agree to release. :) The legal meaning is essentially the same but the new
 wording would be clearer.

 That said, we're thinking about rewriting a lot of the copyright language
 stuff to make it more clear (and hopefully shorter to boot!) so it don't
 think it is a high priority to rewrite/revise this - it may be completely
 revised/reorganized in the next few months anyway.

 Hope that helps-
 Luis

 --
 Luis Villa
 Deputy General Counsel
 Wikimedia Foundation
 415.839.6885 ext. 6810

 NOTICE: *This message may be confidential or legally privileged. If you
 have received it 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.*




-- 
Luis Villa
Deputy General Counsel
Wikimedia Foundation
415.839.6885 ext. 6810

NOTICE: *This message may be confidential or legally privileged. If you
have received it 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.*
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Wikimedia-mobile-copyrightwarning text

[Luis Villa]

On Thu, Jan 30, 2014 at 11:38 AM, James Alexander
jalexan...@wikimedia.orgwrote:



 I'm not sure what to suggest.. IANAL either and no one else seems to
 be engaging in this conversation :-S
 Kenan / Juliusz (I think you follow this list) - might be worth you
 following up with legal and raising a bug if necessary? Or maybe Amir,
 you should raise a bug and we could get someone from legals' opinion/


[Was not previously a list subscriber; have done that now. Thanks to James
Alexander for bringing this to my attention.]

Kenan and I (along with other members of product and design) have been
looking at this language for a while to try to improve it. #1 on my list is
definitely to say agree to irrevocably release instead of irrevocably
agree to release. :) The legal meaning is essentially the same but the new
wording would be clearer.

That said, we're thinking about rewriting a lot of the copyright language
stuff to make it more clear (and hopefully shorter to boot!) so it don't
think it is a high priority to rewrite/revise this - it may be completely
revised/reorganized in the next few months anyway.

Hope that helps-
Luis

-- 
Luis Villa
Deputy General Counsel
Wikimedia Foundation
415.839.6885 ext. 6810

NOTICE: *This message may be confidential or legally privileged. If you
have received it 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.*
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l