Re: [Wikitech-l] [Breaking Change] Scap change for deployers

[Legoktm]

Hi,

On 05/10/2016 10:08 AM, Tyler Cipriani wrote:
> Long story short, you will now run:
> 
> scap sync-file  [message]
> 
> Instead of:
> 
> sync-file  [message]
> 

Would it be possible to have tab completion for the new scap
subcommands? "mwv" → mwversionsinuse versus typing out all of "scap
wikiversions-inuse" ;) Same with "sync-f", etc.

It's not that huge of a deal, but I think we all use those commands
pretty frequently that tab completion saves a lot of keystrokes...

-- Legoktm

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

Re: [Wikitech-l] Getting rid of $wgWellFormedXml = false;

[Legoktm]

Hi,

On 05/02/2016 11:42 AM, Brian Wolff wrote:
> See gerrit patch https://gerrit.wikimedia.org/r/286495 I would
> appreciate everyone's feedback.

Given the lack of objections here and on Gerrit, I went ahead and merged
it today.

-- Legoktm

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

Re: [Wikitech-l] Proposal to invest in Phabricator Calendar

[Legoktm]

Hi,

On 05/13/2016 12:36 PM, Quim Gil wrote:
> The Technical Collaboration team has some budget that we could use to fund
> the Phabricator maintainers to prioritize some improvements in their
> Calendar. If you think this is a bad idea and/or you have a better one,
> please discuss in the task (preferred) or here. If you think this is a good
> idea, your reassuring feedback is welcome too.  ;)

If we're going to be investing money into improving Phabricator upstream
(a great idea IMO), I think we should start with problem areas that
affect a large number of users/developers. There's plenty of low-hanging
fruit like non-drag-n-drop file uploads[1]. [2] was also mentioned on
#wikimedia-tech a few days ago, or some of the UI/UX issues Nemo brought
up after the last Phabricator upgrade[3].

[1] https://phabricator.wikimedia.org/T165#2289766
[2] https://secure.phabricator.com/T10691#167705
[3] https://lists.wikimedia.org/pipermail/wikitech-l/2016-May/085489.html

-- Legoktm

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

[Wikitech-l] Reading planning for Q1 (from July to September)-- call for participation

[Moushira Elamrawy]

Hello Everyone,

Q1 Planning is coming soon.  Staff and community are invited to add their
ideas and suggestions for the work to be planned from the upcoming July
till September. Please add your ideas here:
https://www.mediawiki.org/wiki/Reading/Quarterly_planning/FY2016-2017/Q1

It is worth mentioning that this quarter, is most likely to be packed with
pending tasks, so there might not be much room for new ideas, but that
doesn't mean that we can always add and discuss

Happy weekend!
Moushira
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Reviving SVG client-side rendering task

[Gabriel Wicke]

Another option might be to piggy-back on the current work towards
lazy-loaded images [1]. Since this is using JS, it could take into
account network performance & screen resolutions, in addition to
browser capabilities. Designing this to degrade gracefully without JS
might be a bit tricky, though.

Gabriel

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

On Fri, May 13, 2016 at 3:29 PM, Bartosz Dziewoński  wrote:
> On 2016-05-13 22:28, Jon Robson wrote:
>>
>> The ResourceLoaderImage module is being used widely to generate SVG
>> icons with png fallbacks. I'd be interested in seeing if we can use
>> this in some way for optimising SVGs and removing meta data.
>
>
> I don't know what you have in mind, but please remember that
> ResourceLoaderImage was not written with security in mind. It has a very
> simplified version of our usual SVG rendering code, and it assumes that any
> SVG files passed to it is trusted. We traded some caution for some
> performance. Giving it user-controlled data is going to result in security
> vulnerabilities (at the very least some denial of service ones).
>
> --
> Bartosz Dziewoński
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Gabriel Wicke
Principal Engineer, Wikimedia Foundation

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

[Wikitech-l] Discovery Weekly Update for the week starting 2016-05-09

[Chris Koerner]

Hello,

Here is this week's update from the Discovery department.

* Closed out the latest A/B test for adding descriptive text [1] on the
Portal on May 10
* Started a short banner survey [2] on the wikipedia.org portal page on May
11
* Stalled on updating wikipedia.org portal [3] stats but hope to be
resolved soon (with DBA assistance)
* Created a testing dev workflow page [4] for wikipedia.org portal site A/B
testing
* Released Discernatron! [5]. You can help make search better by grading
search results.
* Presented geo boosted full text search [6], geo queries in WDQS [7], and
updates to mapping for wikivoyage [8] in the monthly CREDIT showcase [9].

