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
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
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
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
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
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
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
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
On 01/14/2013 10:20 AM, Yuvi Panda wrote:
> Is there a sort of 'Extension Bundle' that gets you baseline stuff that
> people who are used to wikipedia 'expect'? ParserFunctions and Cite come to
> mind, but I'm sure there are plenty others.
This was part of my reasoning behind bundling some core extensions with
MediaWiki.
ParserFunctions is already included, but I was going to bundle the
following extensions in 1.21:
* Cite
* InputBox
* LocalisationUpdate
* SyntaxHighlight_GeSHi
As far as template bundles, I think this would be better served with an
extension like LocalisationUpdate that could fetch a new copy of the
desired templates from your chosen Wikipedia.
Another area that could benefit most non-WMF wikis is a way to import
some documentation for how to *use* a wiki.
--
http://hexmode.com/
Language will always shift from day to day. It is the wind blowing
through our mouths. -- http://hexm.de/np