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)
--
https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-05-25
= 2016-05-25 =
== Technology ==
=== Analytics ===
- Trying to puppetize druid, harder than it looks
- Working on scaling on pageview API and cassandra, doing perf testing
on new nodes
- Trying to add throttling to pageview API
- Working on harvesting edit data from db/dumps into hadoop, WIP , main
goal this quarter
- Deployed visualization of Unique Devices:
https://vital-signs.wmflabs.org/#projects=ptwiki/metrics=UniqueDevices
-
=== Services ===
* RESTBase
** rate limiting in prod, log-only
*** Analytics, we need to discuss pageview limits
* Cassandra
** expanding from 2 to 3 instances per node in prod
** upgrade to 2.2.6 next
* Change prop
** handling updates for summary and mobile-sections* endpoints
** will move purging to it soon
* Math
** MathML by default on all wikibooks, early next week all projects
* heads up: Services team on Wikimania, then off-site at the end of June
=== Release Engineering ===
* '''Blocking''': ???
* '''Blocked''': none
* '''Updates''':
** wmf.3 is rolling forward this week
** rc.0 of 1.27 should be out this week
=== Technical Operations ===
* '''Blocking''':
** none
* '''Blocked''':
** none
* Updates:
** misc varnish cluster on route for being upgrade to varnish 4 again
** getting rid of tech debt on the database front (m1 cluster to be
reimaged)
** helping releng with scap3
** Getting finally a redundant link esams-eqiad
** libicu upgrade. See email from Giuseppe on wikitech-l
=== Security ===
* Two-factor authentication has been deployed to CentralAuth wikis with
permission enabled for staff
* Abbey and Daisy are assisting in usability surveying of two-factor
* Darian and Chris are working on knowledge transfer prior to Chris' last
day on Friday, May 27th
* Darian is working on onboarding documentation in anticipation of Security
Team hires in the near-ish future
* Security review schedule remains on track (
https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Schedule ) and Brian
Wolff will be assisting
== Product ==
=== Reading ===
==== Web ====
* Getting ready for Hovercards A/B test (finialising bug fixes)
** Fundraising tech eng can have a look at JS variable for Popups
enabled/disabled
==== Android ====
* released Beta with Reading Lists
==== iOS ====
==== Mobile Content Service ====
* Working on feed endpoints
==== Reading Infrastructure ===
* AuthManager: please read email from Brad on wikitech-l
* https://gerrit.wikimedia.org/r/#/c/290269 (testing gem) pending review as
of 24-May-2016
=== Community Tech ===
* No blockers
* Numerical sorting in categories
** New indexes are in place thanks to JCrespo (
https://phabricator.wikimedia.org/T130692 )
** Will be proposing on Wikitech-l that we switch to "uca-default" as the
default page collation, rather than "uppercase" (
https://phabricator.wikimedia.org/T136113 )
* Launched MassViews interface for pageview stats (
http://tools.wmflabs.org/massviews/ )
* Working on new CopyPatrol tool for detecting plagiarism (
http://tools.wmflabs.org/plagiabot )
=== Editing ===
==== Parsing ====
(Subbu won't be there, updates only)
* Work ongoing to migrate Parsoid to use service-runner after a bunch of
fixes were pushed to service-runner - hoping to push this past the finish
line by next week before attempting a migration of Parsoid cluster to
jessie / node v4 (Follow along on
https://phabricator.wikimedia.org/T135176 and
blocking tasks). Conversation ongoing with services team to resolve details.
* Tidy replacement work proceeding well. After last round of fixes and
visual diff testing, ~88% of test pages render with pixel-perfect accuracy
and ~97% pages with < 1% pixel diffs with HTML5depurate. Additional CSS
fixes since then and new round of visual diff testing in progress. Tim
working to make some fixes to doBlockLevels in core parser to iron out some
kinks there which leads to different behavior in HTML5depurate compared to
Tidy (similar effects in Parsoid).
* Kunal's linker rewrite patch merged. Follow up work in progress to use
the new linker code.
* VE / CX: Please start thinking about how your code needs to change to use
split data-mw format. The data-mw split code is probably 2-3 weeks away in
terms of being ready for deployment, but you can start testing it with
Parsoid master which can provide you the split data-mw (ping arlolra on IRC
for details).
==== Language ====
* Blocked:
** Preference section "Internationalisation" balloons after clicking "More
language settings" https://phabricator.wikimedia.org/T133114(Frontend/Style
libs)
** Can't load In Progress or Published translation list
https://phabricator.wikimedia.org/T135743 (For: Collobration/Roan)
* Updates:
** Compact Language Links (as a non-beta feature) deployed in
Beta/testwikis; work on it continue along with ULS
=== Fundraising tech ===
* (force) merged security patches to fr branch, deployed
** got tests passing again Monday
* CentralNotice: api for a/b testing
* More work to get off ActiveMQ, remove SPOF (just bit us again last week)
* Prepping for fundraising in Israel, Japan and Ukraine
** Trying to mess with language fallbacks on payments cluster so we never
show Russian messages to those whose preferred language is Ukrainian
* Enhancing fraud & dos mitigation measures
=== Discovery ===
* '''Blocking''': none
* '''Blocked''': none
* Team offsite last week, got plans for next Q and year
* Upgrade to ElasticSearch 2.3 is coming on Thursday (
https://phabricator.wikimedia.org/T133124)
* Portal team added descriptive texts to project links on portal after A/B
test showed (small) positive impact
* Survey results for portal visitors:
https://commons.wikimedia.org/wiki/File:Wikipedia_Portal_Survey_-_May_2016.…
* Maps in Wikivoyage now support external layers:
https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Maps_with_extra…
== Wikidata ==
* Blockers: none.
* Deleting files on Commons that are used in Wikidata statements was not
possible due to a bug. https://phabricator.wikimedia.org/T135485
* First prototype for structured data on Commons is close, finally.
https://phabricator.wikimedia.org/T125822
* QUnit tests timed out on Jenkins more often this week. Anybody knows why?
https://phabricator.wikimedia.org/T136303