[1] https://phabricator.wikimedia.org/T131238
[2] https://phabricator.wikimedia.org/T134512
[3] https://phabricator.wikimedia.org/T128546
[4]
https://www.mediawiki.org/wiki/Wikipedia.org_Portal_A/B_testing/dev_process
[5] https://discernatron.wmflabs.org/
[6] https://www.youtube.com/watch?v=GwTDDWjxoek=youtu.be=18m45s
[7] https://www.youtube.com/watch?v=GwTDDWjxoek=youtu.be=21m16s
[8] https://www.youtube.com/watch?v=GwTDDWjxoek=youtu.be=27m31s
[9] https://www.mediawiki.org/wiki/File:CREDIT_-_May_2016.webm



Feedback and suggestions on this weekly update are welcome!

The full update, and archive of past updates, can be found on Mediawiki.org:

https://www.mediawiki.org/wiki/Discovery/Status_updates

-- 
Yours,
Chris Koerner
Community Liaison - Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Insecure (non-HTTPS) API Requests to become unsupported starting 2016-06-12

[Brandon Black]

TL;DR:

* All access to Wikimedia production sites/APIs should use https://
URLs, not http:// -- your bot/tool will break in the near future if it
does not!
* 2016-06-12 - insecure access is unsupported; starting on this date
we plan to break (deny with 403) 10% of all insecure requests randomly
as a wake-up call.
* 2016-07-12 - we plan to break all insecure requests.


Hi all,

As you may remember, all production Wikimedia wikis switched to
HTTPS-only for all canonical domainnames nearly a year ago:
https://blog.wikimedia.org/2015/06/12/securing-wikimedia-sites-with-https/

Since way back then, we've been forcing insecure HTTP requests to our
canonical domains over to HTTPS by using redirects and
Strict-Transport-Security, which is effective for the vast majority of
access from humans using browsers and apps.

In the time since, we've been chasing down various corner-case issues
where loopholes may arise in our HTTPS standards and enforcement.  One
of the most-difficult loopholes to close has been the "Insecure POST"
loophole, which is discussed in our ticket system here:
https://phabricator.wikimedia.org/T105794 .

To briefly recap the "Insecure POST" issue:

* Most of our humans using browser UAs are not affected by it.  They
start out doing GET traffic to our sites, their GETs get redirected to
HTTPS if necessary, and then any POSTs issued by their browser use
protocol-relative URIs which are also HTTPS.
* However, many automated/code UAs (bots, tools, etc) access the APIs
using initial POST requests to hardcoded service URLs using HTTP
(rather than HTTPS).
* For all of the code/library UAs out there in the world, there is no
universally-compatible way to redirect them to HTTPS.  There are
different ways that work for some UAs, but many UAs used for APIs
don't handle redirects at all.
* Regardless of the above, even if we could reliably redirect POST
requests, that doesn't fix the security problem like it does with GET.
The private data has already been leaked in the initial insecure
request before we have a chance to redirect it.  If we did some kind
of redirect first, we'd still just be putting off the inevitable
future date where we have to go through a breaking transition to
secure the data.

Basically, we're left with no good way to upgrade these insecure
requests without breaking them.  The only way it gets fixed is if all
of our API clients in the world use explicit https:// URLs for
Wikimedia sites in all of their code and configuration, and the only
way we can really force them to do so is to break insecure POST
requests by returning a 403 error to tools that don't.

Back in July 2015, I began making some efforts to statistically sample
the User-Agent fields of clients doing "Insecure POST" and tracking
down the most-prominent offenders.  We were able to find and fix many
clients along the way since.

