Another team at the foundation has published a list of code repositories
they manage and/or monitor, along with norms for reviewing code[1]. Should
Discovery create something similar?
[1]
https://www.mediawiki.org/wiki/Wikimedia_Language_engineering/Code_review_s…
Kevin Smith
Agile Coach, Wikimedia Foundation
Hello!
We’re pleased to announce that Jan Drewniak, a Discovery Department User
Experience Engineer, will be shifting to working on improving the user
interface and experience of search on desktop. He has been working
primarily on the wikipedia.org portal site.
What does this mean for the future of wikipedia.org?
Let’s first review what we’ve done so far, just in this quarter (July -
August 2016): Jan worked on internationalization and localization of the
portal so that it could be translated easily (including the sister project
descriptive texts via translatewiki <https://translatewiki.net/>), pushing
minor bug fixes and enhancements as well as updating the articles by
language statistics. In addition, Jan also helped design and code the new
portal page layout (based on several prior successful A/B tests and
community input) to production.
Jan will continue to maintain the portal by fixing bugs, adding minor
enhancements and performing regular statistics updates; which is expected
to take (on average) a couple of hours a week. Otherwise, we are not
planning to do any significant new work on the portal for the next couple
of quarters. As per the annual plan
<https://www.mediawiki.org/wiki/Wikimedia_Discovery#Wikipedia.org_portal>,
the Discovery Portal Team committed to continue to improve the wikipedia.org
page. We plan to resume that work in late Q3 and Q4 (March - July 2017).
What interface improvements will be made to search on desktop?
There’s been a lot of advances in search interfaces in Wikimedia in the
last few years. For example, the mobile apps, mobile web, wikipedia.org,
VisualEditor, and Flow now use imagery and short descriptions to enhance
findability. With Jan’s help, we expect to launch similar improvements on
desktop as a beta feature, to gather feedback and collect data. Jan will
also be working on tidying up the interface of our recent launch of search
language detection
<https://blog.wikimedia.org/2016/07/27/wikipedia-language-search/> to make
it more clear to searchers what’s happening.
Thank you! If you have any questions, please let us know.
Katie Horn, Director, Discovery
Dan Garry, Lead Product Manager, Discovery
David and I had a discussion about moving ascii-folding to come before
stemming on English Wikipedia. It seemed like a good idea, but we decided
we should run some tests before implementing it, just to be sure.
Turns out it is a good idea!
Much more detail:
https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Re-Ordering_Stemming…
We won't deploy it until we deploy BM25 later in the year, since it
requires a full re-index of English Wikipedia, as does BM25. That's
something we should only do once.
—Trey
Trey Jones
Software Engineer, Discovery
Wikimedia Foundation
Forwarding from the wikidata list. If you wish to reply, please do so there.
Awesome tools built on top of the Wikidata Query Service!
Dan
---------- Forwarded message ----------
From: Navino Evans <navino(a)histropedia.com>
Date: 10 August 2016 at 12:49
Subject: [Wikidata] Render sparql queries using the Histropedia timeline
engine
To: "Discussion list for the Wikidata project." <
wikidata(a)lists.wikimedia.org>
Hi all,
At long last, we’re delighted to announce you can now render sparql queries
using the Histropedia timeline engine \o/
Histropedia WikidataQuery Viewer
<http://histropedia.com/showcase/wikidata-viewer.html>
Unlike the main Histropedia site this tool renders timelines with data
directly from live Wikidata queries. It lets you map query variables to
values used to render the timeline. A few notable extra features compared
with the built in timeline view on the Wikidata query service:
*Precision* - You can render each event according to the precision of the
date (as long as you add date precision to your query). It will default to
day precision if you leave this out.
*Rank *– The events on the timeline have a rank defined by the order of
your sparql query results. You can also choose a query variable to use for
rank, but it’s not really needed if you use ORDER BY in your query to
control the order of results. Higher ranked events are placed more
prominently on the timeline.
*URL* – You can choose whichever URL you like from your query results,
which will be opened in a new tab when you double click on an event on the
timeline.
*Automatic colour code / filter* – You can choose any variable in your
sparql query to use for colour coding and filtering. From what I could tell
from the preview, this seems to be the same as the new map layers feature
that is close to launch on the Wikidata Query service (which looks awesome
by the way!)
Also similar to the ‘group by property’ feature on Magnus’ Listeria tool,
but using an arbitrary variable from the sparql results instead of a
Wikidata property.
*Some cool examples:*
Note: click on the droplet icon (top right) to see the colour code key and
filter options
- Discoveries about planetary systems, colour coded by type of object
<http://tinyurl.com/zlqupz9> (only items with an image and discoverer)
- Who's birthday is today? colour coded by country of citizenship
<http://tinyurl.com/hla7nqb>
- Oil paintings at the Louvre, colour coded by creator
<http://tinyurl.com/zu7cygv>
- Descendants of Alfred the Great, colour coded by religion, in Japanese
<http://tinyurl.com/h75utbg> – Note: select ‘no value’ in the filter
panel for a fun edit list of people missing religion statement :)
More examples on a dropdown list from the query input page
<http://www.histropedia.com/showcase/wikidata-viewer.html> in the tool.
The tool has been created by myself and fellow Histropedia co-founder Sean
using our newly released JavaScript library. We are only just learning to
code, and it’s a very early stage app so please let me know if anything
breaks!
You can find more info on the JS library (called HistropediaJS) on this
announcement from the Histropedia mailing list
<https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/…>
Cheers!
Navino
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
--
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
As of last night:
#discovery-analysis-backlog is now simply #discovery-analysis[1]
#discovery-analysis-sprint is now a milestone within #discovery-analysis,
and will (often) be displayed as "Discovery-Analysis (Current work)" [2].
That means it also appears as a column within #discovery-analysis.
The names could still change slightly, depending on the preferences of the
analysis team.
[1] https://phabricator.wikimedia.org/project/view/1850/
[2] https://phabricator.wikimedia.org/project/view/1241/
Kevin Smith
Agile Coach, Wikimedia Foundation
Awesome! Thanks for the heads up. I'll look out for the latest alpha build
after it's merged.
Dan
On 8 August 2016 at 15:39, Corey Floyd <cfloyd(a)wikimedia.org> wrote:
> Just a heads up to Discovery that the Android team has started development
> of the UI for the new and improved GeoSearch API.
>
> https://phabricator.wikimedia.org/T142431
> https://gerrit.wikimedia.org/r/303703
>
> Since the Android app already has a map UI and the API is rather
> straight-forward, Dmitri was able to get this scheduled and up and running
> rather quickly.
>
>
> --
> Corey Floyd
> Software Engineer
> Reading / iOS
> Wikimedia Foundation
>
> _______________________________________________
> reading-wmf mailing list
> reading-wmf(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>
>
--
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
Hi Pax,
I believe that WMF Discovery is the team that is best suited to address
matters like this, so I am forwarding your email to the Discovery mailing
list.
Pine
On Aug 7, 2016 16:46, "Pax Ahimsa Gethen" <list-wikimedia(a)funcrunch.org>
wrote:
> In a recent thread about improving search, I posted a comment about a
> possible hazard of relying on Google to search Wikipedia.[1] I explained
> that Google had been displaying a text snippet from an outdated, disruptive
> revision of the Gender page.[2] Well, that error has now resurfaced, and at
> an editor's suggestion I posted to the Village Pump about it.[3] The
> initial response at VP was essentially "not our problem; go away" which was
> not exactly encouraging.
>
> I'm sorry but if a major search engine is erroneously telling people that
> Wikipedia is stating " There are only 2 genders. Male and Female", that is
> a cause of concern for me, and I want to know if or how this problem can be
> fixed. As I explained on the talk page and in the Village Pump, Google's
> cache of the actual page is up to date; it's just the snippet that is wrong.
>
> - Pax
>
> [1] https://lists.wikimedia.org/pipermail/wikimedia-l/2016-July/
> 084890.html
>
> [2] https://en.wikipedia.org/w/index.php?title=Gender&oldid=722247975
>
> [3] https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(techni
> cal)#Google_returning_outdated_text_snippet_for_Gender_page
>
> --
> Pax Ahimsa Gethen | http://funcrunch.org
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wik
> i/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>
*Stripping Question Marks From Wiki Searches*
*Do you ask questions on Wikipedia? Would you like better results?*
*Summary:* Because the large majority of question marks are used to ask
questions by users unfamiliar with bash-style wildcards
<https://en.wikipedia.org/wiki/Glob_(programming)>, the default behavior
for CirrusSearch will now be to ignore question marks (replacing them with
a space). Escaping them with a backslash (\?) will preserve their wildcard
meaning. Regular expressions in *insource:* will not be affected and should
not be escaped. This option can be modified on a per-wiki basis if needed
(see $wgCirrusSearchStripQuestionMarks
<https://github.com/wikimedia/mediawiki-extensions-CirrusSearch/blob/master/…>
).
When people ask *how old is tom cruise?* on Wikipedia they almost certainly
don’t expect the question mark in *cruise?* to match an additional letter.
They aren’t looking for the words *cruised, cruiser, * or *cruises—*but
that’s what they get, and it keeps them from finding the information they
are really after.
Search on Wikipedia (and other Wikimedia projects) includes a lot of
features that most users don’t know about. Most require special keywords,
and some even require specialized knowledge, such as familiarity with
regular expressions. It’s pretty difficult to invoke these special features
by accident.
But search also supports two particular bash-style wildcards without any
special syntax: *** will match any number of characters, and *?* will match
exactly one. Asterisks do come up from time to time, but people use
question marks all the time—because they like to ask questions!
A recent review of query-string features
<https://commons.wikimedia.org/wiki/File:From_Zero_to_Hero_-_Anticipating_Ze…>
called
out quotes and question marks as the two largest-impact predictors of
unsuccessful queries on Wikipedia. In a follow-up survey of queries with
question marks
<https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Dropping_Final_Quest…>
in
six of the top ten Wikipedias (by search volume), most question marks are
being used to ask questions (the other four of the top 10 were not
reviewed). In all ten of the top ten, stripping final question marks
dramatically decreased the number of ?-final queries that got either no
results, or very few results (i.e., less than 3). The improvement was
around 10-45% for ?-final queries, depending on the wiki. The overall
impact is much more modest (less than 0.5%) because queries with question
marks are not terribly common.
As a result of this analysis, we’ve implemented a change to search which
will by default replace question marks with spaces (to preserve the word
boundaries they intend in queries like *how?why?*). This setting can be
changed on a per-wiki basis, and other options include (i) only stripping
question marks at a clear word boundary (such as before a space), (ii) only
stripping question marks at the end of the query, and (iii) leaving the
question marks alone.
For the rarer users who do use question marks as a one-letter wildcard,
when question mark stripping is enabled, question marks can be escaped with
a backslash (e.g., *wiki\?edia*) to preserve their original wildcard
meaning. Power searchers who use *insource:* won’t need to do anything
special; queries with*insource:* will not be modified.
Here's a screenshot
<https://commons.wikimedia.org/wiki/File:Old-are_viruses_living%3F.png> of
the former question mark behavior, where it is treated as a wildcard.
Note that “living?” only matches the name “Livings”, leading to two very
unsatisfactory results.
Here's a screenshot
<https://commons.wikimedia.org/wiki/File:New-are_viruses_living%3F.png> of
the new question mark behavior, where it is ignored. Now the question
and part of the answer can be seen in the snippet for the very first
result, and all of the top three results seem relevant.
(Sorry I can't embed the screenshots—the mailing list won't allow messages
over 40K.)
Trey Jones
Software Engineer, Discovery
Wikimedia Foundation
