Re-opening this. I'm not sure how much clearer this request could be. It's very explicitly about uninstalling Flow from Commons. That's the title of the task ("Uninstall Flow from Commons") and the task description goes on to further clarify. According to https://commons.wikimedia.org/wiki/Special:Version, Flow is still installed.
Tue, Mar 13
Mon, Mar 12
Thu, Mar 8
@Nemo_bis wrote the wiki report in September 2013: https://github.com/nemobis/gerrit-reports/commit/93858c6c829e17dc030af001f057f04282879685#diff-47f89ceb825fcc72b0b09ddfbf9f99a4.
Wed, Mar 7
@Jdforrester-WMF weighed in on Commons in September 2017, apparently:
Mon, Mar 5
Sat, Mar 3
As far as I know, we have already invested time and energy into creating a proper process to remove Flow from a wiki. We did this with the English Wikipedia (cf. T148611: Plan to disable Flow on Enwiki). From my perspective, adding a configuration variable and additional complexity to the Flow extension and then indefinitely continuing to keep Flow installed on some wikis is a bad approach, both socially and technically. It saddles the wiki with technical debt, with no return on investment, and it creates a higher maintenance burden in order to achieve the same functional result as uninstalling the extension altogether. In the process, rather than respecting the community's wishes, you deliberately subvert them and engender ill will.
Wed, Feb 28
Another potential wording: Please choose a password that is more difficult to guess.
Mon, Feb 26
Another idea is to use the Linter extension and its framework to add a tracking category to redirect pages that have invalid/broken section anchors. This would require getting the Linter extension to work with a non-Parsoid "external service" and would require solving the challenges @Bawolff mentions about manually added IDs.
Sat, Feb 24
What do you think this task is proposing? A whois service operated by Wikimedia Foundation Inc.? Or a Special page in a MediaWiki extension or in MediaWiki core that queries other whois services? Or some combination of the two?
What does further investigation mean in this context? What possible actions can result from this further investigation?
We already have a Special page that exposes a user's IP address information, of course: https://en.wikipedia.org/wiki/Special:Version. It's just not very visible information given the HTML:
Fri, Feb 23
This sounds similar to https://www.mediawiki.org/wiki/Extension:Drafts.
Feb 14 2018
Oh, I think I see what's being described here now. You want the ability to override (replace) the default Wikidata short descriptions that appear in some search results.
I'm having difficulty understanding this task. I found https://www.wikidata.org/wiki/Q1137931, which seems to be the example used here.
For a page such as https://en.wikipedia.org/w/index.php?title=Special:WhatLinksHere/Public_key_certificate&hidelinks=1, it'd be nice to know that "OV certificate" actually links to "Public key certificate#Organization validation" specifically. Outputting this information on the same line as the result seems fine.
Feb 9 2018
Feb 6 2018
Feb 2 2018
Jan 22 2018
Jan 21 2018
I've long been baffled by the high amount of bureaucracy and overhead regarding account creation. We have people who do basically nothing else except create accounts via custom interfaces. Why is this? Does it make any sense to continue to support and enable this practice? For nearly all users, they should be able to create/register an account themselves. Why is a separate group, across hundreds of wikis, needed? Why is separate tooling needed? It doesn't make any sense to me.
Jan 12 2018
Jan 11 2018
@brion: Should this task still be assigned to you? I think not, given that the concept of "shepherd" has gone away now?
Jan 9 2018
Given that any idiot vandal can come along and permanently add multiple rows to the revision table (and thousands of them regularly do!) and given that we're already dealing with other massively large database tables such as pagelinks or categorylinks, it's pretty difficult for me to care about logging growing very moderately to include page creations. I understand and appreciate that disk space and other resources are finite and that large tables can require more maintenance, but this seems like a particularly arbitrary place to draw a line.
In my opinion, it should be possible to look at the logs (i.e., Special:Log/Page_title) of a wiki page in MediaWiki and see a chronology of "major" actions taken to the page. For a standard page, this would include page creation, page renaming, page protections, and page patrolling. For certain pages, this would also include page deletion. We're already doing most of this logging, we're just not including page creation in the logs, somewhat inexplicably. I think we should address this omission in this task.
Jan 2 2018
Dec 30 2017
Thanks for working on this. I'd prefer that the Special page be renamed to "Special:GlobalAccount" or maybe even "Special:AccountInfo" over keeping the existing "Special:CentralAuth" canonical name. That is, could we make "Special:CentralAuth" the alias and then rename this page to have a clearer and less jargon-y page title?
Dec 28 2017
Dec 23 2017
Even though the log won't be complete and won't solve the "show all pages created by this user ever" issue, I think adding a log entry for new page creations makes sense. The current situation where we log page moves and page deletions (and file uploads), but not page creations, is weird. Page creations are important enough to warrant explicit log entries.
Dec 22 2017
Dec 21 2017
Dec 9 2017
Dec 3 2017
Dec 2 2017
I don't think adding yet another configuration variable is reasonable here. We already have way too many configuration variables and we should be focused instead on having sane default behavior.
Nov 29 2017
Nov 27 2017
Nov 18 2017
Nov 17 2017
A user came in to #mediawiki asking about these thresholds. I pointed the user to https://github.com/wikimedia/mediawiki-extensions-Echo/blob/8479687c97bc049f31bd731ee17bd2c40715e20d/Hooks.php#L556.
Nov 16 2017
One concern here is the potential for abuse if people can mask content from internal search.
It's kind of funny that MediaWiki has gone out of its way to abstract namespace names, using namespace IDs so that the namespaces can be localized or renamed somewhat easily and specifically not putting the namespace names into the database. And this effort and architecture gets immediately undermined by having people insist that the namespace names be shoved back in to a database.
Nov 15 2017
Nov 14 2017
It's weird to press a button that says "Publish changes" when posting a new section to a user talk page.
Nov 13 2017
Nov 10 2017
Nov 9 2017
Nov 7 2017
This task is potentially of interest to me. I previously ran a dumb report with the scripts here: https://en.wikipedia.org/wiki/Wikipedia:List_of_Wikipedians_by_article_count/Configuration. I was joining s51334__enwiki_first_page_revisions_p.page against enwiki_p.revision_userindex and it worked pretty well. This report is now broken and users have noticed: https://en.wikipedia.org/w/index.php?title=User_talk:BernsteinBot&oldid=808955710#Not_updated_for_five_days:_List_of_Wikipedians_by_article_count.2C_9k_-_10k.
Nov 4 2017
MariaDB [commonswiki_p]> select @@hostname; +------------+ | @@hostname | +------------+ | labsdb1003 | +------------+ 1 row in set (0.00 sec)
13:41, 4 August 2015 1Veertje (talk | contribs) moved page File:Stuttgart train station..jpg to File:Stuttgart train station.jpg without leaving a redirect
Nov 2 2017
Oct 28 2017
Compare with tools.labsdb, which is a fine enough name, I guess.
Oct 27 2017
Oct 10 2017
For anyone curious, the closest document to an actual "RFC" appears to be https://www.mediawiki.org/wiki/Reading/Web/Projects/NewMobileWebsite.
Sep 28 2017
Sep 14 2017
Sep 12 2017
Sep 5 2017
Sep 4 2017
Aug 31 2017
Just for my notes, one of the angry cats currently lives here: https://www.mediawiki.org/w/skins/Timeless/resources/images/cat-grey.svg?a5931.
Chrome, I think. The issue may have already been resolved.
Aug 30 2017
It's also not clear to me why a trash icon is being used in the date picker. Would an "X" work better? That's what's being used with the media type input already:
Aug 29 2017
Sounds good to me.
Aug 26 2017
Do you think re-using the name "Flow" in the future would be wise? That seems guaranteed to cause confusion. "Flow" as a name for wiki forum discussion software is as nice a name as any. I'm not sure renaming the MediaWiki extension is prudent.
Aug 24 2017
Aug 11 2017
Aug 9 2017
Aug 3 2017
Jul 31 2017
Jul 27 2017
Jul 26 2017
There are user scripts that still reference this old tool: https://en.wikipedia.org/w/index.php?search=mzmcbride+watcher+intitle%3Ajs&title=Special:Search&profile=all&fulltext=1. As Jaime notes, we have https://en.wikipedia.org/w/index.php?title=English_Wikipedia&action=info#mw-pageinfo-watchers now. My guess is that some custom user script that @Samtar loads was recently updated to remove the (broken) link.
Jul 25 2017
It's difficult for me to figure out whether this task is related to Wikimedia wikis or to MediaWiki generally. Are you proposing adding a "jscurator" user group on Wikimedia wikis? If so, I think you'd need to discuss that at Meta-Wiki for a global user group or on a local Wikimedia wiki for a site-specific user group. My understanding for Wikimedia wikis is that we already have https://meta.wikimedia.org/wiki/Interface_editors, which sounds very similar to the "jscurators" group you're possibly proposing here.
Jul 15 2017
Jul 13 2017
I think this task is related to T168480 and https://gerrit.wikimedia.org/r/364007. The unicorn you're referring to is now living in Git history, I believe. If you clone the operations/puppet.git repository, you can run a command like git show ed5e3169f4c538679ebff1294d66046453a6b2b8~1:modules/toollabs/files/40-toolsbeta-bastion-banner.sh to see the previous message.