Wikitech-l May 2013

wikitech-l@lists.wikimedia.org

158 participants
193 discussions

MediaWiki 1.21 delayed
by Mark A. Hershberger 18 May '13

18 May '13

I have to delay the release of MediaWiki 1.21 again because of a logistics problem. I am used to hearing logistics in the context of shipping physical objects -- in the American trucking industry, for example -- so I can't help but feel a little strange saying "logistics". I had to go look up the term and found this definition: The detailed coordination of a complex operation involving many people, facilities, or supplies. That is about right. I apologize for the confusion. -- http://hexmode.com/ Imagination does not breed insanity. Exactly what does breed insanity is reason. Poets do not go mad; but chess-players do. -- G.K. Chesterson

1 0

Code review of the Wikidata code
by Denny Vrandečić 18 May '13

18 May '13

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.

3 2

Server reboots now through next week
by Greg Grossmeier 18 May '13

18 May '13

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 |

3 4

Hiring Community Liaisons (Contract)
by Howie Fung 18 May '13

18 May '13

* 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. *

1 0

Re: [Wikitech-l] [Wikitech-ambassadors] Protocol-relative URLs and application of interwiki format
by Matthew Flaschen 17 May '13

17 May '13

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

1 0

Gerrit and Merging Branches
by Matthew Walker 17 May '13

17 May '13

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

2 3

Fwd: Special casing the Main Page - Reigniting an old discussion
by Jon Robson 17 May '13

17 May '13

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

1 0

Deployment Highlights - Week of May 20th, 2013
by Greg Grossmeier 17 May '13

17 May '13

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 |

1 0

don't show certain links with the help of Special:AllMessages
by Yury Katkov 17 May '13

17 May '13

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

3 4

New extension: Special:ExtensionStatus (opinions?)
by Moriel Schottlender 16 May '13

16 May '13

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!

13 21

← Newer
1
...
5
6
7
8
9
10
11
...
20
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l May 2013