Discovery March 2016

discovery@lists.wikimedia.org

27 participants
58 discussions

Starting work on WDQS
by Guillaume Lederrey 18 Mar '16

18 Mar '16

Hello! Quick status (mainly for Tomasz). We took some time with Stas to go over what needs to be done on WDQS. Blazegraph seems robust enough and standard enough. I'll start playing around with it... The list of open points that I should address seems fairly thin. No upgrade planned in the short term, no specific maintenance, ... I can try to take care of incidents on the service, but it does not seems that there are many. In short: I should not have any problem starting to work on WDQS, but I'm not sure it will free all that much time from Stas... We'll see... MrG -- Guillaume Lederrey Operations Engineer, Discovery Wikimedia Foundation

2 1

Re: [discovery] [Wikimedia-l] Wikipedia.org portal page update!
by Deborah Tankersley 16 Mar '16

16 Mar '16

Hi Sam, We're glad you're using the Portal page more than usual and we hope that with upcoming future enhancements, you'll continue to enjoy it! For your first question - we are currently focusing on the wikipedia.org portal page at this time. We have no immediate plans to update the individual wiki's with this code but that doesn't mean that anyone in the community can't use our code to update another wiki to use the meta data and images as we did, in the search results. For your second question, we actually have a ticket <https://phabricator.wikimedia.org/T129627> open to look for input exactly like that. When a user types in a few words that are not in the language that has been previously selected, we're hoping to be able to switch to that "new" language on the fly. I agree that it'll be a very neat feature for us to have on the portal! Thanks for your input! Cheers, Deb -- Deb Tankersley Product Manager, Discovery Wikimedia Foundation On Tue, Mar 15, 2016 at 4:27 PM, Sam Klein <sjklein(a)hcs.harvard.edu> wrote: > I'm using the portal much more these days! Two thoughts, a few days in: > > = Is there a way to turn on thumbnailing on the individual language wikis > too? > > = Auto-suggesting language based on charset would be nice. when searching > in multiple languages I always forget once to switch to the target language > and end up getting search results for kanji on he.wp or for hebrew on ja.wp > > Thanks, SJ > > On Tue, Mar 15, 2016 at 4:25 AM, Michael Jahn <michael.jahn(a)wikimedia.de> > wrote: > > > I've played around a bit. Feels very cool! > > Michael > > > > 2016-03-11 3:27 GMT+01:00 Deborah Tankersley <dtankersley(a)wikimedia.org > >: > > > > > Hello! > > > > > > I'm very pleased to announce that we've updated the Wikipedia.org > > > <http://wikipedia.org/> portal page with a brand new search box that > is > > > more prominent and will now display meta data with images (as > available) > > in > > > the search results (see attached image). > > > > > > This was a large effort by the Discovery Portal team to develop a > > > JavaScript-only version of the language picker, so that JavaScript > > enabled > > > browsers will see all the new meta data. Alongside that effort, we also > > > ensured that in JavaScript (JS) disabled browsers (or older Internet > > > Explorer versions), our visitors won't have a bad experience when > > choosing > > > a language to search in. (Note: in older IE versions and JS disabled > > > browsers, the type-ahead and meta data search results information will > > not > > > be displayed.) > > > > > > We also implemented a shorter language code (ie: EN for English, ES for > > > Spanish, etc) to allow for more characters to be typed into the search > > box. > > > When a user toggles the language selector, the full language name will > be > > > displayed in the dropdown for easy finding of the language you prefer > to > > > search in. For the more technical minded - I've attached a screenshot > of > > > one of the ways we test our code, visually. > > > > > > We're interested in hearing your feedback or if you have any questions! > > > > > > On behalf of the very happy Wikipedia.org Portal Team, > > > > > > Deb > > > > > > -- > > > Deb Tankersley > > > Product Manager, Discovery > > > Wikimedia Foundation > > > _______________________________________________ > > > Wikimedia-l mailing list, guidelines at: > > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines > > > New messages to: Wikimedia-l(a)lists.wikimedia.org > > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> > > > > > > > > > > -- > > Leiter Kommunikation > > Head of Communications > > > > Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin > > Tel. (030) 219 158 260 > > > > http://wikimedia.de <http://www.wikimedia.de> > > > > Stellen Sie sich eine Welt vor, in der jeder Mensch freien Zugang zu der > > Gesamtheit des Wissens der Menschheit hat. Helfen Sie uns dabei! > > > > Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. > > Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg > unter > > der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für > > Körperschaften I Berlin, Steuernummer 27/029/42207. > > _______________________________________________ > > Wikimedia-l mailing list, guidelines at: > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines > > New messages to: Wikimedia-l(a)lists.wikimedia.org > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> > > > > > > -- > Samuel Klein @metasj w:user:sj +1 617 529 4266 > _______________________________________________ > Wikimedia-l mailing list, guidelines at: > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines > New messages to: Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> >

