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:

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.

Related to T34138: User preference to make images tap to display.

Yessir. Thank you for noting the behavior as of 2018-06-27 in this task!

It looks like we have a generate_watchlist_count.sh script. Does that need to be re-run? If so, are @Marostegui and @jcrespo the only two who can do it or can any shell user?

I agree with what Timo wrote in T189763#4055149.

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?

@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:

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.

Thank you for the task description expansion!

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.

In T187749#4004820, @Anomie wrote:

In T187749#3984345, @Tgr wrote:

I don't think the code would depend much of the specifics of what external version control system is being used. That choice could probably be left to the code maintainers.

I'd be skeptical of having development of on-wiki pages splintered across a multitude of external sites, with attendant PI disclosure and account management issues.

In T121470#4069451, @Yurik wrote:

Also, I don't think shadow namespaces are a good approach, as discussed some time ago at a conference.

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?

I'll defer to @Krinkle's comment in T189284#4057666.

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.

@Nemo_bis wrote the wiki report in September 2013: https://github.com/nemobis/gerrit-reports/commit/93858c6c829e17dc030af001f057f04282879685#diff-47f89ceb825fcc72b0b09ddfbf9f99a4.

@Jdforrester-WMF weighed in on Commons in September 2017, apparently:

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.

In T186463#4020236, @DannyH wrote:

https://commons.wikimedia.org/wiki/Commons:Village_pump#WMF_response_to_proposal_to_uninstall_Flow

Another potential wording: Please choose a password that is more difficult to guess.

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.

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:

This sounds similar to https://www.mediawiki.org/wiki/Extension:Drafts.

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.

If the use-case is "I want to discuss a particular block of text from a wiki page," wouldn't the simplest and quickest implementation be a JavaScript script that copies the text and inserts it into <blockquote> tags in a new talk page section? It could even include a permalink to the exact version of the wiki page. Maybe we should build that first, see if anyone uses it or likes it, and then discuss this significantly larger engineering undertaking.

In T186573#3948883, @Anomie wrote:

<legoktm> We could mention it in the rvprop docs for each parameter
<legoktm> "user: User that made the revision. (note: if the user has been revision deleted, a "userhidden" property will be returned)

In T185417#3915700, @MarcoAurelio wrote:

@MZMcBride I'm talking about the user right, not about restricting who/when/how to create accounts. That has nothing to do with this ticket.

In T2470#3914850, @jeblad wrote:

I wonder if this has been prematurely closed.

[...]

I believe this task should be reopened.

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.

@brion: Should this task still be assigned to you? I think not, given that the concept of "shepherd" has gone away now?

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.

In T73275#3864517, @Reception123 wrote:

Well it should probably be discussed more anyway :D

In T73275#3864514, @Reception123 wrote:

Since this is a WMF-used extension, I assume someone needs to decide this / approve?

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?

In T155678#3863603, @Aklapper wrote:

If you have issues with that, explain your issues if you are interesting in solving issues. Accusing folks of "hijacking" isn't explaining your issue.

In T155678#3861681, @Qgil wrote:

Let's consider the plan for a pilot approved. There has been enough support to start the pilot. Some concerns have been raised, but none of them are considered blockers for the pilot.

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.

Both https://phabricator.wikimedia.org/T180096#3804495 and https://phabricator.wikimedia.org/T180096#3823833 are great replies.

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.

In T181442#3796232, @Nemo_bis wrote:

In T181442#3793269, @Legoktm wrote:

reuse the same footer links that all the other skins do instead of implementing this specifically.

Agreed that MobileFrontend should do so.

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.

In T57385#3769495, @Marostegui wrote:

@MZMcBride I assume this table is to be dropped, right? So I can update its entry on T57385 "Removable" row saying "YES" ?

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.

In T173511#3755509, @jcrespo wrote:

As a pro- I have run many times into people doing the certain summary queries many times independently- instead of those being pregenerated.

In T179628#3755575, @bd808 wrote:

@MZMcBride did you have some reports that used TEMPORARY TABLE as well? I've lost track at this point of who should be involved in some of these conversations.

It's weird to press a button that says "Publish changes" when posting a new section to a user talk page.

Related: T100918: Standardize and document process for mass electronic mailings (Board elections, fundraising, etc.).

In T179877#3739176, @dbarratt wrote:

In T179877#3739173, @Bawolff wrote:

Arguably test(2)wiki, despite its name, is a real production wiki. The surprising part would not be that "test users are real production users" but that users registered at testwiki are considered test users.

Well, all I can say is that I expected a user registered on a test wiki to be a test user (as in, it does not persist for a long period of time). I obviously don't have any data on this, but I think it's reasonable to assume that that would be most people's assumption.

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.