Hello folks,
we have 12 open positions in Wikimedia engineering right now, and a
few more will go up in coming weeks. If you have connections, we'd
appreciate your help hiring for these roles, forwarding this note to
appropriate listservs, tweeting it, etc.
The full listing is at
http://wikimediafoundation.org/wiki/Job_openings , but here are some
key roles that we need help with:
1) Product Managers: We're looking for great people to act as product
owners for three very important initiatives:
- New editor engagement: helping Wikimedia to attract, nurture and
retain new contributors.
- Analytics: supporting the development of systems and tools for
measuring our impact.
- Mobile: helping us reach hundreds of millions of people on mobile
devices and engaging hundreds of thousands of them to contribute in
useful ways.
The product manager role at WMF entails grooming and prioritizing the
product backlog, engaging with the Wikimedia community, commissioning
and organizing research, hands-on testing, but also helping with
across-the-board priorities triage for ongoing product development.
These folks don't have to be product managers by trade, but they need
to be comfortable negotiating compromise while holding the product
vision. They need to treat engineers as equal partners, and be
excellent communicators. Ideally they have strong domain expertise
relevant to their focus area.
We have two of these currently posted:
http://wikimediafoundation.org/wiki/Job_openings/Product_Manager_(Features)http://wikimediafoundation.org/wiki/Job_openings/Product_Manager_(Analytics)
The mobile one will go up soon, and we'll refine the definition
further. But please use these as reference points for now.
2) Analytics Engineers: We're hiring for two systems engineers to
build out our analytics infrastructure. What exists so far is still
fairly rudimentary, so we need to build scalable logging and tracking
systems for various purposes, e.g.
- geographic breakdown of access and editing activity
- usage data for specific features; A/B testing of features
- search activity, real-time editor retention measures, new activity
visualizations, and more ..
The ideal candidate here likely is someone who's very strong building
out large scale distributed systems, and has experience with NoSQL
technologies, distributed computing, etc.
The relevant JD is here:
http://wikimediafoundation.org/wiki/Job_openings/Systems_Engineer_-_Data_An…
3) A strong QA Lead who can help us write and perform test plans with
shoestring and duct tape, i.e. using a combination of test automation,
work with outside vendors, and volunteer-driven testing to strengthen
our product quality. The relevant JD is here:
http://wikimediafoundation.org/wiki/Job_openings/QA_Lead
4) Strong frontend and backend engineers: for features development,
code review, deployment and release management support, and so forth.
Demonstrable open source experience is always a major plus, and while
PHP is learnable, not being predisposed against it helps. :-)
http://wikimediafoundation.org/wiki/Job_openings/Software_Developer_Fronten…http://wikimediafoundation.org/wiki/Job_openings/Software_Developer_Backend…
Your outreach and support is always appreciated.
All best,
Erik
--
Erik Möller
Deputy Director, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
We'll be holding a public IRC bug triage in about 2-3 minutes on
#wikimedia-dev for all who are interested. We will be using
http://etherpad.wikimedia.org/BugTriage-2011-06 to keep notes as well.
See you there!
Mark.
I'm not sure who would be in charge of this, but I think it would be
useful if the WMF was a liaison member of the Unicode Constortium:
http://unicode.org/consortium/memblogo.html
This body makes all sorts of important decisions about the Unicode
standard—decisions that affects many aspects of our projects. If an
issue were to come up that adversely affected us, we would not have a
formal way to object at the moment. Being a liason member gives us
official standing with the organization, allowing us to participate
alongside Google, Apple, and Microsoft in any Unicode-related
discussions that are important to us.
Other open sources projects that are currently liaison members:
The GNOME Foundation
The Mozilla Project
OpenOffice.org
I'm not sure if there is any fee for becoming a liaison member. The
instructions simply say to "contact the Unicode Office for details".
Would it be worth contacting them to find out?
Ryan Kaldari
Tomorrow is the first IRC bug triage (finally!). We'll start the
meeting at 2300 UTC (see http://hexm.de/44 for the UTC impaired, like
myself).
The triage agenda is all set on
<http://etherpad.wikimedia.org/BugTriage-2011-06>. Feel free to make
comments, but please do not delete items.
Here is the broad overview:
* Start with bugs that are affecting Wikipedia users *now*
* Followup on bugs discussed in previous triages and get updates on
progress
* Discuss an outstanding API issue that a tracking bug covers
Following that, I'd like to get brief input on bugs that were marked
“High” priority going into the 1.18 cycle and have been marked
deployment or tarball blockers as a result. Let's discuss if the
deployment blockers should really be blocking deployment.
Some are older bugs, so we may remain relatively unconcerned about them
and decide that they shouldn't block 1.18. Or, maybe we'll find a
willing hacker to fix them.
So join us in #wikimedia-dev for our first ever IRC Bug Triage.
See you there,
Mark.
When I think that a version committed by myself r90650 (marked as new)
is fully obsolete and
already replaced in my other commit r90684 (marked as fixed)
in order to save code reviewers' time,
here are my questions:
1. shall I revert the 90650 from SVN ?
2. how exactly, and what would be meaingful comment ?
3. or can I do anything else which is of help in this case?
I need to ask here, because I could not find clear instructions or
conventions
for such cases on
http://www.mediawiki.org/wiki/Code_review_guide and
http://www.mediawiki.org/wiki/Subversion
T.
Hi
Do the latex equations rendered as images, dont have a image description page.
If they do, how do I go about getting an xml for them?
Consider the image below.
http://upload.wikimedia.org/math/f/6/a/f6ac8632c237011599f300e62d916859.png.
It is on page http://en.wikipedia.org/wiki/Acid.
I can't find the image description page for this image.
If it doesnt have a description page, is this true only for images
with class tex?
Or is it the case for some other classes of image as well?
Thanks :)
Sorry, now correctly cross posted.
Emmanuel
-------- Original Message --------
Subject: WMF XML dump title case problem
Date: Sun, 26 Jun 2011 17:07:19 +0200
From: Emmanuel Engelhart <emmanuel(a)engelhart.org>
To: Mailing list for Wikimedia CH <wikimediach-l(a)lists.wikimedia.org>,
offline-l(a)lists.wikimedia.org
Hi
Titles should be stored in the table "page" with a first letter uppercased.
http://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_%28technical_rest…
Unfortunately, it seems that we have XML dumps (and consequently
mwdumper generated SQL) containing titles with a first letter lowercased.
For example:
$wget
http://download.wikimedia.org/mywiktionary/20110617/mywiktionary-20110617-p…
$bzip2 -d -c mywiktionary-20110617-pages-articles.xml.bz2 | grep
"<title>"| grep tationery | more
<title>stationery</title>
<title>stationery shop</title>
Is that a bug?
Regards
Emmanuel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We are proud to announce the first stable release of the 1.17 series.
Selected changes since MediaWiki 1.16 that may be of interest:
* A new installer has been introduced. It has a wizard-style interface
which is translated into many languages. Many shortcomings in the old
installer were addressed with this rewrite. Note that it is no longer
required for the config directory to be made writable by the webserver.
Instead the generated LocalSettings.php file is offered as a download,
which you must then upload to the wiki's base directory.
* ResourceLoader, a new framework for delivering client-side resources
such as JavaScript and CSS, has been introduced. These resources are
now delivered through the new entry point script "load.php", instead of
as static files served directly by the web server. This allows
minification, compression and client-side caching to be used more
effectively, which should provide a net performance improvement for
most users.
* Category sorting has been improved.
* Sorting is now case insensitive.
* Sub-categories, pages and files can now be paged separately.
* When several pages are given the same sort key, they sort by their
names instead of randomly.
* The lowest supported version of PHP is now 5.2.3. If necessary, please
upgrade PHP prior to upgrading MediaWiki.
* Oracle Database support has been improved, and is now ready for beta
testing. If you work in an environment where Oracle is readily
available, and you can't get access to MySQL, this may be a useful
alternative for you. Please try it out and let us know if it works for
you. Oracle support is not yet recommended for use in production.
For more information about what's new in the MediaWiki 1.17 branch, see:
http://www.mediawiki.org/wiki/MediaWiki_1.17
Frequently asked questions about upgrading:
http://www.mediawiki.org/wiki/Manual:FAQ#Upgrading
Changes since 1.17.0rc1:
* Fixed syntax error in generated LocalSettings.php when a non-default
user rights profile is chosen.
* (bug 29399) Fixed PostgreSQL installation when the DB user for
installation is the same as the one for web access.
* (bug 29233) Fixed failover for DB slave servers. When a DB slave
went down, an error was immediately shown to the user, instead of
trying another slave. Was broken since 1.17 beta 1.
* (bug 29278) Fixed PHP fatal error when attempting to add text to a
page via a redirect.
* (bug 29408) Fixed uploads of files with MIME types that aren't
detected by MediaWiki.
Full release notes:
http://www.mediawiki.org/wiki/Release_notes/1.17
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.0.tar.gz
Patch to previous version (1.17.0rc1):
http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.0.patch.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.0.tar.gz.sighttp://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.0.patch.gz.sig
Public keys:
https://secure.wikimedia.org/keys.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4BdgAACgkQgkA+Wfn4zXkHuACfRZ4ih2jCGLF2mpzn85iCifzk
vUcAnj8Unua4E4p0uyOeXh96Jqb14pkY
=E8Vn
-----END PGP SIGNATURE-----
