Fri, Aug 3
Tue, Jul 31
Sun, Jul 29
Thu, Jul 26
Is there a maintenance script to add a bunch of users to a user group? It seems like that could potentially be a feature within this script and might be a more common case.
Mon, Jul 23
Another report in the #mediawiki IRC channel just now:
Sun, Jul 22
Sat, Jul 21
I think the relationship between Wikimedia Foundation Inc. and Go Fish Digital has every appearance of being highly problematic, as I outlined here: https://lists.wikimedia.org/pipermail/wikimedia-l/2018-July/090737.html. And I don't think XML site maps are going to help Wikipedia's search engine optimization. Any discussion of improving Wikipedia's SEO has long been taken as a joke given Wikipedia's existing ridiculously high placement in Google search results. That said...
I'd really be interested to know what's potentially libelous about labeling activity such as this as whitewashing (from https://gofishdigital.com/online-reputation-management/):
Has the account approval queue been re-enabled? From the #wikimedia IRC channel this evening:
Fri, Jul 20
This is an old topic. If you search this Phabricator installation for "password length", you'll find a bunch of related commits and tasks. There are also wiki pages such as https://www.mediawiki.org/wiki/Requests_for_comment/Passwords and mailing list posts about this.
Jul 8 2018
Jul 1 2018
Jun 28 2018
Yessir. Thank you for noting the behavior as of 2018-06-27 in this task!
Jun 22 2018
Jun 21 2018
Jun 19 2018
I agree with what Timo wrote in T189763#4055149.
Jun 18 2018
Am I understanding this issue correctly? The current behavior when a new user registers a Wikimedia Phabricator account to file a bug or report some kind of issue is presenting them with this screen?
I tried to create a test account just now and a verified e-mail address is required. Since when?
An issue that impairs the ability of a user to perform basic functions such as reading a task is a high priority to get resolved. Can you explain why you reset the priority here?
Jun 17 2018
@Framawiki notes that the "watchlist_count" table has gone missing at https://en.wikipedia.org/w/index.php?title=User_talk:MZMcBride&oldid=846197628#About_watchlist_table_on_replicas. I can confirm:
Jun 11 2018
Jun 10 2018
Jun 8 2018
May 23 2018
May 12 2018
I changed "reCAPTCHA" to "CAPTCHA" in the task title because we've typically avoided reCAPTCHA specifically, in favor of using our own CAPTCHA on the wikis.
May 11 2018
May 8 2018
May 4 2018
Apr 20 2018
Mar 29 2018
Thank you for the task description expansion!
Mar 28 2018
Since the "Removable" table column is not sortable, perhaps splitting the table into multiple tables would be useful? The current mix of removed, unremovable, and pending removal tables is somewhat confusing to digest.
Mar 21 2018
It's not totally clear to me how this task is distinct from older tasks such as T66475: Make crosswiki bits and pieces truly global (tracking). Is there something new here?
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.
Mar 13 2018
Mar 12 2018
Mar 8 2018
@Nemo_bis wrote the wiki report in September 2013: https://github.com/nemobis/gerrit-reports/commit/93858c6c829e17dc030af001f057f04282879685#diff-47f89ceb825fcc72b0b09ddfbf9f99a4.
Mar 7 2018
@Jdforrester-WMF weighed in on Commons in September 2017, apparently:
Mar 5 2018
Mar 3 2018
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.
Feb 28 2018
Another potential wording: Please choose a password that is more difficult to guess.
Feb 26 2018
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.
Feb 24 2018
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:
Feb 23 2018
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.