Wikitech-l January 2013

wikitech-l@lists.wikimedia.org

143 participants
160 discussions

want to work with WikiMedia Foundation
by Shailaja Shah 15 Jan '13

15 Jan '13

Hello, I am a 3rd year B.Tech I.C.T.(Information and Communication Technology) student and am eager to contribute to the projects of postgresql involving PHP and SQL which is one of my interests.And I have also some experience in JAVA and C. I request you for contact of a mentor to guide me for the same. Cheers, Shailaja Shah

3 2

Fwd: [Wikimedia-l] Aaron Swartz Community Impact
by James Forrester 15 Jan '13

15 Jan '13

All, I thought that this might be particularly-relevant to members of this list, for those not on wikimedia-l; apologies if you have already seen. James. -- James D. Forrester jdforrester(a)gmail.com [[Wikipedia:User:Jdforrester|James F.]] (speaking purely in a personal capacity) ---------- Forwarded message ---------- From: Gayle Karen Young <gyoung(a)wikimedia.org> Date: 14 January 2013 11:13 Subject: [Wikimedia-l] Aaron Swartz Community Impact To: "wikimedia-l(a)lists.wikimedia.org" <wikimedia-l(a)lists.wikimedia.org> *I sent this to the staff list and am sending it to wikimedia-l now as well. I didn’t know Aaron Swartz, but many friends and colleagues that I respect and admire were influenced and impacted, by both his life and death. I’m sad for those who knew him, and I carry the sense that the world is a worse place for his absence. I’m worried that other talented, smart people who see what is wrong with this world and try to change it against overwhelming odds will see this as one more thing that tips the scales towards the “this isn’t worth it” or “I can’t exist like this”, slide a little further down the slippery slope into their own abyss. I’m worried about people in pain and confusion, who may not have the people in their lives who are able to handle explicit or implicit expressions of pain and grief, who may feel isolated or sad and not able to reach out for help, or don’t believe they can be helped. I started my career studying depression treatment and prevention because I’ve seen what it does to people - whether they’re beautifully ordinary people you’d meet on the street or whether they’re great shining lights whose loss makes you want to rail at an unfair universe - and because I have my own history of major depressive episodes and my own sit-down with a bottle of pills one dark night and I’ve grieved suicide in my own family system and lived with its consequences. For the living, different kinds of death leave different kinds of wounds, and I think suicide leaves the most jagged, livid ones. If you’ve had a loved one pass from illness or old age, the wound is just different than that of suicide. As an illness, depression is painful and inherently isolating, and it makes people feel terrible about themselves - and isolation is a major factor for suicide. Depression slams blinders on possibility, when people most need to be able to see the options and paths before and around them, and when people need to have access. The state inherently robs someone of their ability - and even of the belief that help is possible and available. My favorite author <http://www.amazon.com/Night-Falls-Fast-Understanding-Suicide/dp/0375701478 >on this topic, Kay Redfield Jamison, wrote “When people are suicidal, their thinking is paralyzed, their options appear spare or nonexistent, their mood is despairing, and hopelessness permeates their entire mental domain. The future cannot be separated from the present, and the present is painful beyond solace.” The factors that generally lead to depression and suicide are complex, though people keep trying to find the one tipping point thing, the one cause. At the end of the day, death forces the living to sit with the unknowns. I think anecdotally that if you live long enough, you develop a certain resiliency and a greater capacity - but that’s if you get to that point in the first place. So here’s your public service announcement - communities where there is exposure to suicide via media/internet carry greater risks. It’s called suicide contagion <http://www.cdc.gov/mmwr/preview/mmwrhtml/00031539.htm>. As a community, it’s worth it to be informed and to be extra care-full of those we interact with, and to take increased care of your mental health. (Take a walk. Call a friend.) Major risk factors <http://www.cdc.gov/violenceprevention/suicide/riskprotectivefactors.html >for suicide include mental disorders, especially mood disorders, hopelessness, impulsive/aggressive tendencies, family history or previous attempts, physical illness, job/financial loss, relationship loss, lack of social support and isolation, stigma associated with asking for help, cultural beliefs, and exposure to others who have committed suicide (via internet as a form of transmission). If someone you know is suicidal (and especially if they have a plan), get help. Don’t try to talk them out of suicide. Don’t tell them their family will miss them or that they’ll be a huge loss, even though both of those are true. Listen to them. Tell them what they’re going through is temporary, even if they’ve lived with it for awhile, and that It’s treatable. It will pass. And for the love of anything you consider holy, get professional help. They’ll often believe they can’t be helped. If it’s you, please ask for it. I will find you help. You are not alone. If you have or had suicidal thoughts, you’re not crazy. It’s okay - or at least, it’s not yet but it will be. It’s a signal flare that it’s time to get aid. Rilke wrote, “I am not yet wise in my grief so this great darkness makes me small” and I’ve thought often of that line because I needed it to remind me that I had to learn to be wiser, especially in my grief. I think the other thing to remember are the words of Mary Oliver, that “To live in this world, you must be able to do three things: to love what is mortal; to hold it against your bones knowing your own life depends on it; and, when the time comes to let it go, to let it go.” For the living, grieving Aaron and letting him go without making more or less than the fullness of his life and passing, is part of our individual and collective task.* Gayle -- Gayle Karen K. Young Chief Talent and Culture Officer Wikimedia Foundation p. 415.839.6885 x6691 c. 415.310.8416 www.wikimediafoundation.org _______________________________________________ Wikimedia-l mailing list Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l

