Google Code-in 2015 has come to an end.
Thanks to our students for resolving 461 Wikimedia tasks. Thanks to our
35 mentors for being available, also on weekends & holidays. Thanks to
everybody on IRC for your friendliness, patience, and help provided to
new contributors.
Some more achievements, apart from those already mentioned in
https://lists.wikimedia.org/pipermail/wikitech-l/2015-December/084421.html :
* The CommonsMetadata extension parses vcards in the src field
* The MediaWiki core API exposes "actual watchers" as in "action=info"
* MediaWiki image thumbnails are interlaced whenever possible
* Kiwix is installable/moveable to the SD card, automatically opens
the virtual keyboard for "find in page", (re)starts with the last
open article
* imageinfo queries in MultimediaViewer are cached
* Twinkle's set of article maintenance tags was audited and its XFD
module has preview functionality
* The RandomRootPage extension got merged into MediaWiki core
* One can remove items from Gather collections
* A new MediaWiki maintenance script imports content from text files
* Pywikibot has action=mergehistory support implemented
* Huggle makes a tone when someone writes something
* Many i18n issues fixed and strings improved
* Namespace aliases added to MediaWiki's export dumps
* The Translate extension is compatible with PHP 7
The Grand Prize winners & finalists will be announced on February 8th.
Again congratulations everybody, and thanks for the hard work.
See you around on IRC, mailing lists, Gerrit, and Phabricator!
Cheers,
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
---------- Forwarded message ----------
From: Kevin Leduc <kevin(a)wikimedia.org>
Date: Tue, Feb 2, 2016 at 4:22 PM
Subject: February 2016 Lightning Talks
To: "Staff (All)" <wmfall(a)lists.wikimedia.org>
Hi All,
The next Lightning Talks are scheduled for February 16th (two weeks from
today). We hope at least 4 people will sign up for the talks by Friday
February 12th otherwise we will postpone them another month. Lightning
Talks are an opportunity for teams @ WMF & in the Community to showcase
something they have achieved: a quarterly goal, milestone, release, or
anything of significance to the rest of the foundation and the movement as
a whole.
Each presentation will be 10 minutes or less including time for questions.
Sign up here: https://www.mediawiki.org/wiki/Lightning_Talks#February_2016
Next round of Lightning Talks:
When: Tuesday February 16, 1900 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Lightning+Talks&is…>,
11am PST (We have added this Lightning Talk to the WMF Engineering, Fun &
Learning, and Staff calendars)
Where: 5th Floor
Remotees: On-Air google hangout will be provided just before the meeting
IRC: #wikimedia-tech
YouTube stream: http://www.youtube.com/watch?v=D3fyCgBWvFc
Thanks!
Kevin Leduc, Megan Neisler, Brendan Campbell
The Winter break took longer than expected. Busy times!
You can help develop the next summary.
*Developer Relations focus*
* Wrapping up Google Code-in 2015
* Wikimedia Hackathon 2016 travel sponsorship requests
* Wikimedia Developer Summit 2016/Lessons Learned
* Developer Relations strategy and annual plan
There is a lot more at
https://www.mediawiki.org/wiki/Developer_Relations/Weekly_summary#2016-01-26
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Cool. Forwarding this email.
Pine
On Tue, Feb 2, 2016 at 10:30 AM, Jonathan Morgan <jmorgan(a)wikimedia.org>
wrote:
> Yesterday, 2013 IEG grantee Jeph Paul started seeing 1000s of hits on his
> (grant-funded, volunteer-maintained) ReplayEdits tool which visually
> replays edit histories of Wikipedia articles.
>
> Here's why:
>
> http://www.nytimes.com/2016/02/02/us/politics/wikipedia-donald-trump-2016-e…
> (the tool <https://cosmiclattes.github.io/wikireplay/player.html> is
> linked from one of the last few paragraphs in the article)
>
> The article itself is not exceptional. It's just cool to see one of our
> locally grown research prototypes get good press.
>
> Jonathan
>
> --
> Jonathan T. Morgan
> Senior Design Researcher
> Wikimedia Foundation
> User:Jmorgan (WMF) <https://meta.wikimedia.org/wiki/User:Jmorgan_(WMF)>
>
>
> _______________________________________________
> Wiki-research-l mailing list
> Wiki-research-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
>
>
I've been working on a little redesign project for the Main Page on
wikitech [0] and three key sub pages it points to since 2016-01-01 in
my User space. Tonight I decided that although it is far from perfect
it is better enough. I hope that some of you like it better than the
old page and that none of you hate it with a fiery passion that
compels you to revert it rather than helping me make it better.
[0]: https://wikitech.wikimedia.org/wiki/Main_Page
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
irc: bd808 v:415.839.6885 x6855
I am pleased to announce that Guillaume Lederrey joins WMF this week
as Operation Engineer in the Discovery team. Guillaume will work
closely with our operations team to support Elastic Search, Maps, and
WDQS along with strengthening our experience with Java based services.
Guillaume will be working remotely from Lausanne (Switzerland) where
he lives with his 4 month old son and his mother. Guillaume has
previous experience with non profits, having worked for a year in
Rwanda for an NGO. Working to make the world a better place is what
motivates him to join WMF.
For the last 5 years, Guillaume has been working for Nespresso, taking
care of all things from performance and stability of the e-commerce
and backend stacks, challenging agile practices and introducing Puppet
as the main configuration tool to managing build tools, improving
automated code quality and bringing coffee to his coworkers.
On his free time, Guillaume is the maintainer of JmxTrans [1], the
missing piece to monitor JVM based applications.
Guillaume can be found on IRC under the nickname 'gehel'.
Please join me in welcoming him!
--tomasz
[1]: https://github.com/jmxtrans/jmxtrans
Hello everyone,
The public Parsoid endpoint http://parsoid-lb.eqiad.wikimedia.org is
being decommissioned [1] once we migrate over all straggler references
to that endpoint [1] possibly as soon as 3 weeks from now.
As far as we know, there are very few requests to that endpoint right
now, but if you have been using that endpoint, please switch over to
using the RESTbase service instead. You can access Parsoid HTML for the
wikimedia wikis via their REST API endpoint. For example,
https://en.wikipedia.org/api/rest_v1/?doc is the REST API url for
English Wikipedia content.
Thanks,
Subbu.
1. https://phabricator.wikimedia.org/T110474
Hi Luigi,
On Fri, Jan 29, 2016 at 12:31 PM, Luigi Assom <itsawesome.yes(a)gmail.com> wrote:
> - how to extract _ID from ETag in headers:
> GET /page/title/{title}
the page id is indeed not directly exposed in the HTML response.
However, the revision number is exposed as part of the ETag. This can
then be used to request revision metadata including the page id at
https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_revision_….
This is admittedly not very convenient, so I created
https://phabricator.wikimedia.org/T125453 for generally improved page
id support in the REST API.
> - how to ensure
> GET /page/title/{title with different char encoding or old titles are always
> resolved to last canonical version}
The storage backing this end point is automatically kept up to date
with edits and dependency changes. Edits in particular should be
reflected within a few seconds.
>> If you refer to
>>
>> https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_graph_png…,
>> this is an end point exposing rendered graph images for
>> https://www.mediawiki.org/wiki/Extension:Graph (as linked in the end
>> point documentation).
>
>
> Oh very interesting!
> So basically html markup can be extended ?
> Would it be possible to share json objects as html5 markup and embed them in
> wiki pages?
The graph extension is using the regular MediaWiki tag extension
mechanism: https://www.mediawiki.org/wiki/Manual:Tag_extensions
Graphs are indeed defined using JSON within this tag.
> I want to avoid to update my graph just because titles changes: entities are
> always the same.
Makes sense. The current API is optimized for the common case of
access by title, but we will consider adding access by page ID as
well.
> I still don't know what parsoid is.
Parsoid is the service providing semantic HTML and a bi-directional
conversion between that & wikitext:
https://www.mediawiki.org/wiki/Parsoid
Gabriel
Hello,
As you know we had to rollback 1.27-wmf.11 a few times in the last two
weeks due to issues in the new SessionManager code base. The last time
was this weekend (Saturday) and thus right now (Monday Feb 1st and 18:00
UTC) Wikimedia production is running only[0] wmf.10.
After discussions with Brad (Anomie), Bryan (bd808), Dan (marxarelli),
Antoine (hashar), and myself we decided on this plan moving forward:
1) Stay at wmf.10 everywhere today/Mon Feb 1st
2) Brad/Bryan prepare master *without* SessionManager
3) Brad to prepare session invalidation improvement (speed up the
invalidation process)
4) Tomorrow/Tuesday Feb 2nd: cut wmf.12 (without SessionManager)
5) Roll wmf.12 as normal this week (ie: skip wmf.11 entirely)
6) Rest of week: Brad and Bryan to get some more end-to-end tests
running with Dan
7) Next week: Hopefully get SessionManager back into wmf.13 (with
session invalidation improvement incorporated)
Apologies to all for the issues we've been having and apologies to
Bryan, Brad, and Gergo for delaying the rollout of SessionManager (and
probably AuthManager). I think this is the best solution we have right
now given the situation.
Best,
Greg
[0] If you care about relatively tiny details, the mw1017 appserver is
running wmf.11, but the only users that get that server set a special
debug header. This is for the team to test/debug what they can.
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Within the next few weeks, I'll be deploying VisualEditor for 1000+ authors here at Cimpress/Vistaprint, in a wiki with 225,000 articles.
I plan to collect feedback from our users on what works and what doesn't. What would be the best way to communicate this feedback to Wikimedia?
Here are some early, informal comments from our pilot group of 20 users:
"I am in love!"
"TemplateData integration is awesome."
"How do I insert <code> tags?" (He didn't notice the "More" link in the font menu.)
"How do I set the width of a table column?"
"How do I copy and paste table rows?"
"Editing links is fiddly" (https://phabricator.wikimedia.org/T124305)
"I didn't see the editing tools at first because they're white on a white background."
"Can we save the page without having a pop-up?"
Thanks,
DanB