1 0

Investing in documentation
by Kevin Smith 15 Mar '16

15 Mar '16

In today's departmental weekly checkin, I asked if it might be worth spending more effort on documentation (e.g. TextCat). That brief discussion generated the following notes (which are already on wiki[1]): - Should we have a semi-formal policy about the importance of documentation? - Concerns about over-documenting (e.g. not agile) - Move this conversation to email - Dan is willing to prioritize phab tasks to write docs on specific topics - Chris can alert us if he is answering the same question multiple times (feature-level) - Multiple audiences (onboarding new staff, end-users on Wikimedia sites, end users on third party sites, other devs) For now, it seems that our immediate next steps could be to create a phab task whenever you notice (or are informed of) a shortcoming with our documentation. That task can be prioritized by whoever manages the workflow of the person/people who would do the documentation. If we end up in situations where documentation work ends up as eternal low priority, of if using phab proves unproductive, we can adapt and adjust. Feel free to continue the discussion here, if there are additional questions, concerns, or suggestions. [1] https://www.mediawiki.org/wiki/Wikimedia_Discovery/Checkin_meeting_minutes/… Kevin Smith Agile Coach, Wikimedia Foundation

1 0

Re: [discovery] Wiki maps news and updates
by Chris Koerner 15 Mar '16

15 Mar '16

Yuri, Great news! I'm glad to see the progress and look forward to helping work with the Wikivoyage and other map-loving communities. Not to be a pain, but shouldn't the IRC channel be #wikimedia-interactive ? :) -- Yours, Chris Koerner Community Liaison - Discovery Wikimedia Foundation

1 0

wikipedia portal browser support
by Jan Drewniak 15 Mar '16

15 Mar '16

Hi All, The portal team has had some discussions about what browsers we support on the wikipedia.org portal over the past week. Currently, our browser support is all over the map (in regards to IE anyway, almost literally any other browser release in the past 10 years works fine). - The typeahead suggestions work on IE6+ (but very slowly) - The baseline event logging works on IE6+ - A/B test event logging works on IE8+ (requires localStorage) - The JS language-picker works on IE9+ (requires CSS capabilities) - The upcoming A/B test (localized top-links) work on IE8+ (hasn't been test on lower versions) I think we should standardize on browser support. Currently our browser-usage from our dashboard <http://discovery.wmflabs.org/portal/#browser_breakdown> shows IE7 at ~ 1%, IE8 at ~1.5% IE9 at ~ 1% and IE6 isn't even on the map. Mediawiki, and by extension wikipedia.org, *has* browser compatibility standards, published here: https://www.mediawiki.org/wiki/Compatibility I think since the wikipedia portal is a gateway to the rest of wikipedia, it makes sense to follow the same guidelines as the rest of wikipedia. This would mean dropping JS support for IE8 and lower. We would still provide 'basic' support to IE8 and below, meaning the non-js version of the portal would still work for these browsers. This change would slightly change our dashboard metrics, but it would certainly speed-up our development time, allowing us to do more with our limited resources. Any objections or concerns with this approach? -Jan

4 3

Sharing my todo list
by Guillaume Lederrey 15 Mar '16

15 Mar '16

Hello! I'm trying to put some order into what I'm doing / want to do. If you have a few minutes to have a look (especially Dan) and let me know if I'm missing something big or if you have some idea on the priorities of all that... T124444 - Look into encrypting Elasticsearch traffic (in progress, *should* be done for codfw switchover) T128786 - improve robustness of es-tool (limitation were seen during elasticsearch 1.7.5 upgrade) T128000 - Refresh elastic10{01..16}.eqiad.wmnet servers (waiting for the hardware) T128616 - Remove hostname from elasticsearch log messages (minor point but shoudl improve visibility on logs) T128433 - Estimate hardware requirements for relevance lab elasticsearch servers (I'm mainly following, Erik is the brain on this one) T129254 - Put elasticsearch upgrade scripts under version control (small task, but should be done) T129256 - Implement proper orchestration mechanics for elasticsearch upgrade (we should at least investigate and see if we want to invest in better orchestration or not) I have a few more things in my head that are not clear enough yet to be written down. Feedback welcomed! MrG

3 5

Wiki maps news and updates
by Yuri Astrakhan 15 Mar '16

15 Mar '16

