Hello and welcome to the latest edition of the WMF Engineering Roadmap
and Deployment update.
The full log of planned deployments next week can be found at:
<https://wikitech.wikimedia.org/wiki/Deployments#Week_of_November_24th>
A quick list of notable items...
== All Week ==
* Firefox:
** Nov 25: Firefox 34 with default HTTPS search on Wikipedia (and
sometimes Wiktionary)
** <https://bugzilla.mozilla.org/show_bug.cgi?id=758857>
* HHVM:
** Nov 25: dissolve the distinction between HHVM and Zend appservers
and progressively move every appserver to HHVM
* Phabricator:
** November 21st - 24th: Phabricator Bugzilla migration
** <https://www.mediawiki.org/wiki/Phabricator#Migration_timeline>
* Fundraising tests throughout the week (on-going through the rest of
the yearly fundraising)
== Tuesday ==
* MediaWiki deploy
** group1 to 1.25wmf9: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** <https://www.mediawiki.org/wiki/MediaWiki_1.25/wmf9>
== Wednesday ==
* MediaWiki deploy
** group2 to 1.25wmf9 (all Wikipedias)
** group0 to 1.25wmf10 (test/test2/testwikidata/mediawiki)
== Thursday ==
* No deploys, US Holiday (Thanksgiving)
Thanks and as always, questions and comments welcome,
Greg
--
Greg Grossmeier
Release Team Manager
On Mon, Nov 17, 2014 at 10:20 PM, Tim Starling <tstarling(a)wikimedia.org> wrote:
> In the next RFC meeting we would like to discuss the following RFC:
>
> * Text extraction
> <https://www.mediawiki.org/wiki/Requests_for_comment/Text_extraction>
>
> The meeting will be on the IRC channel #wikimedia-office on
> irc.freenode.org at the following time:
>
> * UTC: Wednesday 21:00
> * US PST: Wednesday 13:00
> * Europe CET: Wednesday 22:00
> * Australia AEDT: Thursday 08:00
>
> Please note that the time has changed. It is an hour earlier so that
> it will be easier for people in Europe to attend.
We (collectively) need to get a lot better about not merely signaling
what is coming up, but what the results of these decisions are. If
you look here:
https://www.mediawiki.org/wiki/Architecture_meetings
...you could be forgiven for thinking the RFC meetings are something
we do anymore. Basically, you have to be subscribed to this mailing
list, and then, if you miss the time, fish through the logs here:
https://tools.wmflabs.org/meetbot/wikimedia-office/2014/
...and hope that some glitch hasn't wiped out the logs, since I don't
think there are any service level expectations for those logs.
I send this mail not to beat up on the Architecture Committee, but in
the hopes that we can find some wikignome volunteers to help out. To
the extent that it's not realistic to duplicate mailing list
announcements to mediawiki.org, we should probably just say "join
wikitech-l to receive announcements on meeting timing", and generally,
if we need to teach people how to fish rather than serving them
beautifully-plated caviar, let's actually say we're doing that rather
than setting up the expectation that they'll be able to wait for
someone to post something on the wiki.
Anyone willing to chip in?
Rob
[Redirecting conversation about TemplateData to wikitech-l; wikitext-l is
for parser and Parsoid discussion.]
On 6 November 2014 22:56, Andre Klapper <aklapper(a)wikimedia.org> wrote:
> Could there be any Template(Data) related tasks that could be worked on
> by Google Code-In students? For example something like "Fix five
> Templates from the list at XXXX by doing YYYY"?
>
> I'm happy to help setting up such tasks if somebody volunteers to mentor
> (more than one mentor means less work for everybody) and if somebody
> could add some boilerplate text at
>
> https://www.mediawiki.org/wiki/Google_Code-in_2014#Common_instructions_for_…
It's possible, though writing TemplateData needs a reasonably strong grasp
of the local community's expectations about template usage and all of the
complexities that goes with that. CC'ed to Elitre and WhatamIdoing in case
they might be interested in mentoring.
J.
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
Hi everyone,
We have two new people starting this week in Platform Engineering.
James Douglas
James started yesterday as the second member of our newly formed
Services group. "Services" in this context are standalone software
components that often run on their own machines and have very specific
jobs, such as "generate a PDF from this article". Much of our
infrastructure isn't that specific, so you'll hear us talking a lot
over the next year about moving toward "Service Oriented
Architecture", which basically means taking our general purpose
software and breaking it up into more focused components. James
working closely with Gabriel Wicke on bringing new services online,
such as RESTbase[1].
James comes to us from Versal, an organization he co-founded, and
where he was responsible for building out a Scala-based online
education platform. He lives here in San Francisco, and he'll be
sitting beside Gabriel on the south end of 3. You can find a wealth of
writings about his work with Scala as well as other software
development topics on James' personal website[2].
Stas Malyshev
Stas joins us from SugarCRM, where he was Software Architect since
2010. Prior to working at Sugar, Stas worked at Zend (makers of PHP),
where he was employee #1, and build the first version of their
website. In debugging problems on the website, he eventually got
slurped into fixing bugs and eventually doing much more with the PHP
runtime itself. If you're a php developer (or maybe even if you're
not), you should be following Stas's blog[3] where he talks about many
issues in PHP development.
Stas will be working in the MediaWiki Core team, mostly focused on
performance issues (though right now is getting up to speed on the
Wikidata Query Service[4], figuring out what we need to do to make it
suitable for widespread deployment of WikiGrok[5]). Stas lives in San
Jose, and will be working mostly remotely, but will be coming up to
the office about once a week. When he's here (like today) he'll be on
3rd floor south.
Welcome James and Stas!
Rob
1. https://github.com/gwicke/restbase
2. http://earldouglas.com/
3. http://php100.wordpress.com/
4. https://wdq.wmflabs.org/
5. http://www.mediawiki.org/wiki/Extension:MobileFrontend/WikiGrok
Are you good in swearing? WE NEED YOU
Huggle 3 comes with vandalism-prediction as it is precaching the diffs
even before they are enqueued including their contents. Each edit has
so called "score" which is a numerical value that if higher, the edit
is more likely a vandalism.
If you want to help us improve this feature, it is necessary to define
a "score words" list for every wiki where huggle is about to be used,
for example on English wiki.
Each list has following syntax:
(see https://en.wikipedia.org/w/index.php?title=Wikipedia:Huggle/Config&diff=573…)
score-words(score):
list of words separated by comma, can contain newlines but comma
must be present
example
score-words(200):
these, are, some, words, which, presence, of, increases, the, score,
each, word, by, 200,
So, if you know english better than me, which you likely do, go ahead
and improve the configuration file there, no worries, huggle's config
parser is very syntax-error proof.
If you have any other suggestion how to improve huggle's prediction,
go ahead and tell us!
In the next RFC meeting we would like to discuss the following RFC:
* Text extraction
<https://www.mediawiki.org/wiki/Requests_for_comment/Text_extraction>
The meeting will be on the IRC channel #wikimedia-office on
irc.freenode.org at the following time:
* UTC: Wednesday 21:00
* US PST: Wednesday 13:00
* Europe CET: Wednesday 22:00
* Australia AEDT: Thursday 08:00
Please note that the time has changed. It is an hour earlier so that
it will be easier for people in Europe to attend.
-- Tim Starling
I have noticed that there are a lot of pages which are extremely well
developed in one language and not particularly well developed in other
languages. I have been thinking about making tools to help identify and
translate these articles. What tools and approaches have been developed to
address this problem already? Have there been any projects to this effect?
Regards,
Chas
What URL can I use to search across all languages of Wikipedia (or a sister project)? Would like to add it as a search engine so that I don't have to constantly switch between 2-3 language different search engines in the list.