Wikitech-l May 2016

113 participants
119 discussions

How to make commits from mirrored Wikimedia repos show up on your GitHub profile
by Bartosz Dziewoński 27 Jun '24

27 Jun '24

I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here. tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.) (Is there a place on mw.org to put this tidbit on?) ------- Forwarded message ------- From: "Brian Levine" <support(a)github.com> (GitHub Staff) To: matma.rex(a)gmail.com Cc: Subject: Re: Commits in mirrored repositories not showing up on my profile Date: Tue, 09 Jul 2013 06:47:19 +0200 Hi Bartosz In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit. The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits. Cheers Brian -- Matma Rex

3 3

bluejeans
by Jeremy Baron 22 Feb '23

22 Feb '23

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

9 16

productivity of mediawiki developers
by rupert THURNER 29 May '17

29 May '17

hi, is there a statistics about mediawiki developer productivity? i just fell over a couple of pages and i am quite impressed i must say: * gabriel, https://github.com/gwicke, 2'300 commits last year * jeroen, https://github.com/JeroenDeDauw, 3'700 commits a year * ori, https://github.com/atdt, 1'700 * james, https://github.com/jdforrester, 1'200 * yuri, https://github.com/nyurik, 900 * matt: https://github.com/mattflaschen, 400 commits rupert

11 14

Deploying the UrlShortener extension to Wikimedia wikis
by Legoktm 12 Nov '16

12 Nov '16

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

3 5

Phab blogs
by Amir E. Aharoni 19 Sep '16

19 Sep '16

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‬

6 6

Crediting the work of our community members
by Jon Robson 07 Jul '16

07 Jul '16

"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…

9 10

Recent authentication session instability (was Re: Update from the Wikimedia Performance Team)
by Bryan Davis 19 Jun '16

19 Jun '16

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

7 13

New mirror of 'other' datasets
by Ariel Glenn WMF 17 Jun '16

17 Jun '16

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/

2 2

Should we switch the default category collation to uca-default?
by Ryan Kaldari 03 Jun '16

03 Jun '16

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

8 9

Campaigns extension / ServerSideAccountCreation log - does anyone still use it?
by Brad Jorsch (Anomie) 03 Jun '16

03 Jun '16

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

4 7

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 2016