for those who attended Wikimania, i hope you all had a wonderful time!
One of the things that i've talked about at Mania with a few people is
the current way of 'tool discovery', or rather, the lack thereof.
We've seen really cool things done by the community, but i have a
feeling many of the tools go by unnoticed, simply because nobody knows
that they exist. Maybe they've been send around here or posted on IRC,
but after the initial interest many of them are forgotten and lead a
lonely life on our virtual servers.
I think this is especially problematic for non-community members for
whom the tools might be very useful. For example, as a Wikipedian in
Residence and GLAM advocate i have sent numerous mails with links to
the various GLAM tools made by Magnus, stats.grok.se, etcetera.
But, you might say, we run all these knowledge sites called wikis
right? And there are some pages there that list tools, don't they?
You're right, the community has put some efforts in a few pages (1).
However, IMHO, a wiki doesn't lend itself to easy tool discovery:
* The format on how to describe a tool is unclear, thereby leading to
both very long and very short descriptions.
* It's not possible to easily search for tools in a certain category
(e.g. 'GLAM' or 'editcount').
* The categorization of tools leads to much clicking around,
distracting and confusing users.
* There's no way to sort results, for example by the number of people
using the tool.
The biggest problem of all is the disconnection between the actual
code of the tool itself (hosted in a Git repo), and the description
advertising it. People update their tool to do something different (or
deprecate it), but they forget the documentation on the wiki, don't
remove it when the tool doesn't work anymore, etcetera.
I believe we can, and should do better.
My proposal is to use the same mechanisms that already exist for
package managers such as NPM (2) or 'app stores', such as the Chrome
store (3). Basically this involes adding a small JSON file to your
project, including a few key properties such as 'title' and
'description'. These files get indexed, and an easy to use frontend to
search to all the tools is provided to end users. You could imagine a
'toolinfo.json' file to look something like this:
"name" : "WikiDataQuery",
"description" : "An API for Wikidata items and properties.",
"url" : "http://wdq.wmflabs.org/",
"keywords" : "wikidata, api, query",
"author" : "Magnus Manske"
If you have a web-hosted tool, simply stick it in the root of your
tools directory so that it's reachable by the crawler. Whenever your
tool data changes, just update the file and the directory will
automatically update the directory site.
The link to your toolinfo.json could be added to a Wiki page so that
it's easy to remove your tool from the directory or change the URL to
the JSON file.
I'm a firm believer in putting code where your mouth is, so i've
hacked up a working tool directory here:
Try searching for stuff, clicking on the labels. To add your own tool,
scroll the page down for instructions.
Current this only lists my tools, but i hope that this directory will
soon grow with everything the Wikimedia community has to offer.
I'm interested in your opinion in this proposal and, if you like it,
add a toolinfo.json to your project!
-- Hay / [[User:Husky]]
today adenia finally died - OS not found.
Fortunatelly all relevant data was already on the SAN so I could move the DBs completely to cassia. The host alias sql also points there.
user-store had to move as well and is now active on cassia, too.
It was an interruption of about 2,5h all together.
This regards very few users only but you should know since OSM and Merls tools were not accessible and are probably still broken if they dont use the hostname "sql" for the queries.