Wikimedia-search

wikimedia-search@lists.wikimedia.org

1 participants
108 discussions

Phabricator process has been tweaked
by Kevin Smith 23 Jun '15

23 Jun '15

We have refined our use of our "sprint" projects, explicitly orienting them around people, not projects. The first step was that we renamed our Data-And-Research board to Analytics, reflecting that it is really all about Oliver's work. Then we moved data-related engineering work out of the Analytics-Sprint board, and into the Cirrus-Sprint board. The people doing this work are part of the Cirrus sub-team, so all of their work (Cirrus or not) now appears on a single board. At some point, we might rename the Cirrus-Sprint project to reflect this new nature, but we're leaving it for now. Short version: Every individual contributor on the team should be able to focus on just one workboard. If you are an engineer, you should no longer have to look for work on the Data or Analysis workboards. I have updated our process page[1] accordingly. [1] https://www.mediawiki.org/wiki/Discovery/Process Kevin Smith Agile Coach Wikimedia Foundation *Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*

2 1

Fwd: [Announcements] Elasticsearch 1.6.0 released
by Nikolas Everett 18 Jun '15

18 Jun '15

Hurray! Nik ---------- Forwarded message ---------- From: Clinton Gormley <noreply(a)discuss.elastic.co> Date: Tue, Jun 9, 2015 at 12:36 PM Subject: [Announcements] Elasticsearch 1.6.0 released To: nik9000(a)gmail.com Clinton_Gormley <http://discuss.elastic.co/users/clinton_gormley> June 9 Today, we are pleased to announce the release of Elasticsearch 1.6.0, based on Lucene 4.10.4. This is the latest stable version of Elasticsearch and is packed with awesome new features: - Faster restarts with synced flushing - Shard allocation no longer blocks pending tasks JSON response body filtering - Security fix for shared file-system repositories - Upgrade API for ancient indices - More lenient highlighting for Kibana users - mlockall for Windows users - Fine-grained script settings You can read more in the blog post: https://www.elastic.co/blog/elasticsearch-1-6-0-released ------------------------------ To respond, reply to this email or visit http://discuss.elastic.co/t/elasticsearch-1-6-0-released/2235/1 in your browser. To unsubscribe from these emails, visit your user preferences <http://discuss.elastic.co/my/preferences>.

2 1

Schema:Search
by Adam Baso 18 Jun '15

18 Jun '15

Hey all, looks like the new rev'd Schema:Search logging for desktop is in effect. Here are a couple queries suggesting that, at least on English Wikipedia for stable versions of Chrome most of the time people either click on an OpenSearch result from the set or dropdown results or press ENTER / click on the magnifying glass icon. > SELECT count(DISTINCT event_userSessionToken) FROM Search_12057910 WHERE timestamp > '20150614' AND timestamp < '20150615' AND (event_action = 'click-result' OR event_action = 'submit-form') AND wiki = 'enwiki' and userAgent LIKE '%Chrome/43%'; +----------------------------------------+ | count(DISTINCT event_userSessionToken) | +----------------------------------------+ | 1049 | +----------------------------------------+ 1 row in set (0.20 sec) > SELECT count(DISTINCT event_userSessionToken) FROM Search_12057910 WHERE timestamp > '20150614' AND timestamp < '20150615' AND wiki = 'enwiki' and userAgent LIKE '%Chrome/43%'; > SELECT count(DISTINCT event_userSessionToken) FROM Search_12057910 WHERE timestamp > '20150614' AND timestamp < '20150615' AND wiki = 'enwiki' and userAgent LIKE '%Chrome/43%'; +----------------------------------------+ | count(DISTINCT event_userSessionToken) | +----------------------------------------+ | 1100 | +----------------------------------------+

2 3

Concerns about production-like projects in labs
by Kevin Smith 17 Jun '15

17 Jun '15

In a recent meeting, Oliver expressed concerns about us having services running in labs which are treated sort of like they were in production. Examples include WDQS (already) and maps (potentially). We agreed to have this discussion on the mailing list, so this is an invitation to do so. I am not familiar enough with the various technical issues to explain them properly, so hopefully someone else will step in and do so. I believe one big area of concern is analytics. Kevin Smith Agile Coach Wikimedia Foundation *Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*

8 19

Maps tasks and phabricator
by Kevin Smith 09 Jun '15

09 Jun '15