A few months ago Bryan Davis got us further when he committed a
MediaWiki core change to let our sites directly warn offending
clients.  I believe that went live on Jan 29th of this year (
https://gerrit.wikimedia.org/r/#/c/266958 ).  It allows insecure POSTs
to still succeed, but sends the clients a standard warning that says
"HTTP used when HTTPS was expected".

This actually broke some older clients that weren't prepared to handle
warnings at all, and caused several clients to upgrade.  We've been
logging offending UAs and accounts which trigger the warning via
EventLogging since then, but after the initial impact the rate
flattened out again; clients and/or users that didn't notice the
warning fairly quickly likely never will.

Many of the remaining UAs we see in logs are simply un-updated.  For
example, https://github.com/mwclient/mwclient switched to
HTTPS-by-default in 0.8.0, released in early January, but we're still
getting lots of insecure POST from older mwclient versions installed
out there in the world.  Even in cases where the code is up to date
and supports HTTPS properly, bot/tool configurations may still have
hardcoded http:// site config URLs.

We're basically out of "soft" ways to finish up this part of the HTTPS
transition, and we've stalled long enough on this.

** 2016-06-12 is the selected support cutoff date **

After this date, insecure HTTP POST requests to our sites are
officially unsupported.  This date is:

* A year to day after the public announcement that our sites are HTTPS only
* ~ 11 months after we began manually tracking down top offenders and
getting them fixed
* ~ 4 months after we began sending warning messages in the response
to all insecure POST requests to the MW APIs
* ~ 1 month after this email itself

On the support cutoff date, we’ll begin emitting a “403 Insecure POST
Forbidden - use HTTPS” failure for 10% of all insecure POST traffic
(randomly-selected).  Some clients will retry around this, and
hopefully the intermittent errors will raise awareness more-strongly
than the API warning message and this email did.

A month later (two months 

Re: [Wikitech-l] Reviving SVG client-side rendering task

[Bartosz Dziewoński]

On 2016-05-13 22:28, Jon Robson wrote:

The ResourceLoaderImage module is being used widely to generate SVG
icons with png fallbacks. I'd be interested in seeing if we can use
this in some way for optimising SVGs and removing meta data.


I don't know what you have in mind, but please remember that 
ResourceLoaderImage was not written with security in mind. It has a very 
simplified version of our usual SVG rendering code, and it assumes that 
any SVG files passed to it is trusted. We traded some caution for some 
performance. Giving it user-controlled data is going to result in 
security vulnerabilities (at the very least some denial of service ones).


--
Bartosz Dziewoński

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

[Wikitech-l] Mobile Content Service: naming of new endpoints for feeds

[Bernd Sitzmann]

We plan to add more RESTBase endpoints to support the new "Explore feeds"
feature in the apps. The currently proposed names are listed in [1]. It
introduces a new top-level hierarchy, called "project".

If you have issues with the current proposal or ideas to improve them
please comment on the Phab ticket by Thursday, May 19, 2016.

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

Thank you,
Bernd Sitzmann
Android app & Mobile Content Service
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Reviving SVG client-side rendering task

[Brion Vibber]

On Fri, May 13, 2016 at 1:28 PM, Jon Robson  wrote:

> Thanks for starting this conversation Brion!
>
> On mobile we are constantly tackling the trade offs between data
> shipped (cost for end user) and quality. Hopefully we'll have a better
> solution for this by the end of the quarter which will allow us to
> reconsider srcset usage.


Note that srcset usage for raster images is a different issue from native
SVG, in that the higher-resolution renderings *do* require more bandwidth
than the lower-resolution images -- especially for photos.


> That said relying on srcset to render SVGs
> well seems like a hack to me and thus I'd rather we fixed the problem
> at the source.
>

The problem is the intersection of:
* some older browsers do not support SVG in 
*  provides no system for automatic fallback based on the browser's
format support
*  does provide that, but the spec is not finalized, browser
support is not finalized, and it may have implications for scripting and
styling by introducing a new wrapper element

Using  with PNG in the src and a "1x" SVG in the srcset resolves the
first case by feeding a compatible rasterization to old browsers, solves
the second problem by using srcset support as a proxy check for SVG support
(native srcset support implies SVG support in all known cases), and avoids
the third problem by not using a new, different element for images.

We could jump straight to , but it'll have bigger QA implications
in that it may affect styling and JS gadgets that look for  elements
specifically.

 would be nice for other things though -- future support of WebP
for alternate, more bandwidth-efficient thumbnails, or if we start doing
fancier types of responsive images based on "art direction" usages where a
narrow column gets a different image than a wide window.



> A few thoughts
> * The ResourceLoaderImage module is being used widely to generate SVG
> icons with png fallbacks. I'd be interested in seeing if we can use
> this in some way for optimising SVGs and removing meta data.
>

Definitely yes! Just as we minify CSS and JS source, we should make sure
the SVG icons are efficiently packed as well. (There's usually good
opportunity to do that at commit time, but it's nice to be able to include
comments and such in the source.)



> * I wonder if there is an opportunity here to use BetaFeatures and
> mobile beta to get a sense of performance impact of these changes?
> This would allow people to opt in and for us to crowdsource feedback
> in a safe enviroment.
>

Yes, I am suggesting exactly that. :)

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

Re: [Wikitech-l] Reviving SVG client-side rendering task

[Jon Robson]

Thanks for starting this conversation Brion!

On mobile we are constantly tackling the trade offs between data
shipped (cost for end user) and quality. Hopefully we'll have a better
solution for this by the end of the quarter which will allow us to
reconsider srcset usage. That said relying on srcset to render SVGs
well seems like a hack to me and thus I'd rather we fixed the problem
at the source.

A few thoughts
* The ResourceLoaderImage module is being used widely to generate SVG
icons with png fallbacks. I'd be interested in seeing if we can use
this in some way for optimising SVGs and removing meta data.
* I wonder if there is an opportunity here to use BetaFeatures and
mobile beta to get a sense of performance impact of these changes?
This would allow people to opt in and for us to crowdsource feedback
in a safe enviroment.

Jon


On Wed, May 11, 2016 at 11:12 AM, Brion Vibber  wrote:
> On Wed, May 11, 2016 at 11:10 AM, Chris Steipp 
> wrote:
>
>> On Thu, May 5, 2016 at 6:49 AM, Brion Vibber 
>> wrote:
>>
>> >
>> > And then there are long term goals of taking more advantage of SVGs
>> dynamic
>> > nature -- making things animated or interactive. That's a much bigger
>> > question and has implementation and security issues!
>>
>>
>> Sorry for the late response (and if this is covered in one of the linked
>> bugs), but getting back to this-- are you envisioning SVG's inlined into
>> the html?
>
>
> Maybe someday that might be interesting for interactive bits, but not in
> the short term.
>
>
>> Or would they be served from a domain like upload.wm.o, like we
>> currently use for uploaded images?
>>
>
> Yes for now.
>
> -- brion
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Wikitech-l] Proposal to invest in Phabricator Calendar