1 0

Open Tech Chat this week: git-deploy!
by Rob Lanphier 15 Jan '13

15 Jan '13

Hi everyone, This week's open tech chat is going to be very tied to current events, where the current event is the data center migration, and specifically, our move to git-deploy[1] as a replacement for the venerable "scap"[2] for deployments in the new (and old) datacenters. This talk will be geared toward people that already have deploy access due to the urgency of this training. So, while we won't be kicking anyone out who just wants to learn about this stuff, and we can probably handle a couple of basic questions that people who currently deploy should already know, we'd like to keep things largely focused on the people who need to learn this to know the new system. Meeting details are here. http://www.mediawiki.org/wiki/Meetings/2013-01-17 Hope to see you there! Rob [1] http://wikitech.wikimedia.org/view/Git-deploy [2] http://wikitech.wikimedia.org/view/Scap

1 0

Update on Ashburn data center switchover / migration – target date is week of 1/22/13
by Ct Woo 15 Jan '13

15 Jan '13

All, The Migration team is in the last lap on completing the remaining tasks to ready our software stack and Ashburn infrastructure for the big switchover day. Per my last update,<http://lists.wikimedia.org/pipermail/wikitech-l/2012-October/063668.html> with the Fundraising activity behind us now, the team has scheduled the *week of 22nd January*, 2013 to perform the switchover. We are going to block a 8-hour migration window on the *22nd, 23rd and 24**th*. During those periods, *17:00 UTC to 01:00 UTC hours (9am to 5pm PST*), there will be intermittent blackouts and they will be treated as 'planned' outages. You can follow the migration on irc.freenode.org in the #wikimedia-operations channel. The team is putting the finishing touches to the last few tasks and we will make the final Go/No decision on 18th Jan, 2013. An update will send out then. For those interested in tracking the progress, the meeting notes are captured on this wikitech page<http://wikitech.wikimedia.org/view/Eqiad_Migration_Planning#Improving_Switc…> . *Please note that we will be restricting code deployment during that week, allowing only emergency and critical ones only.* Thanks. CT Woo

4 4

Re: [Wikitech-l] Release Notes and ContentHandler
by Lee Worden 15 Jan '13

15 Jan '13

