Hmm, if that goes live where will the repository be?

Added the SRE tag under the assumption that it's an operation question whether such a change is needed at all. In any case, we'd need some careful analysis of how fast editors have to work.

As a compromise, one could encourage people to delete the local versions once they have been imported into the central repository.

I am guessing having a plan for replacing all currently in use magic links with template'd links would be desirable.

All but the last file have a notice at the top right corner that implies they come from https://www.whitehouse.gov/ and thus are usually public domain as works of the US federal government. However, having source information is necessary, also because some videos there may include copyrighted material from others.

Maybe want to check how frequent edit summaries satisfy/don't satisfy the criteria in T2738#34571 so that we know how robust that fix is.

I have my doubts that most communities care about how high their condition limit is, seeing as it has (almost) no effect on the actual project and is mostly a technical variable.

Um, for ''which'' project do you want this? Also, setting page-specific licenses and allowing non-commercial ones seem like two different propositions.

This has been marked as high priority for almost a year; is it a realistic priority?

Depends on what $wgAutoblockExpiry says, which seems to be 24 hours on Wikimedia sites.

My impression was that the Meta Wiki block here is used to prevent appeals/edits when they have no chance of ending well. Is there a need for a three layer (blocked everywhere but Meta - blocked everywhere but Meta user talk pages - blocked everywhere) system over the two layer one which seems to be the current system (blocked everywhere but Meta - blocked everywhere)?

Only thing I know of that would need special logging systems is T68450#2530241 which is a proposal and not (yet) an extension.

Well, that needs some infrastructure to ferret the content to and fro the other projects - and to third parties - for starters.

Massblocking accounts seems like something conceptually unrelated to checkuser, so yeah moving it out of CU makes sense.

editcss, editjs and editinterface are sensitive permissions. Was this aspect discussed and is it really a good idea to have usergroups encompassing these permissions being assigned by administrators in general?

How would that be different from regular page deletion, then?

Is there a community consensus supporting such a proposal?

To my understanding, translating GET to POST via JS is not a problem, applying GET directly to the request is, see T135170#2310146

Is there any problem about this change other than the extra confirmation step?

Sometimes account creations that were held up by the titleblacklist are overridden by an administrator (due to false positives, say). In such cases, logging an IP of an accountcreation attempt may connect it to the future user of such an account. Which was already mentioned in T68450#696668.

Came across this task a while ago. In my mind restricting the visibility to OS or CU is not an acceptable solution; aside from the issues @MarcoAurelio mentioned in T68450#1656957 (and that such a log would keep an IP-account connection listed indefinitely, while CU only keeps it for 3 months at this time), the scope of this log is much broader than just identifying the IPs behind a blacklisted username.

It serves as circumstantial evidence. Also, I've seen people being warned on enwiki for "following around" other editors and thus either engaging in harassment or violating interaction bans or the like.

Would logging the list help with the stalking/hounding issue? That is, there is a (public or semi-public) log where people (either everybody or administrators) can see who is being watched by who.

https://en.m.wikipedia.org/wiki/Special:History/List_of_Internet_entrepreneurs seems to display fine from here. Logged in on my administrator account, that is, but it looks correct when I open it up in private mode as well (where logins don't work).

That seems like a copy of the enwiki policy. I have to wonder if the editors of the enwiki page have been attributed and whether the policy complies with fair dealing - the enwiki policy is based on US fair use which is broader in scope than Indian fair dealing.

Some Wikipedias also have copyright policies which use only laws within a given jurisdiction. For example, the German Wikipedia uses copyright laws in Switzerland, Austria and Germany and the English Wikipedia solely US law. Which means that not all files which are free for these projects are also OK on Commons.

<not a lawyer disclaimer>

@MarcoAurelio: Far as I know, "All rights reserved" would only work if no content is ever copied/derived between the private wikis and the public ones, otherwise you'd end up with a license violation (if copied public->private) or a copyright violation (if copied private->public). One also wonders if using copyright to enforce private-ness is a good idea at all.

Some major copyvio incidents have happened with users having such permissions, at least on enwiki. So I'd say the risk is fairly real.

The uses and functions of CU are pretty well documented in public venues (how long information is available and what kind of information is available) far more accessed than Phabricator, so I second the notion that a private discussion offers no security benefits.

Presumably, to create a way to override that block.

You may want to ask the stewards on Meta if they can give him the "confirmed" user permission; according to https://meta.wikimedia.org/wiki/Special:ListGroupRights OAuth Consumer proposals can be made by confirmed users.

Cascade protection intentionally allows only those people to edit who have the "protect" right. Otherwise one could protect a page simply by transcluding it in a cascade-protected page even without having the "protect" right.

On Commons, usually a subpage of "Commons:Deletion requests/Page under discussion" is used for a deletion request, with a tag being placed on the page being discussed. Same on English Wikipedia, save for different names.