[Quim Gil]

Annoyed by the difficulties of tracking events in the Wikimedia tech
community? Or by the difficulties of announcing events in an effective way?
Check this out:

Consolidate the many tech events calendars in Phabricator's calendar
https://phabricator.wikimedia.org/T1035

The hypothesis is that it is worth improving the current situation with
calendars in the Wikimedia tech community, and that Phabricator Calendar is
the best starting point. If we get a system that works for Wikimedia Tech,
I believe we can get a system that works for the rest of Wikimedia,
probably with some extra steps.

The Technical Collaboration team has some budget that we could use to fund
the Phabricator maintainers to prioritize some improvements in their
Calendar. If you think this is a bad idea and/or you have a better one,
please discuss in the task (preferred) or here. If you think this is a good
idea, your reassuring feedback is welcome too.  ;)

Thank you!

-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Best practice for WIP patches to help code review office hours

[Greg Grossmeier]

> Gerrit also has drafts...

Drafts are only visible to the author, unfortunately. But yes, that'd
work, but it's also fairly drastic. And people might not know about it
before they push ('git-review .') and then they can't (afaict) make
their change into a draft (per https://phabricator.wikimedia.org/T63124
).

Upstream docs:
https://gerrit-review.googlesource.com/Documentation/intro-user.html#drafts

I like the WIP status label better, personally :)

Greg

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

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

Re: [Wikitech-l] Best practice for WIP patches to help code review office hours

[Greg Grossmeier]

> .
> On 12 May 2016 4:18 p.m., "Stas Malyshev"  wrote:
> >
> > Hi!
> >
> > > No, -2 is restricted to project owners and thus not an op-
> > > tion for the vast majority of contributors.  For that pur-
> > > pose, I proposed a Gerrit label "WIP"
> > > (cf.
> http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/84068
> ).
> >
> > This looks like a nice solution.
> 
> Seconded. What's stopping us from adopting? It seems in that thread nothing
> happened.
> 
> Greg - is this something we can do?

Certainly.

"Adopting"? :) Making it official? I'd guess just setting the Gerrit
config to exposing the WIP label and then documenting it on mw.org,
maybe one of:
* https://www.mediawiki.org/wiki/Gerrit/Advanced_usage 
* https://www.mediawiki.org/wiki/Gerrit/Code_review (only focused on the
  review part, not the submission part, should it expand in scope?)
* https://www.mediawiki.org/wiki/Gerrit/Getting_started ? maybe too
  basic/focused to have this?
* Maybe a new page describing the stages of a change and how to start
  contributing? I think of this because of this
  task:https://phabricator.wikimedia.org/T73357 - "Add a welcome bot to
  Gerrit for first time contributors"

Task to track this for Gerrit I've created:
https://phabricator.wikimedia.org/T135245


(Below is just some documentation on how to do it that I wrote last
night...)

How to do it via the command line?

