Wikimedia Forum

← Discussion pages

Wikimedia Forums

Archives →

The Wikimedia Forum is a central place for questions, announcements and other discussions about the Wikimedia Foundation and its projects. (For discussion about the Meta wiki, see Meta:Babel.)
This is not the place to make technical queries regarding the MediaWiki software; please ask such questions at the MediaWiki support desk; technical questions about Wikimedia wikis, however, can be placed on Tech page.

You can reply to a topic by clicking the "[edit]" link beside that section, or you can start a new discussion.

Wikimedia Meta-Wiki

• About Meta
• Discussion pages
• Request pages
• Policies and guidelines
• Information and statistics
• Categories
• Help pages
• Meta-Wiki discussion page

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} and sections whose most recent comment is older than 30 days.

Where else to re-propose restricting new users from interwiki-uploading?

Besides enwiki and arwiki, where else can I re-propose? I attempted a Community Wish, which was then "archived"... or rather declined by the WMF as policy-related. The Commons community has favored restricting newest (or non-confirmed) users from crosswiki-uploading files into Commons. So have arwiki and enwiki. Shall I re-propose at dewiki, Meta's RFC, or where else? George Ho (talk) 16:44, 23 December 2024 (UTC)

I think that a request for comment is the best way to go. Having to notify each community individually would be time consuming. I am willing to start a RfC if you agree. This will require a massmessage to every prominent page on every wiki, so that the wider community can share their thoughts here. ToadetteEdit (talk) 16:45, 28 December 2024 (UTC)

@ToadetteEdit: Please feel free to go ahead and start the RFC then. George Ho (talk) 09:36, 29 December 2024 (UTC)

Where is the decline? How is this not solely a commonswiki issue? Isn't that the only project impacted? — xaosflux ^Talk 21:14, 28 December 2024 (UTC)

phab:T370598 is still open. This seems to simply be a commonswiki request of Don't let users upload files to our project using certain methods unless they meet certain criteria, correct? As they have already decided that via community discussion, where is the place that WMF staff has told them their request will be refused? (link please). — xaosflux ^Talk 22:20, 28 December 2024 (UTC)

I suspect by "refused" George Ho simply means nobody has gotten around to doing it. * Pppery * _{it has begun} 00:21, 29 December 2024 (UTC)

It also sounds like this isn't an existing configuration setting to just be toggled, and no one has volunteered to write patches to support it. Are we missing something here @George Ho? — xaosflux ^Talk 05:55, 29 December 2024 (UTC)

@Xaosflux and Pppery: Link to the refusal... unless it's not a "refusal"?: Community Wishlist/Wishes/Disallow or restrict non-confirmed users from cross-wiki uploading files to Commons. George Ho (talk) 09:35, 29 December 2024 (UTC)

Well lets go right to the source: @JWheeler-WMF: is this concept something that the foundation would block for deployment on WMF servers without additional specific actions from communities, if so what? If this is simply a matter of not spending paid developer effort, I'm assuming that wouldn't prevent volunteer effort (along with the thousand and thousands of other backlogged phabricator feature requests). — xaosflux ^Talk 12:44, 29 December 2024 (UTC)

Comment Hi everyone, I opened a discussion since August 25 on arwiki, Most of the discussion participants agree to restrict non-(auto)confirmed users from uploading files to Commons. Gerges ^(Talk) 11:59, 29 December 2024 (UTC)

I agree that cross-wiki uploads are a problem, but I don't think autoconfirmed status is enough. About two years ago I tracked certain cross-wiki uploads for four months, and what I found was that the Upload dialog is used mostly by inexperienced users. Almost half of the circa 250 images were deleted, and there are still many that should be checked. The WMF study confirms what I learned from my data. Editors who upload images straight from the editing window have no understanding of copyright in Wikimedia setting, yet they're "allowed" to upload images with just a couple of clicks. That hurts the copyright holders, the volunteers who clean up the mess, and also the uploaders who get discouraged when their images are deleted, sometimes without them even realizing it. From page 22 in the study, a comment from one participant: "I don't need to know what CC A-SA 4.0 is. I trust Wikipedia to do the right thing." Yikes. Each wiki should be able to decide the userright threshold for cross-wiki uploading in their wiki. -kyykaarme (talk) 17:24, 1 January 2025 (UTC)

Sorry, but global restrictions against non-(auto)confirmed users are the best way forward for all wikis.

Each wiki should be able to decide the userright threshold for cross-wiki uploading in their wiki.

