Hi,
On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote:
> We will be holding this brownbag in 25 minutes. The Bluejeans link has
> changed:
>
> https://bluejeans.com/396234560
I'm not familiar with bluejeans and maybe have missed a transition
because I wasn't paying enough attention. is this some kind of
experiment? have all meetings transitioned to this service?
anyway, my immediate question at the moment is how do you join without
sharing your microphone and camera?
am I correct thinking that this is an entirely proprietary stack
that's neither gratis nor libre and has no on-premise (not cloud)
hosting option? are we paying for this?
-Jeremy
Hi,
YuviPanda, prtksxna, and myself (with help from Tim and Aaron) have been
working the UrlShortener extension, which is designed to implement the
URL shortener RfC[1] (specifically Tim's implementation suggestion).
I've filed T108557[2] to deploy the extension to Wikimedia wikis. We'd
like to use the "w.wiki" short domain, which the WMF is already in
control of.
A test wiki has been set up mimicking what Wikimedia's configuration
would be like: http://urlshortener.wmflabs.org/, and has an accompanying
"short" domain at us.wmflabs.org (e.g. http://us.wmflabs.org/3). Please
play with it and report any bugs you might find :)
[1] https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener
[2] https://phabricator.wikimedia.org/T108557
Thanks,
-- Legoktm
Hi,
I only now noticed that Phabricator has blogs:
https://phabricator.wikimedia.org/phame/blog/
I couldn't find a way to subscribe to them in RSS. Is it possible?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
"I came across a patch from a user who was keen to move himself from
"Patch contributors" to "Developers" in the MediaWiki CREDITS file
[1]. It had been sitting there for over a year. He doesn't seem to
have been active since. I don't know what to do with it. It made me
think.
Do we have it documented anywhere how we use this credits file and why
we feel the need to distinguish between Developers and Patch
Contributors? It seems like a recipe for disaster in my opinion as it
can only lead to hurt feelings due to contributors feeling unfairly
treated. https://www.mediawiki.org/wiki/Special:Version/Credits leads
with 'We would like to recognize the following persons for their
contribution to MediaWiki." - if someone is not in that list are they
not as important?
If we keep these files we should probably explain the rules to what
adding names looks like within these files and what the process to
adding your name is (can I add myself? Is there a process like getting
+2?)
To take another extreme, we might consider abandoning such a file in
favour of something automatically generated. Things like
https://github.com/wikimedia/mediawiki/graphs/contributors do a far
better job at allowing people to see who contributed to a tool and
making people feel like their work is rewarded.
On a slightly related note, can we abandon the practice of putting
names inside files themselves? I see this practice in JavaScript and
PHP files throughout core (grep for @author). As Team Geek [2] (great
read btw) says "unlike other collaborative pieces of creative work...
software keeps changing even after it's "done". So while listing
contributors credits at the end of a movie is a safe and static thing,
attempting to add and remove names from a source file is a
never-ending exercise in insanity". For similar reasons this practice
gives an impression of ownership of a file/code review
responsibilities (which are not always true) and risks hurt feelings.
[1] https://github.com/wikimedia/mediawiki/blob/master/CREDITS
[2] http://www.amazon.com/gp/search?index=books&linkCode=qs&keywords=9781449302…
On Thu, Feb 4, 2016 at 8:20 AM, MZMcBride <z(a)mzmcbride.com> wrote:
> Federico Leva (Nemo) wrote:
>>Login pretty much never does what I expect nowadays, but I'm not sure my
>>expectations are correct so I can't identify actual bugs.
>
> There are various open tasks in Phabricator about user sessions currently,
> such as <https://phabricator.wikimedia.org/T124440>. Being unexpectedly
> logged out lately has been a bit annoying, though I don't know if it's
> related to the Performance team or some other team.
The origin of the unexpected logouts falls on the AuthManager project
and specifically the SessionManager component that rolled out in
1.27.0-wmf.11 [0]. We had various issues related to the session
handling changes including a bug that was overloading the storage
capacity of the Redis servers that store session data [1] and two
other issues which required rolling the wikis back to 1.27.0-wmf.10
[2][3].
Both rollbacks were accompanied by a run of the
"resetGlobalUserTokens.php" maintenance script which updates each
user's CentralAuth records in such a way that their authentication
session will be considered invalid the next time it is used on a wiki.
This was done from an abundance of caution point of view concerning
possible issues with sessions that had been issued by the
SessionManager software. The reset script is not fast [4], so session
invalidation has slowly worked its way across the CentralAuth user
table.
Part of the enhancements that are being applied in order to bring
SessionManager back to production with 1.27.0-wmf.13 is a new config
setting that can be used to give us a nearly instant switch to throw
to invalidate all active sessions. This setting is actually included
in 1.27.0-wmf.12, but the configuration on the Wikimedia cluster has
not been changed to make use of it yet. Invalidating all user sessions
is not something we plan to do for fun certainly, but there have been
in the past (and likely will be in the future) software and
configuration issues that necessitate the use of that heavy hammer
approach.
[0]: https://phabricator.wikimedia.org/T123451
[1]: https://phabricator.wikimedia.org/T125267
[2]: https://wikitech.wikimedia.org/wiki/Incident_documentation/20160123-Session…
[3]: https://tools.wmflabs.org/sal/log/AVKZtfQXW8txF7J0uNE2
[4]: https://phabricator.wikimedia.org/T124861
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
irc: bd808 v:415.839.6885 x6855
I'm happy to announce a new mirror for datasets other than the XML dumps.
This mirror comes to us courtesy of the Center for Research Computing,
University of Notre Dame, and covers everything "other" [1] which includes
such goodies as Wikidata entity dumps, pageview counts, titles of all files
on each wiki (daily), titles of all articles of each wiki (daily), and the
so-called "adds-changes" dumps, among other things. You can access it at
http://wikimedia.crc.nd.edu/other/ so please do!
Ariel
[1] https://dumps.wikimedia.org/other/
There are currently 94 WMF wikis using UCA category collation rather than
the default "uppercase" collation. The Unicode Collation Algorithm (UCA) is
the official standard for how to sort Unicode characters, and generally
follows how a human would typically alphabetize strings. For example,
uppercase collation sorts Aztec, Ärsenik, Zoo, Aardvark as "Aardvark,
Aztec, Zoo, Ärsenik", but uca-default collation sorts them as "Aardvark,
Ärsenik, Aztec, Zoo". UCA collation also (optionally) supports natural
numeric sorting so that 100, 1, 99 sorts as "1, 99, 100" rather than "1,
100, 99". The WMF Community Tech team has recently posted proposals on
English Wikipedia and several Wiktionaries asking if these communities
would support switching to UCA collation. The proposal on English Wikipedia
has received unanimous support so far.[1] We thought that Wiktionaries
would be more skeptical of the change, but so far we have received only
positive responses.[2]
Since it seems that most wikis are receptive to switching to UCA, maybe we
should just make it the default rather than waiting on all the wikis to
request it separately. Of the large Wikipedias, French, Dutch, Polish,
Portuguese, and Russian are already using UCA, and German is in the process
of switching.[3] For non-Latin scripts, my understanding is that UCA will
be a big improvement, especially if we switch them to language-specific
implementations, like uca-ja, uca-zh, uca-ar, etc.
Three questions:
1. Does switching the default collation from "uppercase" to "uca-default"
sound like a good idea?
2. Should this be proposed on meta or is it too technical?
3. Are there any wikis that would need to opt out of this for some reason?
(I know there are issues with Kurdish,[4] but that's the only one I know
about.)
1.
https://en.wikipedia.org/wiki/Wikipedia_talk:Categorization#OK_to_switch_En…
2. https://phabricator.wikimedia.org/T128502
3. https://phabricator.wikimedia.org/T128806
4. https://phabricator.wikimedia.org/T48235
Question 1: Would anyone care if we kill the "loginCTA" campaign, which
tracks when people use the link at the bottom of Special:UserLogin to get
to the account creation page?
Question 2: Would anyone care if we remove the extension entirely from
Wikimedia wikis? Wikiapiary seems to show only one user outside of
Wikimedia.
Background: The extension needs a rewrite for AuthManager, and in
particular the "loginCTA" campaign will be a bit of a pain to keep working.
If someone is making use of the extension that's fine, but if not we may as
well not continue to spend development resources on it.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
Hi everyone,
The important part of this email is this link:
https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Status_repor…
This is the second Community Wishlist Survey status report. In November and
December, active contributors to Wikimedia projects proposed, discussed and
voted on the features and fixes that they most want to see. The Wikimedia
Foundation Community Tech team has been tasked with working on
these. Additionally, Wikimedia Deutschland's Technical Wishes team has been
working on wishes from the German-speaking community. There's overlap
between the two wishlists, and the teams are collaborating on various
wishes, so this report includes progress made by both teams as well as
great work being done by volunteer developers and other WMF staff.
So far, we (in the broad sense) have added support for:
*) Migrating dead external links to archives (but there's more work to be
done!)
*) Pageview stats
*) Global notifications
*) A category watchlist
We're currently working on:
*) Improving the plagiarism detection bot
*) Improving the diff compare screen
*) Numerical sorting in categories
*) The possibility to add an expiry date to watchlist items
*) A revision slider to help editors navigate through diff pages
For more information on these projects as well as upcoming tasks, see the
full status report on Meta:
https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Status_repor…
We're looking forward to talking and working with you as we go along.
Thanks,
//Johan Jönsson
User:Johan (WMF)
--