Aye, we don't have bots checking images for copyright violations.

On enwiki, one can ask for feedback in the https://en.wikipedia.org/wiki/Wikipedia:Edit_filter_noticeboard

Is the non-deployment to global wikis a community (i.e needs permission) or a tech (e.g large wikis creating performance problems) issue?

Regarding TitleBlacklist and AbuseFilter, are they needed to block account creations?

Greetings, @Aabdullayev851. As a general rule site requests need a community consensus (or for very small projects, a reasonably publicized proposal with no opposition, if memory serves) for setting changes - is there such support somewhere?

Is it in scope (or technically possible) for the tags to also indicate the original file page on the original wiki?

Something like T31793: Check uploaded images with Google image search to find copyright violations?

At least one "hide" log entry does exist, yes. https://en.wikipedia.org/w/index.php?title=Special:Log&offset=20160201000000&limit=50&type=&user=Future+Perfect+at+Sunrise&page=&tagfilter=&hide_thanks_log=1&hide_patrol_log=1&hide_tag_log=1&hide_review_log=1

Tentatively associating this project so that the task isn't orphaned.

My impression from other tasks along these lines is that shutting off anon page creation is not generally done even when there is consensus for this as it violates fundamental principles of Wikimedia, c.f Limits to configuration changes, T47066: Disable anonymous page creation at tr.wikipedia and T44894: Please restrict anonymous users from creating new pages at sw.wikipedia.

It's a magic word that translates system messages.

But it's not approved yet. LangCom needs to approve it before a wiki can be started about it.

If it's text, might Wikisource work as well? According to https://commons.wikimedia.org/wiki/Commons:Project_scope, text should be used in Commons only if it's in form of text files that are of use to other Wikimedia Projects.

The pertinent policy pages/discussions are https://meta.wikimedia.org/wiki/Requests_for_comment/Disable_local_uploads_on_smaller_wikis and https://meta.wikimedia.org/wiki/Local_uploads_policy, I believe. The policy is still marked as "draft", though.

(Onlookers' comment) That function allows one (through a checkbox) to submit some private data (IP addresses and email, for example) of an account to stopforumspam.com. Seems like this one would be the biggest privacy concern with using this extension on Wikimedia, when users with the permission to submit may use it (if at all) - and who receives that permission. Can't speak of the blocking function itself.

Does it make sense for this function to be part of CheckUser? IP data and watchlists are strictly different things, https://wikimediafoundation.org/wiki/Privacy_policy does mention both separately and I suspect other sites using CheckUser do not lump them together either.

Hope this is the right place (relevant also to T71445): Also adding a more recent post here about one feature one may use on this central repository, if it happens in wiki page form.

I've commented on it.

Take note that the German Wikipedia has no "fair use" policy this feature might violate. Are we sure that PageImages can (technically) fetch non-frees to www.wikipedia.org? It isn't part of a wiki.

A suggestion when checking piped URLs (i.e [URL text] format) and citation templates is to search for the content of "text" and the citation templates in the webpage called by the URL. Working links will usually display some of the material, dead links usually don't.

To this non-sysop, a permission error page and a bunch of greyed out checkboxes display at this URL.

Some commentary is being posted here: https://meta.wikimedia.org/wiki/Talk:Community_Tech/Global_cross-wiki_talk_page

Added two projects. Maybe the edit is processed by the abuse filter before the block status is checked?

That discussion did ask for the auto-welcome to be turned off. Is that the same thing as undeploying the extension?

Looks like the issue is resolved; I guess that if someone else has a problem they can reopen.

Also, under the non-free policy for enwikipedia non-free images are not allowed outside of article namespace (https://en.wikipedia.org/wiki/Wikipedia:Non-free_content_criteria#9) and my impression from deletion discussions is that they can be used only to identify the subject of an article, not necessarily a bunch of subjects that happen to be listed on a list.

Seeing as this seems to be an issue with the CentralAuth function, adding two associated projects.

According to T113148 a Phabricator admin can change an email address, perhaps this is the desired action?

So as to not have this task orphaned.

Probably the former, seeing as other Tool Labs functions still work fine.

Italian Wikipedia has a template https://it.wikipedia.org/wiki/Template:EDP that is required by policy to be placed on all non-free media, as another example. Dunno about other projects.

If detection of non-free images is a concern, https://en.wikipedia.org/wiki/Category:All_non-free_media is a category that is set up (not sure if required by policy, but in practice always observed to my understanding) to list all non-free media on enwiki.

According to https://test.wikipedia.org/wiki/Special:ListGroupRights all users have the ability to change tags there. I know some other main projects also have the ability to tag edits for all users.

Seeing as CU, OS and that functionary stuff is typically associated with that project, I'll add it there as well.