We can't just await every community's decision on how to resolve this, can we? They can individually decide how to set the boundaries between autoconfirmed and extended-confirmed statuses, but every wiki (if not almost) seems reluctant to challenge/oppose proposed restrictions against non-confirmed users. George Ho (talk) 20:04, 1 January 2025 (UTC)

The blocking is not the problem every Commons admin can simply set the current AbuseFilter they are already blocking some uploads to block all uploads from users without the required rights. The problem is that if we do this this way people still see the dialog and get an error message at the end of the process. We need to hide the tool or mark it as unavailable for users without the required rights on Commons. GPSLeo (talk) 19:25, 2 January 2025 (UTC)

I did some testing with a new user account and figured that blocking non-confirmed users from cross-wiki uploading is better than doing nothing. (It takes a bit more "effort" to become confirmed on Commons than what I had thought.) But why not do it with the Abuse Filter? Sure, it's not user-friendly, but the filter already has more than 3 million hits and it matches hundreds of uploads a day. (So what's a few more.) A small portion of the uploaders manage to upload their image later with the Upload Wizard, which is what we want new users doing. If the Abuse Filter option turns out to be a huge disaster, it can be reverted back to the restrictions it has now. kyykaarme (talk) 12:21, 5 January 2025 (UTC)

Started the RFC yesterday: Requests for comment/Restrict non-confirmed users of all wikis from crosswiki-uploading files to Commons. George Ho (talk) 17:25, 5 January 2025 (UTC)

Global user names and profile pages

Is there any meta policy on what can be used as user name and added to a profile page?

Say, a user creates a user page for "John Doe (A inc)" with the content "User account for John Doe, paid by A inc". This is then displayed on all wikis. In some discussion they then concede that they are no longer paid by "A inc" nor is "A inc" aware of some their edits as they are just personal contributions. e 12:46, 19 January 2025 (UTC)

There is a Title blacklist, which extends to user names, so some names would not be able to be registered here, or if registered on another SUL wiki that doesn't use the same block list, you would not be able to make a user page. Our local Changing username refers to w:en:Wikipedia:Username policy, which is probably a good rule of thumb about the kinds of usernames you could and couldn't or should and shouldn't use. —Justin (koavf)❤T☮C☺M☯ 14:04, 19 January 2025 (UTC)

If one actually works for "(A inc)" and contributes for them on some wiki, the username is a good choice. Title blacklist would block it for legitimate uses. e 14:12, 19 January 2025 (UTC)

In this hypothetical - If someone works for ABC INC, and make a disclosed paid editing account "USERNAME (ABC INC)" - then they are no longer am going to make edits in my capacity as a paid editor of ABC INC, I suggest they simply stop using that account entirely - as it would be linked to such disclosed paid editing in the past. Simply make a new account for contributions made in an independent volunteer capacity. Noting on your new account that you previously made disclosed paid edits under account USERNAME (ABC INC) to move forward. — xaosflux ^Talk 14:19, 19 January 2025 (UTC)

"Paid by" might not even mean they are actually employed by "A inc", possibly they just received some funding from them.

How should these points be addressed policy-wise on Meta? e 14:24, 19 January 2025 (UTC)

Special:Contributions/EBjune_(WMF) is simply "locked" with the explanation "no longer work for wmf", Global_blocks#Guidelines_2 allows for blocks where "a combination of local blocks would be [..] inefficient."

Is the locking of accounts of deceased users based on the same? e 16:13, 19 January 2025 (UTC)

It is mostly common sense. Use a dedicated account for each disclosed paid editing/explicit conflict of interest editing engagement that you want to do, use a separate account for volunteer work. — xaosflux ^Talk 16:27, 19 January 2025 (UTC)

WMF could be systematic about it. No need to explain "common sense" to their staff. I don't think I ever came across a WMF staffer who edited with their staff account. Some of their business hours activity on private accounts might be oddly aligned with their staff projects.

So how do we explain it users who continue using their "A inc" account and what action should be taken? e 16:32, 19 January 2025 (UTC)

There is a special relationship between WMF and the project, as the foundation pays for everything here. WMF staffers that also edit as volunteers almost always maintain 2 accounts, one for contributions made in their capacity as an employee, and one for ones in their capacity as a volunteer. WMF staffers edit all the time, to do things like make WMF announcements.

To your question, if someone is making contributions that you think are inappropriate, use the procedures of the projects where this is occurring to review the situation. — xaosflux ^Talk 17:06, 19 January 2025 (UTC)

Well, profiles are created on this wiki.