On 01/13/2013 07:00 PM, wikitech-l-request(a)lists.wikimedia.org wrote: > From: Daniel Kinzler<daniel(a)brightbyte.de> > To: Wikimedia developers<wikitech-l(a)lists.wikimedia.org> > Subject: Re: [Wikitech-l] Release Notes and ContentHandler > Message-ID:<50F2ABF9.4020907(a)brightbyte.de> > Content-Type: text/plain; charset=ISO-8859-1 > > On 13.01.2013 02:02, Lee Worden wrote: >> >Yes, I think ContentHandler does some of what WW does, and I'll be happy to >> >integrate with it. I don't think we'll want to abandon the source-file tag, >> >though, because on pages like >> >http://lalashan.mcmaster.ca/theobio/math/index.php/Nomogram and >> >http://lalashan.mcmaster.ca/theobio/worden/index.php/Selection_Gradients/Ma…, >> >it's good to be able to intertwine source code with the rest of the page's >> >wikitext. > ContentHandler does not yet have good support for inclusion - currently, there's > just Content::getWikitextForInclusion(), which is annoying. It would be much > nicer if we had Content::getHTMLForInclusion(). That would allow us to > transclude any kind of content anywhere. > > That would mean taht instead of <source-file>Foo.tex</source-file>, you could > just use {{:Foo.tex}} to transclude Foo.tex's content. Actually, you could > implement getWikitextForInclusion() to return > <source-file>Foo.tex</source-file>, I guess - but that's cheating ;) It's not <source-file>Foo.tex</source-file> - that would be ridiculous. If nothing else, I'd use <source-file filename="Foo.tex"/>. :) [In fact, I do support that form, but it's hardly ever used.] No, it's <source-file filename="Foo.tex">\documentclass{article} [...] \end{document}</source-file>. It stores the actual source code. The file is not transcluded. This may seem ridiculous at first blush, and you might never want to do that with long .tex files or Python modules, but think instead of explaining a concept by using a series of little 4-line programs, to illustrate each step. You can think of <source-file> as <syntaxhighlight> with semantics behind it. It displays a code listing, with highlighting, but it also lets you run the code, in context, and display the output. There are plenty of use cases where you don't want to do that, you just want to put each source file on its own page, and I support that now, and I'll definitely support the use of ContentHandler when it's time, as I've been planning to all along. But the ability to edit, run, test, and refine the code by pressing the Preview button, without saving your changes to the wiki until you're satisfied, even if the code is in multiple source files, is a valuable affordance, and we may not want to give it up. >> >Also, in a multi-file project, for instance a simple LaTeX project with a .tex >> >file and a .bib file, it's useful to put the files on a single page so you can >> >edit and preview them for a while before saving. > That would not change when using the ContentHandler: You would have one page for > the .tex file, one for the .bib file, etc. The difference is that MediaWiki will > know about the different types of content, so it can provide different rendering > methods (syntax highlighted source or html output, as you like), different > editing methods (input forms for bibtext entries?). > > Basically, you no longer need nasty hacks to work around MediaWiki's assumption > that pages contain wikitext, because that assumption was removed in 1.21. Bundling several source files onto a single page, with wikitext interspersed, is a form of literate programming. It's part of the same tradition as knitr, R markdown, sage notebooks, etc. There are valuable uses for embedding code in free-form markup, and I think it's useful to be able to do it in MediaWiki. LW > -- daniel

1 0

Current state of the LTS
by Mark A. Hershberger 15 Jan '13

15 Jan '13

I've been looking at SMW's plans for the LTS and talking with other people on-wiki and off. As a result, LTS is firming up: * Security patches supplied until May 2015. * Compatibility extension for those features that can be put into an extension. * Back porting of other features. Where possible, we will only add hooks that the Compatibility extension can use. Also updated: https://www.mediawiki.org/wiki/Version_lifecycle Thanks! Mark. -- http://hexmode.com/ Language will always shift from day to day. It is the wind blowing through our mouths. -- http://hexm.de/np

2 1

i18n deployment 2013-01-15
by Siebrand Mazeland (WMF) 15 Jan '13

15 Jan '13

The following changes will be deployed to Wikimedia wikis on Tuesday 09:00 UTC (01:00 PST): * Backport of feature to "Allow preferences that need not be rendered in Special:Preferences"[1] to 1.21wmf7 * Update of extensions Translate[2] and UniversalLanguageSelector[3] to master in 1.21wmf7 * Disable extensions Narayam[4] and WebFonts[5] on all wikis with extension Translate enabled (see list below). Functionality of these extensions is superseded by that of UniversalLanguageSelector. * Enable extension UniversalLanguageSelector to be enabled on all wikis with extension Translate enabled (see list below) UniversalLanguageSelector will be enabled with: * $wgULSEnableAnon set to false (see bug 41451[6] for details) * $wgULSGeoService = false; List of wikis with extension Translate enabled and the changes besides the language selector: * bewikimedia (adds web fonts and input methods) * incubatorwiki * mediawikiwiki * metawiki (also adds web fonts) * outreachwiki (adds web fonts and input methods) * testwiki (also adds input methods) * wikidatawiki (also adds input methods) * wikimania2012wiki (also adds web fonts and input methods) * wikimania2013wiki (also adds web fonts and input methods) [1] https://gerrit.wikimedia.org/r/#/c/37395/ [2] https://www.mediawiki.org/wiki/Extension:Translate [3] https://www.mediawiki.org/wiki/Extension:Universal_Language_Selector [4] https://www.mediawiki.org/wiki/Extension:Narayam [5] https://www.mediawiki.org/wiki/Extension:WebFonts [6] https://bugzilla.wikimedia.org/41451 Cheers! -- Siebrand Mazeland Product Manager Language Engineering Wikimedia Foundation M: +31 6 50 69 1239 Skype: siebrand Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

4 6

Rescheduled MobileFrontend deployment, open slot this Tuesday
by Arthur Richards 15 Jan '13

15 Jan '13

The mobile team had to reschedule its regular MobileFrontend deployment from Tuesday (1-3pm PST) to Thursday (3-5pm PST)[1]. So, there's a new open slot on Tuesday if anyone needs it :) [1] http://wikitech.wikimedia.org/index.php?title=Deployments&diff=55333&oldid=… -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687

1 0

Proposal: MediaWiki Group Marketing
by Quim Gil 14 Jan '13

14 Jan '13

Hi, following the process for requesting the creation of a MediaWiki group, here is a proposal for MediaWiki Group Marketing http://www.mediawiki.org/wiki/Groups/Proposals/Marketing Your endorsements, improvements and feedback are welcome at the wiki page. Thank you! PS: see also http://www.mediawiki.org/wiki/Groups/Proposals -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

2 2

Extending the action=options API with storing arbitrary preferences
by Matma Rex 14 Jan '13

14 Jan '13

Yesterday, per the extended discussion on bug 40124, gerrit change I5f9ba5b0 has been merged. It extends the action=options API, essentially allowing user scripts, gadgets, and external editors to store arbitrary persistent private data in user preferences. [ https://bugzilla.wikimedia.org/40124 / https://gerrit.wikimedia.org/r/#q,I5f9ba5b0,n,z ] This officially reenables the feature that was present, but undocumented and defective in MW 1.20 (saving preferences using Special:Preferences cleared any additional fields) and which has been disabled in 1.20.1 as a part of a security fix (bug 42202 / gerrit I98df55f2). [ https://bugzilla.wikimedia.org/42202 / https://gerrit.wikimedia.org/r/#q,I98df55f2,n,z ] These semi-arbitrary options have only three limitations imposed on them: * the key must start with userjs- prefix (to avoid conflicting with new options being added in core or in extensions) * the length of the key must not exceed 255 bytes (this is a database schema limitation) * the key must consist only of ASCII letters, numbers, hyphens and underscores (a-z, A-Z, 0-9, _, -; for sanity) There are currently no hard limits on the length nor contents of the value, as well as on the number of additional preferences. The contents of these preferences are not escaped, sanitized nor validated in any way; script authors are expected to sanitize them themselves to prevent XSS attacks and other security vulnerabilities. Similar care should be taken if they are ever shown anywhere in the Special:Preferences interface. Two low-severity sister issues are left to be solved right now: * bug 43959 - action=options API should allow resetting of chosen preferences (instead of the all-or-nothing approach) * bug 43960 - Arbitrary userjs- preferences should be shown in the GUI, with the possibility of clearing them one-by-one [ https://bugzilla.wikimedia.org/43959 / https://bugzilla.wikimedia.org/43960 ] Overall, this could be a replacement for the current system of storing settings as global variables set in user's skin.js file, or in a separate .js file with gadget configuration, or in cookies / localStorage, which all have their drawbacks (clumsy, non-private, force an edit on-wiki to change prefs, volatile, possibly size-limited...). I'm quite looking forward to this happening :) -- Matma Rex

3 4

← Newer
1
...
8
9
10
11
12
13
14
15
16
Older →

Jump to page:

2025

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 January 2013