For Gerrit, use what was proposed in that last thread by Tim L:


> "C. Scott Ananian"  wrote:
> 
> > I'd use this tag more often if I could set it from the gerrit
> > command-line when I upload a patch.  Otherwise it will be pretty
> > inconvenient to keep this in sync with the summary line of my patch.
> 
> That should be possible with Gerrit's command line inter-
> face
> (cf.
> https://gerrit-review.googlesource.com/Documentation/cmd-review.html).
> For example, I just voted on
> https://gerrit.wikimedia.org/r/#/c/238201/ with:
> 
> | ssh -p 29418 gerrit.wikimedia.org gerrit review --label
> Code-Review=+1 4266a950bf7d0984cc5177b0f2f8d76b7d0b3c55
> 
> This /should/ work for arbitrary labels.

For those experimenting with Differential already it's even easier per
Mukunda:


> We definitely need consistency for any convention like this to be
> useful.
> Phabricator has the equivalent of self-2 in Differential:
> `arc diff --plan-changes`

From arcanist's help information:

greg@x230  ~ % arc help diff

  --plan-changes
Create or update a revision without requesting a
code review.


Which makes something like this:
https://secure.phabricator.com/D15906

Then that change does not show up in searches for Diffs needing review.
:)


Best,

Greg

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

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

Re: [Wikitech-l] Best practice for WIP patches to help code review office hours

[Addshore]

Gerrit also has drafts...

On 13 May 2016 at 01:56, Jon Robson  wrote:

> .
> On 12 May 2016 4:18 p.m., "Stas Malyshev"  wrote:
> >
> > Hi!
> >
> > > No, -2 is restricted to project owners and thus not an op-
> > > tion for the vast majority of contributors.  For that pur-
> > > pose, I proposed a Gerrit label "WIP"
> > > (cf.
>
> http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/84068
> ).
> >
> > This looks like a nice solution.
>
> Seconded. What's stopping us from adopting? It seems in that thread nothing
> happened.
>
> Greg - is this something we can do?
>
> >
> > --
> > Stas Malyshev
> > smalys...@wikimedia.org
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



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

Re: [Wikitech-l] [Engineering] 1.28.0-wmf.0 on hold for now

[Chad Horohoe]

On Fri, May 13, 2016 at 6:53 AM, Brad Jorsch (Anomie)  wrote:

> On Thu, May 12, 2016 at 7:33 PM, Erik Bernhardson <
> ebernhard...@wikimedia.org> wrote:
>
>> It looks like the train didn't roll forward today? I was going to swat
>> out a new test that depends on 1.28.0-wmf.1 but 1.27.0-wmf.23 still looks
>> to be running group2
>>
>
> For the record, it appears that group 2 was moved to 1.28.0-wmf.1 about an
> hour after Erik's message was sent.
>
>
Indeed. I rolled out group1 roughly during the window for group2. I waited
a few hours (until after afternoon swat) and rolled out group2.

1.28.0-wmf.1 is everywhere now.

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

Re: [Wikitech-l] [Engineering] 1.28.0-wmf.0 on hold for now

[Brad Jorsch (Anomie)]

On Thu, May 12, 2016 at 7:33 PM, Erik Bernhardson <
ebernhard...@wikimedia.org> wrote:

> It looks like the train didn't roll forward today? I was going to swat out
> a new test that depends on 1.28.0-wmf.1 but 1.27.0-wmf.23 still looks to be
> running group2
>

For the record, it appears that group 2 was moved to 1.28.0-wmf.1 about an
hour after Erik's message was sent.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Today's CREDIT showcase - video

[Sam Smith]

Thanks for taking the time to demo your projects y'all. Good work!

I'm particularly interested in Erik's geo boosted search queries and, as
was noted in his presentation, how it might be applied in the mobile
context.

-Sam

On Fri, May 13, 2016 at 2:34 AM, Adam Baso  wrote:

> Here's video from today's 12-May-2016 CREDIT showcase
> .
>
> https://www.youtube.com/watch?v=GwTDDWjxoek=youtu.be=7
>
> https://commons.wikimedia.org/wiki/File:CREDIT_-_May_2016.webm
>
> == Contents ==
>
> * Derk-Jan Hartman: Video.js progress
> * Dmitry Brant: Wikidata infoboxes in Android app
> * Joaquin Hernandez: Vicky chat bot
> * Baha: mobile printing for offline reading
> * Monte: "smart random" content service endpoint
> * Erik: Geo boosting search queries
> * Julien: Maps for Wikivoyage
>
> Thanks!
> -Adam
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l