From this account list, we can conclude that WMF no longer systematically creates accounts for their staff since December 2021. Special:Log/ERoss_(WMF) stopped in July 2023 deactivating (older) accounts. Is there someone else who took over the role? There are still some 500 active accounts with "(WMF)" in their name.

In general, a good way to go about this would be to contact the organization to review these accounts and deactivate them, if they are no longer in use (WMF can do that directly). e 17:25, 19 January 2025 (UTC)

More recent accounts have "-WMF" not " (WMF)": 2nd list (345 accounts). e 18:13, 19 January 2025 (UTC)

It is really no big deal and doesn't need any action. If a former WMF staffer is actively using an unlocked User:%WMF% account, we can address it as it occurs. — xaosflux ^Talk 18:36, 19 January 2025 (UTC)

It's a risk we shouldn't really take. For WMF it might be easy to check (except on weekends), but less so for "A inc". In the meantime, we would end up with confused users. Some "A inc" people might not even know they shouldn't be doing this.

When looking at the WMF accounts, the query also included User:Sylvain_Boissel_WMFr which is blocked, but apparently only here and not globally. e 18:46, 19 January 2025 (UTC)

There is no requirement for WMF or affiliate accounts to be locked. The foundation usually does it, most other affiliates (e.g. WMDE, WMUK...) don't (or only occasionally). Please don't make a big issue out of something which really is no issue at all. Johannnes89 (talk) 19:33, 19 January 2025 (UTC)

It's good practice in general and inefficient to lock them on Meta only.

Luckily I had time to look into this in detail today. It's unclear why one would want to have "A inc" users to continue editing. Once the backlog is handled, it should be fairly low volume. e 19:57, 19 January 2025 (UTC)

If you are not just talking about WMF & affiliates, but also about all accounts belonging to any companies (e.g. "A inc"), then we are talking about hundreds of thousands of accounts. There is no benefit in locking them and no local project has ever called for that. It's just a loot of unnecessary extra work without clear benefit. The foundation is locking their own accounts while also managing permissions of those accounts, they are unique in doing that. I see no reason to bother volunteers with role accounts of all 37 chapters and 153 user groups. Johannnes89 (talk) 20:16, 19 January 2025 (UTC)

There are other affiliates doing it.

For a random "A Inc", one would probably ask for a review only when there are issues. Maybe you haven't read the question at the beginning of the thread. e 20:24, 19 January 2025 (UTC)

I've read your initial question which also doesn't make sense to me, there is really no issue that needs fixing. But after your initial question you've started to ask questions about how WMF, WMDE etc. are handling their accounts, that's what I've been responding to. Johannnes89 (talk) 20:33, 19 January 2025 (UTC)

So what solution do you suggest? Let people put whatever they want on their user page? e 20:39, 19 January 2025 (UTC)

The relevant policies are Global user pages#Content + Meta:Inclusion policy + Meta:Civility (+ local policies and some common sense). If content on a global user page violates local policies, it can either be removed or local projects can just override the global user page (e.g. by creating a blank local one). Johannnes89 (talk) 21:02, 19 January 2025 (UTC)

"But after your initial question you've started to ask questions about how WMF, WMDE etc. are handling their accounts" - can you show the diff for that? I cannot even find any statement by that user that includes the string "WMDE". Φ1.6180339887499 (talk) 23:26, 20 January 2025 (UTC)

I contacted User_talk:DSeyfert_(WMF)#WMF_staff_accounts for WMF. e 18:13, 19 January 2025 (UTC)

I came across a summary by @NahidSultan (WMF): at this RfC: "Trust and Safety follows a strict protocol when it comes to userrights assignment to staff members. The staffer requesting the rights has to provide a use case and the duration they would require the rights. [..] We also periodically review staff user rights as part of the T&S user rights audit." Sounds good. @NahidSultan: when is the next review planned? e 16:11, 20 January 2025 (UTC)

@NahidSultan (WMF): "The staffer requesting the rights has to provide a use case and the duration they would require the rights" - is any of the two, the provided "use case" or "duration" publicly visible? What happens after they have been provided, are the rights then granted? Φ1.6180339887499 (talk) 23:34, 20 January 2025 (UTC)

Correct me if I'm wrong, but it seems like you are the same person using two different accounts with usernames that have mathematical constants. Is that the case? —Justin (koavf)❤T☮C☺M☯ 23:35, 20 January 2025 (UTC)

No. Φ isn't e. e 05:17, 21 January 2025 (UTC)

