Hey,
in order to sanity check the code we have written in the Wikidata project,
we have asked an external company to review our code and discuss it with
the team. The effort was very instructional for us.
We want to share the results with you. The report looks dauntingly big, but
this is mostly due to the appendixes. The first 20 pages are quite worth a
read.
Since the Wikidata code is an extension to MediaWiki, a number of the
issues raised are also relevant to the MediaWiki code proper. I would hope
that this code review can be regarded as a contribution towards the
discussion of the status of our shared code-base as well.
I will unfortunately not be at the Hackathon, but a number of Wikidata
developers will, please feel free to chat them up. Daniel Kinzler is also
preparing a presentation to discuss a few lessons learned and ideas at the
Hackathon.
The review is available through this page: <
http://meta.wikimedia.org/wiki/Wikidata/Development/Code_Review>
Cheers,
Denny
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
This past week there was an important security release for the Linux
kernel. As such, we will be updating and rebooting ALL of our machines
ASAP.
This may affect you.
ALL WMF services will experience some downtime of up to 10 or so minutes
(including Bugzilla, Gerrit, etc).
== SPECIAL CONSIDERATIONS ==
Some machines are OK for us to just reboot as needed but others are
being utilized by others for various tasks (scripts, cronjobs, etc).
If you have jobs running on any machine that you do not have puppetized
(ie: it won't just magically start up again after a reboot) you will
want to restart your jobs after the reboot.
There is, unfortunately, not set schedule of when any particular machine
will be rebooted, but Ops will be giving ~30 minutes notice in the
#wikimedia-operations IRC channel on Freenode. You can watch the public
Server Admin Log at <https://wikitech.wikimedia.org/wiki/Server_admin_log>
for the warnings and the reboot notice.
Sorry for the invonvenience,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
*
Hey all,
For the last 18 months, the Engineering & Product Development department
has been experimenting with the role of “Community Liaison, Product
Development” - a staff member embedded in the Product team and tasked with
factoring community concerns into our software development process, keeping
editors informed about what we’re doing, and maintaining a dialogue between
those who write code and those who write articles.
While there is always room for improvement, I think this role has shown a
lot of promise. We have a number of large projects coming down the
pipeline (e.g., visual editor, discussion systems) and we need more help
reaching out to our contributor communities, especially our non-English
speaking projects, as our outreach there has traditionally been challenged.
We’d like to recruit a small number of English-speaking or multilingual
editors to do the Community Liaison job with different development teams
and focuses.
In particular we’re looking for people with a strong history of
contributions to our projects who can provide sound and reasoned judgment
and are trusted to do so by their community. Speaking other languages in
addition to English is a major plus, as one of the objectives here is to
ensure we can properly interact with and support non-English projects.
I’ve included the full job description below.
Our immediate need is for help with the Visual Editor. We’d like to hire a
few community liaisons to help inform different Wikipedia language
communities of the upcoming launch, create spaces for feedback and
discussion, synthesize feedback for the Visual Editor team, and other
activities required to support the Visual Editor launch later this year.
If this is a role that would interest you, please e-mail Philippe Beaudette
at pbeaudette(a)wikimedia.org<https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=pbeaudette@wikimedia.org>.
And if you know someone else who might fit the role, let them know about
it :-). We’re provisionally interested in hiring 2-3 liaisons, at an hourly
rate commensurate with experience. This can be a part-time role, but we’ll
need at least 15 hours/week for the length of the engagement (minimum 3
months). Please do apply if you think it’s a role that suits you, and if
you find places we haven’t notified, spread the word!
Thanks.
Howie
*
_________________________
Howie Fung
Director of Product Development
Wikimedia Foundation
*
Community Liaison Job Description
Background Information and Statement of Purpose
The Wikimedia Foundation’s Engineering & Product Development Department is
looking at ways to more effectively incorporate broad community
perspectives in decisions and hold dialogues with our editors about the
scope, pace and features of upcoming changes to Wikimedia projects. As part
of this, it is hiring additional Community Liaisons from our volunteer
community.
Scope of Work
Support and improve our ongoing software development projects, in
particular:
-
Building up a network of volunteers from both English language and
non-English language wikis, increasing the number of projects we can
interact with;
-
Engaging the community in the software development process, by acting as
a conduit for community questions, bugs and and feature requests, talking
to editors about our work and how they can participate in it effectively,
and recruiting them for workgroups and studies;
-
Being available from time to time to provide expertise and knowledge
about our projects, including but not limited to training
externally-sourced staff in the way our projects work, answering their
questions, and providing expert advice on an ad-hoc basis;
-
Ensuring that our community is represented in the decision-making
process and that our planned software adequately reflects user needs;
-
Monitoring Wikimedia projects, with the assistance of a network of
volunteers, for emerging issues that have an impact on Engineering
programmes; and
-
Other duties as needed.
Requirements
Effective Community Liaisons will be:
-
Experienced users of Wikimedia projects, capable of representing our
community within the Foundation and vice-versa.
-
Strong communicators (both verbally and with the written word), able to
explain our products to different groups of users with different levels of
technical understanding.
-
Able to focus on the larger picture, understanding which concerns and
views are widespread and which are marginal or individual.
-
Approachable, as both users and product developers must be able to trust
these people for the relationship to function.
-
Self-motivated - they will be given important projects and expected to
execute with little to no supervision.
-
Strongly empathetic - they excel at understanding the perspectives of
others and bridging the gap between different approaches to the world.
-
Willing and able to remain resilient in the face of frustration from our
users, in order to get the job done.
Pluses
Other positive attributes or areas of knowledge include:
-
Diverse language skills. While the Wikimedia Foundation communicates
internally in English, we aim to be able to talk to our different
communities natively.
-
Experience with the software development process. You will be thrown
into teams that are actively working on new features; having a background
that reduces the slope of your learning curve is a plus.
- Familiarity with multiple Wikimedia projects is a major plus; we are
about more than just Wikipedia.
*
On 05/17/2013 04:23 PM, David Abián wrote:
> Hello all,
>
> In the last weeks, I have been applying protocol-relative URLs in links
> with an HTTP defined protocol, and converting links from external to
> internal link format with my bot in all content pages of some (few)
> Wikimedia projects (please see details in [1]).
You quote Ryan Lane, "A number of templates, CSS, and Javascript on
projects are improperly referencing resources, and as such, they are
being loaded incorrectly. All resources should be referenced using
protocol-relative URLs now (//<resource-url> vs http://<resource-url>)."
But he is talking about resources like CSS/images/JavaScript, which can
cause mixed content warnings. Your bot only does links, which is a
separate issue.
Note that public WMF wikis do not have such external content in
wikitext. Images can only be from the local wiki or Commons (which of
course handles the protocol right).
The rest (CSS, JavaScript, other images, etc.) can only be from
extensions, gadgets, and user scripts.
> However, most of the projects are still pending, this task is not
> included in GBs scope, the community is raising many doubts, and I think
> that, in some way, running this task on all pages and projects, even
> without exceptions, should be allowed.
I use HTTPS Everywhere myself, so I get where you're coming from. But I
see this is a normal task that should follow the normal per-wiki bot
approval process(es) (if any).
Matt Flaschen
Hey all,
Fundraising uses deploy branches -- and this is a question about how to
manage them via gerrit / git-review. Effectively -- what am I doing wrong
that causes gerrit to reject my changes as exampled below:
Take for example CentralNotice (I created a test branch mwalker_test that
was cloned from far back in the repo). If I follow the basic example of how
I cherry pick a change into core, e.g.:
git fetch
git checkout mwalker_test
git cherry-pick 491b0dbb3ac01b4ebe6288cc5ea7e9aff6d49753 <-- a change
beyond my current tip
git review
gerrit tells me:
$ git cherry-pick 491b0dbb3ac01b4ebe6288cc5ea7e9aff6d49753
[mwalker_test 7016450] Add dependency to mobile module
Author: jrobson <jrobson(a)wikimedia.org>
1 file changed, 1 insertion(+)
$ git review
remote: Resolving deltas: 100% (2/2)
remote: Processing changes: refs: 1, done
To ssh://
mwalker@gerrit.wikimedia.org:29418/mediawiki/extensions/CentralNotice.git
! [remote rejected] HEAD -> refs/publish/master/mwalker_test (change 59546
closed)
error: failed to push some refs to 'ssh://
mwalker@gerrit.wikimedia.org:29418/mediawiki/extensions/CentralNotice.git'
Say what!? The mystery further deepens when I do a straight up merge:
$git merge master
...
$ git review
remote: Processing changes: refs: 1, done
To ssh://
mwalker@gerrit.wikimedia.org:29418/mediawiki/extensions/CentralNotice.git
! [remote rejected] HEAD -> refs/publish/master/mwalker_test (no new
changes)
error: failed to push some refs to 'ssh://
mwalker@gerrit.wikimedia.org:29418/mediawiki/extensions/CentralNotice.git'
Anyone have any ideas?
~Matt Walker
Wikimedia Foundation
Fundraising Technology Team
Forwarding to a wider audience.
Quick summary: Do people still care about having to add additional
markup to their homepage to make it mobile friendly? Are you
interesting in seeing how it looks without the special casing and
fixing it?
---------- Forwarded message ----------
From: Jon Robson <jdlrobson(a)gmail.com>
Date: Wed, May 15, 2013 at 5:24 PM
Subject: Special casing the Main Page - Reigniting an old discussion
To: mobile-l <mobile-l(a)lists.wikimedia.org>
Since I started working on MediaWiki in the mobile team a common
complaint has been "why do I have to make my homepage mobile friendly"
(especially during Wikimania 2012). As background - currently Main
Pages have to be marked up specially for mobile [1].
Although I share the hate (this has been a long standing bug [2]) - if
I'd been around in the early days would have prevented from happening
- I believe people are more inclined to fix ugly broken things then
fix things that do the job.
The main problem here is that the majority of wiki projects have
homepages that are extremely badly written for mobile. There are
various hacks that we can do our end but there is no guarantee these
will work on older phones without a massive rewrite. The main
offenders are typically inline styles which are near impossible to
predict/override/control (many people familiar with me know all about
my vendetta against them [4]) and the use of tables which are also
problematic on mobile.
Luckily with a recent change it's now easier to see what is wrong with
your favourite Wiki homepage even after lots of hacks from our end. If
you opt into the experimental mode [4] and visit the home page it will
no longer be special cased and inline styles on it will be scrubbed
with javascript enabled...
I'd encourage anyone who cares about killing this 'feature' of
MobileFrontend with fire to reassess their favourite homepages.
Suggested actions after opting into experimental mode:
* Disable javascript and see what your homepage looks like with inline
styles - edit the main page to make any inline styles that involve
pixels or %s's more mobile friendly and where possible and reusable
move these inline styles to css rules in MediaWiki:Common.css which is
not run on mobile.
* Add the class nomobile to elements which should not be shown on mobile.
If there is enough traction/interest here I'd be keen to make no
special casing an opt in configurable global feature. It would be nice
to have consistent mobile and desktop views. If there's no interest
that's cool as well - it just means I can resolve this long standing
bug as RESOLVED WONTFIX :)
Let me know either way... FWIW Wikivoyage and Wikipedia are almost
there in terms of mobile friendliness without any special casing...
[1] http://meta.wikimedia.org/wiki/Mobile_Projects/Mobile_Gateway#Mobile_homepa…
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=30405
[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=35704
[4] https://en.m.wikipedia.org/w/index.php?title=Special:MobileOptions&returnto…
--
Jon Robson
http://jonrobson.me.uk
@rakugojon
Hello and welcome to the latest installment of the Deployment Highlights
email.
The full calendar for next week lives at:
https://wikitech.wikimedia.org/wiki/Deployments#Week_of_May_20th
For the week of May 6th we have the following interesting deployments:
== All Week ==
* Due to a security update to the Linux kernel, we will be upgrading and
rebooting ALL machines throughout the week. This may affect your
experience with some services, but it should be minimal.
== Monday ==
* VisualEditor will be deploy a new extension, TemplateData, to all
Wikipedias (<https://bugzilla.wikimedia.org/show_bug.cgi?id=44444>) in
addition to a VisualEditor configuration change on mediawiki.org
(<https://bugzilla.wikimedia.org/show_bug.cgi?id=48430>).
* English Wikipedia will be updated to MediaWiki version 1.22wmf4, in
addition to a WikiData client update on English Wikipedia. See
<https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap>
* An update to HTCP purging will be rolled out by the WMF Operations
team which might create momentary issues with some thumbnails. Please
report any issues you experience.
== Wednesday ==
* The rest of the Wikipedias will be updated to MediaWiki 1.22wmf4, thus
completing the roll out of that version. The next version, 1.22wmf5,
will start on Monday May 27th. See
<https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap>
== Thursday ==
* The Editor Engagement team (E2) will rollout bugfixes to Notifications
(Echo). See <http://etherpad.wikimedia.org/echo-release>.
Best,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hi everyone!
I think that Special:AllMessages and the idea that every message in the
wiki has its own wikipage is just _awesome_.
So, I can Replace the "disclaimer" label to smth different
using MediaWiki:Disclaimers. That's great.
However I haven't found the way to HIDE the element. For instance I don't
need the "policy" link in my footer. Is that possible of should I use CSS?
-----
Yury Katkov, WikiVote
Hello everyone,
I'd like to get your opinions and critique on my very first MediaWiki
extension, which, I hope, will be helpful to other developers.
I noticed that there's no easy way of seeing if extensions that we have
installed on our MediaWiki require update, and there are even some
extensions that get so little regular attention that when they do get
updated, there's no real way of knowing it (unless we check specifically).
It can be annoying when encountering problems or bugs, and then discovering
that one of our extensions (probably the one we least expected) actually
has an update that fixed this bug.
So, I thought to try and solve this issue with my extension. Since
MediaWiki's changes are submitted through gerrit, I thought I'd take
advantage of that and perform a remote check to see if there are any new
commits that appeared in any of the extensions since they were installed.
How it works, briefly: the system compares the local repository date to the
list of latest commits on gerrit's repo for the extension to see how many
commits a user is behind on. If the user doesn't have a local git for the
extension (or if they downloaded the extension manually) the system falls
back to testing the local modification date for the files. It's not
perfect, but it can give people a general idea of whether or not their
extensions need some TLC.
The extension is available on GitHub:
https://github.com/mooeypoo/MediaWiki-ExtensionStatus along with
screenshots and a short possible todo list.
There's a list of things I plan to try and improve, some of them are meant
to make the lives of newbie developers (like me!) easier, but I'd love it
if I could get feedback from you all and see if you think this could be
helpful to you.
Would you like to see anything else in it? Do you think I'm in the right
direction or am I doing it all wrong?
Be merciless!
Okay, maybe not *completely* merciless, but please don't hold back. This is
my very first extension, and beyond wanting to make this a good extension,
I also want to get a sense of whether or not I got into MW development
right, and if there is anything I should have done (or be doing)
differently.
Please let me know what you think!
Moriel
(mooeypoo)
--
No trees were harmed in the creation of this post.
But billions of electrons, photons, and electromagnetic waves were terribly
inconvenienced during its transmission!
Hello GSoC Mentors,
As you are participating to Google Summer of Code, I'm wondering if you
could consider using Flower Dev Center [1] while working with students.
Flower Dev Center is an online platform for UML modeling diagramming,
with a strong focus on code synchronization, integration with dev tools
(Git, SVN, etc) and real time collaboration on diagrams (and a little
bit on code as well).
We think Flower Dev Center can be helpful for both: mentors and students
during Google Summer of Code. We have created an article on this topic
(i.e. Flower Dev Center + GSoC): [2], [3].
If you have a couple of spare minutes, could you tell us if you would
like to use Flower Dev Center? And/or raise topics that you think are
important (based on previous GSoC participations) to be supported by
Flower Dev Center?
REMARK1: Right now, Flower Dev Center is closed source and offered for
free to open-source projects. Starting with next version we'll begin to
open its API and source code, so that anyone could write extension
plugins, etc.
REMARK2: The next version of Flower Dev Center, the 2.0.0 planned for
June/July 2013, has major new features, that we did not demonstrate yet
and that will improve even more the collaboration between developers.
REMARK3: Flower Dev Center doesn't currently support PHP programming
language. But if you are interested in using Flower Dev Center, we'll
prioritize it's implementation and we'll work hard to do it ASAP, with
Flower Dev Center 2.0.0.
REMARK4: Flower Dev Center will support programming languages that are
not object oriented, starting with 2.0.0
Thank you in advance!
Best regards,
Mircea @ The Flower Platform Team.
[1] - Flower Dev Center web site - http://www.flower-platform.com
[2] - Video “Flower Dev Center + Google Summer of Code” -
http://learn-discuss.flower-platform.com/flower_dev_center/videos/flower_de…
[3] - Text version with same content as the above video -
http://learn-discuss.flower-platform.com/flower_dev_center/tutorials/flower…