Hello all, We will now be tracking our maps-related work in the Discovery-Maps-Sprint project[1], rather than the Maps project[2]. Maps will continue to exist, as a feature-centric list of tasks. However, it will not reflect the status of tasks (e.g. "In Progress" or "Needs Review"). That will be handled by Discovery-Maps-Sprint, along with the Maps column of the Discovery project[3]. In Maps, I have moved all the tasks into a single column, and have hidden the other columns, to avoid them accidentally being used. I have copied all the Maps tasks over to the Sprint board, into the appropriate columns. Note that the columns in Sprint are a bit different than they were in Maps, to align with other Sprint boards within the Discovery department. For details on how tasks are handled, see the Discovery department process page[4]. I will be requesting phab herald rules to automatically ensure that Maps tasks automatically get sync'd between these three related projects. Please let me know if you have any questions or concerns. [1] https://phabricator.wikimedia.org/tag/discovery-maps-sprint/ [2] https://phabricator.wikimedia.org/tag/maps/ [3] https://phabricator.wikimedia.org/tag/discovery/ [4] https://www.mediawiki.org/wiki/Search_and_Discovery/Process#Workflow_and_Ph… Kevin Smith Agile Coach Wikimedia Foundation *Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*

1 0

Elasticsearch 1.6 upgrade
by Nikolas Everett 06 Jun '15

06 Jun '15

I think Elasticsearch 1.6 is coming out soon. I can feel it in my bones. <https://github.com/elastic/elasticsearch/issues?q=is%3Aopen+is%3Aissue+labe…> I'm excited for it because it'll give a way to do Elasticsearch restarts more quickly (1 hour instead of 36). I filed https://phabricator.wikimedia.org/T101530 to enumerate the tasks for upgrading to it. I'm so excited by it that I sent this email. Nik

2 1

Getting the word out
by Federico Leva (Nemo) 03 Jun '15

03 Jun '15

It was nice to chat with many of you in Lyon! Wes mentioned that this mailing list will be used intensely, but I don't remember how I got to know about it. Starting from simple things, it will be good if * it's added to https://meta.wikimedia.org/wiki/Mailing_lists/Overview with a description of the usage you expect to make of it; * short notifications about it are sent to all relevant mailing lists (which you can find in the wiki list above once you know who you want to reach). Nemo

3 3

Predicting the load of EventLogging on Wikipedia Portal
by James Douglas 03 Jun '15

03 Jun '15

Does anyone know where I can find info about the current load on www.wikipedia.org? I'd like to set some reasonable sampling rates for the EventLogging instrumentation that's going to be in place soon. If the Portal gets a zillion hits per second, then 1/1000 of that is probably too high. On the other hand, if it gets five hits per day, then 1/1000 of that is rather too low.

2 2

New proposal for recurring meetings
by Kevin Smith 02 Jun '15

02 Jun '15

Based on input from the developers, Wes, and Dan, and others, here is a new proposal for a new slate of Search & Discovery vertical recurring meetings[1]. These changes really can't take full effect until the first week of June, due to the Hackathon and related travel. But hopefully we can agree on them now, and start to get them scheduled. After trying the new scheme out for a couple weeks, we'll have a retrospective so we can adjust as needed. The days-of-week proposed here are not set in stone, but they seemed logical. They came out of an attempt to stack meetings (as requested by Nik and others), combined with a sense that Monday and Friday are not ideal days for certain types of meetings, plus a recognition that finding huge blocks of time on our schedules may be challenging. Basically, if you are a developer, you'll have twice-weekly 15-minute sub-team standups, plus the weekly 25-minute full-vertical checkin. Every 2-4 weeks, you might be involved in a retrospective and/or showcase. That's a total of about 1 hour of meetings per week. Dan and I crave meetings[2], so we'll enjoy about 6.5 hours per week. The "leads" among you will have meeting loads somewhere in between those extremes. Any concerns? Violent outbursts? Purrs of contentment? [1] https://www.mediawiki.org/wiki/Search_and_Discovery/Process#Recurring_Meeti… [2] Not really, but we'll pretend we do Kevin Smith Agile Coach Wikimedia Foundation *Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*

5 4

wdqs beta updater performance data
by Stas Malyshev 02 Jun '15

02 Jun '15

Hi! Just in case anybody finds it interesting/useful, I've made a quick performance analysis on the update service we're running on wdqs-beta, in order to catch up with the wikidata updates: https://www.mediawiki.org/wiki/Wikibase/Indexing/Updater_performance_analys… May be useful for evaluation which hardware we may need if we want for updates to coexist with production loads. -- Stas Malyshev smalyshev(a)wikimedia.org

2 3

← Newer
1
...
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Wikimedia-search