The quest to bring maps to Wikipedia continues: * Kartographer has launched for WikiVoyage * Julien Girault will help maps with his UI expertise * Talk to us at the FreeNode IRC channel #wikipedia-interactive https://www.mediawiki.org/wiki/Help:Kartographer Last week we enabled Kartographer extension for Wikivoyage sites, allowing users to add maps to wiki pages without any additional wmflabs and JavaScript tricks. Now you can simply add a <mapframe> or <maplink> to a wiki page, or even use the Visual Editor to insert a map. Additionally, you can: * add markers and polygons visually * edit geojson and see how it changes the map on each keystroke * add auto-numbered markers (either numbers or letters), and have multiple counters * have multiple "groups" of markers/polygons and showing them on the same map or on separate maps (e.g. all food and all drink maps and one combined map) * markers can be of any color, 3 sizes, and contain many different icons * markers and polygons can be clicked and will show popups with wiki text and images * very fast full screen popup map Feedback: https://www.mediawiki.org/wiki/Talk:Maps Bugs & TODOs: https://phabricator.wikimedia.org/tag/kartographer/ All maps-related tasks: https://phabricator.wikimedia.org/tag/maps/ == What's next? == There will be plenty of cleanup and polishing work to make Kartographer work seamlessly. We will need to address the missing functionality reported to us by the community, and help migrate existing wmflabs-based maps to the new platform. Lastly, VE editing will need some more work to become indispensable. Yet, our site is still set on the bigger target - maps for all of Wikipedia. For that we are waiting for more hardware, plus we will need to improve our static maps service to be able to handle wiki-load. Hardware task: https://phabricator.wikimedia.org/T125126 Thank you Max Semenik, Ed Sanders, Alex Kosiaris, Brandon Black, Chris Koerner, Chris Steipp, Tomasz Finc, and Wes Moran for making this possible.

1 0

Julien Girault supporting Maps team
by Moiz Syed 14 Mar '16

14 Mar '16

Hi all, Just a quick announcement that Julien will now be supporting Max and Yuri on the Maps team. I'm looking forward to all the great things the Maps team will build now with the additional help of Julien! Jan and Julien will still be reviewing each others code for the next little while. Quick announcement over :) Moiz

2 1

User searches for information about health crises
by Pine W 14 Mar '16

14 Mar '16

Food for thought: http://www.seattletimes.com/business/smartphone-voices-not-always-helpful-i… I wonder if Wikipedia search should have some enhanced capability to help people who perform searches like these. There may be ethical and legal limits to what Wikipedia should provide in the way of "medical advice", but I think if our search tool gets queries like the ones mentioned in that article, Wikipedia Search might suggest to people that they contact their local emergency services rather than try to do self-help via Wikipedia. Pine

1 0

Help with our hiera hierarchy
by Guillaume Lederrey 14 Mar '16

14 Mar '16

Hey! I'm probably missing something obvious, but there is something I do not understand about our hiera hierarchy as part of change 274711 [1]. What I am trying to achieve: 1) activate HTTPS for elastic search in both eqiad and codfw 2) not activate it for logstash (it would not hurt, but it does not seem like we need it at the moment) 3) define base::puppet::dns_alt_names for elasticsearch servers to 'search.svc.eqiad.wmnet' and 'search.svc.codfw.wmnet' respectively How I'm trying to achieve this: 1) Adding the property elasticsearch::https::ensure: 'present' in hieradata/role/common/elasticsearch/server.yaml 2) Adding the property elasticsearch::https::ensure: 'present' in hieradata/role/common/logstash/server.yaml 3) Adding the property base::puppet::dns_alt_names: 'search.svc.[codfw|eqiad].wmnet' in hieradata/role/[codfw|eqiad]/elasticsearch/server.yaml respectively. What makes me think it is not working: The excellent puppet-compiler gives me a view on the change catalog [6], [7] that tells me that * elasticsearch::https is ensured 'present' for both elasticsearch and logstash nodes * dns_alt_names is not defined for any node Anyone has a pointer on what I'm missing? Thanks! MrG [1] https://gerrit.wikimedia.org/r/#/c/274711/ [2] https://gerrit.wikimedia.org/r/#/c/274711/10/hieradata/role/common/elastics… [3] https://gerrit.wikimedia.org/r/#/c/274711/10/hieradata/role/common/logstash… [4] https://gerrit.wikimedia.org/r/#/c/274711/10/hieradata/role/codfw/elasticse… [5] https://gerrit.wikimedia.org/r/#/c/274711/10/hieradata/role/eqiad/elasticse… [6] http://puppet-compiler.wmflabs.org/2048/elastic1001.eqiad.wmnet/change.elas… [7] http://puppet-compiler.wmflabs.org/2048/logstash1001.eqiad.wmnet/change.log… --- Guillaume Lederrey Operations Engineer, Discovery Wikimedia Foundation

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Discovery March 2016