Thanks. Weird coincidence, I suppose. —Justin (koavf)❤T☮C☺M☯ 08:03, 21 January 2025 (UTC)

I don't think coincidence is the word as even the number of digits match. e 09:19, 21 January 2025 (UTC)

RfC sorting

Category:Requests for comments were mostly sorted by year (current is Category:Requests for comments in 2025) and status (Category:Requests for comments (open)), a few also by project. I added some subcategories there. Projects with just 1 or 2 RfCs might not have a subcategory. RFCs about non-Wikipedia projects are generally just in the category of that project.

There is now also one for Category:Requests for comments about RFCs. All about individual users could go in another subcategory. Category:Requests for comments related to bots has a few.

The oldest ones are in Category:Requests for comments in 2005. e 10:37, 22 January 2025 (UTC)

Dumps are still broken

See Talk:Data dumps. They have now been broken for some time. I know the devs want us to post this to Phabricator, but not all of us want to share our email addresses with the WMF in order to get a Phabricator account. This should have already been caught by internal monitoring and fixed already. Come on devs, please get your act together. And please make it possible to register a Phabricator account without specifying an email address. The Anome (talk) 14:35, 22 January 2025 (UTC)

see phab:T368098#10420647 and phab:T383030. e 14:49, 22 January 2025 (UTC)

I'm glad to see they're on it. Hopefully dumps will restart soon, so dump-driven bots can re-start work. The Anome (talk) 17:36, 22 January 2025 (UTC)

For essential services, shouldn't be an easier way to find out than wading through endless tickets in phabricator. Like a list with everything that should be running and a link to the ticket when it isn't. e 21:07, 22 January 2025 (UTC)

See the recent 2025-01-22 Dumps failed delivery January dumps (enwiki, wikidatawiki) on the xmldatadumps-l mailing list. -- BDavis (WMF) (talk) 00:22, 23 January 2025 (UTC)

Notifications and topics on request pages

Usually I subscribe to a topic I commented on and get notifications when someone responds to them.

For pages like Steward requests/Global and Steward requests/Miscellaneous, one ends up subscribing and being notified about every request there. Is this wanted or just that one hasn't tried changing it? e 20:56, 22 January 2025 (UTC)

Your account settings may have been automatically adding the edited pages/files to your watchlist by default:

1. To make an one-time change, there is a switchable "★" (concrete star sign) to the right of "View history" tab on the top menu of each article page, where you can click to change to "☆" (blank star sign) to opt out from the watchlist at any time to stop receiving future notifications.

2. If would like to make a general change on the notification pattern at any time, simply visit your account's "Preference" page > "Watchlist" tab > "Watched pages" section > deselect the "Add pages and files I edit to my watchlist" box to avoid the unwanted notifications at any time. Good luck and have a great day! Mickie-Mickie (talk) 21:18, 22 January 2025 (UTC)

What I'm looking for is to subscribe to Steward_requests/Miscellaneous#Old_RfC and not Steward_requests/Miscellaneous#Manual_requests. Because now I get notifications about all other requests in that section. e 21:28, 22 January 2025 (UTC)

Oh, tough luck in that case... there seems to be no specifically assigned "[subscribe]" button for the sub-section of "Old RfC" topic, so the system defaults to the subscription of its parent section "Manual requests" – the application by design is out of my reach, sorry. An upper-level guidance or a programmer's input might be required... Mickie-Mickie (talk) 21:50, 22 January 2025 (UTC)

I'm curious if it's intended or if one just hasn't tried to change it (by some setting or by changing the level of the headers). e 21:54, 22 January 2025 (UTC)

At Help:DiscussionTools#Notes, it says "You can only subscribe to a ==Level 2 section==". So, one would need to change the headers to have that level. For Steward requests/Miscellaneous, this seems relatively simple. e 13:43, 23 January 2025 (UTC)

Universal Code of Conduct annual review: provide your comments on the UCoC and Enforcement Guidelines

Please help translate to your language.

I am writing to you to let you know the annual review period for the Universal Code of Conduct and Enforcement Guidelines is open now. You can make suggestions for changes through 3 February 2025. This is the first step of several to be taken for the annual review. Read more information and find a conversation to join on the UCoC page on Meta.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. This annual review was planned and implemented by the U4C. For more information and the responsibilities of the U4C, you may review the U4C Charter.

Please share this information with other members in your community wherever else might be appropriate.

-- In cooperation with the U4C, Keegan (WMF) (talk) 01:10, 24 January 2025 (UTC)