Policy Technical Proposals Idea lab WMF Miscellaneous 
The WMF section of the village pump is a community-managed page. Editors or Wikimedia Foundation staff may post and discuss information, proposals, feedback requests, or other matters of significance to both the community and the foundation. It is intended to aid communication, understanding, and coordination between the community and the foundation, though Wikimedia Foundation currently does not consider this page to be a communication venue.

Threads may be automatically archived after 14 days of inactivity.


« Archives, 1, 2, 3, 4


What we've got here is failure to communicate (some mobile editors you just can't reach)

Further information: WP:THEYCANTHEARYOU

Summary of overall issues: User:Suffusion of Yellow/Mobile communication bugs ProcrastinatingReader (talk) 03:08, 21 March 2021 (UTC)[reply]

Over a year ago, I reported two problems to the WMF:

(1) Logged-in mobile web editors are not given a very strong indication that they have new messages. There's just a little number in a red circle. It's similar to what many other sites use for "Exciting! New! Offers!" and other garbage. There's nothing to say "A human being wants to talk to you."

(2) Mobile web IP editors are given no indication at all that they have new messages. Nothing. Every template warning, every carefully thought out personal message, and everything else just disappears into a black hole, unless the user stumbles across their talk page by accident, or switches to the desktop interface.

But I get it. Bugs happen. They can be fixed. Instead both problems were marked as a "low" priority.

This is baffling. Problem 1 is a serious issue. Problem 2 is utterly unacceptable.

We are yelling at users (or even dragging them to WP:ANI) for "ignoring" our messages that they have no idea exist. We are expecting them learn without any communication all sorts of rules from WP:V to WP:3RR to WP:MOS that don't even apply to most other sites on the web.

Until they get blocked, of course. What a terrible experience. How are we supposed to gain new users when their very first interaction with a human is being told to f--- off, for "ignoring" a message they didn't even know about?

WMF, please explain to this community why this is a "low" priority. One year is long enough. Suffusion of Yellow (talk) 22:55, 16 February 2021 (UTC)[reply]

I'll just note that a majority of our users are accessing us on mobile so this isn't a niche problem either. Best, Barkeep49 (talk) 23:26, 16 February 2021 (UTC)[reply]
Wow. Neglected high-priority phabricator tickets are nothing new, but this is another level. Jimbo Wales, this deserves your attention. ((u|Sdkb))talk 08:11, 18 February 2021 (UTC)[reply]
I would like to point out that the majority of messages left to IPs will never reach the user in question anyways, ESPECIALLY on mobile connections. Due to shared ips, the chance of someone else viewing the message before the person you are trying to reach is probably about 50/50. I realise that sometimes leaving a message is effective, but there are serious questions about all the cases where it is simply leaving a very confusing and often aggressively toned message to a completely different user just randomly reading an article at the busstop a month later. What we really need is a completely new way to leave messages to anonymous users. Possibly with some sort of very short lived session or something. But as ip users are more or less stateless (the software concept) right now, that is probably hard to implement. —TheDJ (talkcontribs) 09:26, 18 February 2021 (UTC)[reply]
@TheDJ: I would have no objection to expiring the OBOD if the talk page isn't clicked in a few days. Many messages come only a few minutes after the user makes the edit; most mobile carriers aren't that dynamic. Suffusion of Yellow (talk) 17:14, 23 February 2021 (UTC)[reply]
Equally baffling is that mobile app users do not see any notifications, including no talk page notifications, logged in or out. The link to talk is buried within the settings. Official mobile apps! They don't even see block messages! See T263943 and others. This block review and also this discussion where an editor also tested block messages. The editor was blocked multiple times for something that was not their fault but that of a poorly thought out app. They are not alone. Quote from phab task: Conclusion: Using the app is like being inside a bubble, without contacts with the exterior. It's no wonder there's so much people complaining here that using the app caused their Wikipedia account to be blocked, for reasons they don't understand. ProcrastinatingReader (talk) 09:33, 18 February 2021 (UTC)[reply]
I have filed T275117 and T275118. ProcrastinatingReader (talk) 10:22, 18 February 2021 (UTC)[reply]
I'm always surprised that anyone manages to edit with the mobile interface. As another example, if you're not logged in, there is no way to access the talk page of an article, or even any indication that it exists. If an unregistered user makes an edit and is reverted with a common summary like "see talk", I imagine many will have no idea what's going on. – Joe (talk) 09:39, 18 February 2021 (UTC)[reply]
@Joe Roe: Sorry if this is not the right place, but I'm trying to find out why you can't access an article talk page if you're not logged in (on mobile). This was the only mention I could find. Do you know if this issue is being addressed anywhere? Cheers, Fredlesaltique (talk) 07:50, 18 June 2021 (UTC)[reply]
@Fredlesaltique: AFAICT the talk page link is a feature of mw:Reading/Web/Advanced mobile contributions (see § January 14, 2019 - Getting started with Talk page links), which is currently only available to logged in editors (I don't know why, though). See also phab:T54165, though that doesn't seem very active. – Rummskartoffel 11:30, 18 June 2021 (UTC)[reply]
The mobile web, and mobile apps, appear to be designed for readers and not writers. Having used mobile web occasionally, I think it's usable for logged in editing, but I do have to switch to desktop every now and then. I've used the iOS app only for a test - it is not usable for editing imo. ProcrastinatingReader (talk) 09:55, 18 February 2021 (UTC)[reply]
The number of edits I have made with the mobile web or app interface is most likely less than 50 (out of 13,000). Even for reading, the mobile interface is borderline unusable. I do frequently edit from my 4-inch cell phone screen (in fact, I'm doing that right now)... but I use the desktop version. —pythoncoder (talk | contribs) 14:04, 18 February 2021 (UTC)[reply]
I agree with Joe and have always found Cullen328 to be a bit of a superhero for being who he is on a mobile device. Best, Barkeep49 (talk) 18:19, 18 February 2021 (UTC)[reply]
Thanks for the kind words, Barkeep49, but I simply use the fully functional desktop site on my Android smartphone. It's easy. If I was the king of the Wikimedia Foundation, I would shut down the mobile site and apps, because they are an ongoing impediment to serious editing. RoySmith, there is no need to invest more effort (money) on a good editing interface for mobile, because that interface already exists - the desktop site. Just change its name from desktop to universal or something, and the problem will be solved.Cullen328 Let's discuss it 18:34, 18 February 2021 (UTC)[reply]

Question - Is this something that could be cured by bringing back the "Orange Bar of Death"? Mjroots (talk) 16:31, 22 February 2021 (UTC)[reply]

@Mjroots: the orange bar of death never went away. Last I check, it's still there for non mobile IP editors. That's why they get an indication of new messages. AFAIK, it was never there for the mobile web editor, that's probably part of the problem. Nil Einne (talk) 03:06, 23 February 2021 (UTC)[reply]
What no one has ever told me is why it was left out in the first place. Was it a simple oversight? Did someone have such a little understanding of how the sites work that they thought communication was unnecessary? Some other reason, that I'm not thinking of? This is the most confusing part. Suffusion of Yellow (talk) 17:14, 23 February 2021 (UTC)[reply]
I wish it could be brought back for all editors. Looks like bringing it in for IPs on mobiles could be the cure here. Mjroots (talk) 18:40, 23 February 2021 (UTC)[reply]
Maybe WMF cares more about the app's aesthetics than they do its functionality (hence why they made dark mode the default even though it ruins tables by making their text blend in with the background, and why the mobile wikitext editor is missing features as basic as template insertion so it can fit on the screen). ☢️Plutonical☢️ᶜᵒᵐᵐᵘⁿᶦᶜᵃᵗᶦᵒⁿˢ 20:33, 13 December 2021 (UTC)[reply]
This is alarming but not surprising. Since I do a lot of question answering at the Teahouse, I'll point out a random IP's post from yesterday, in the same vein as some of the sentiments noted above: "Also, why don’t they get rid of the mobile view? So terrible!".--Fuhghettaboutit (talk) 00:29, 24 February 2021 (UTC)[reply]



When you spend three times as much money without the actual job you were hired to do changing, you start to focus more on spending all of that money instead of on doing your job. When you hire a boatload of new employees when the current bunch are more that enough to do the job, those new employees find something to do, whether that something needs doing or not. I'm just saying. --Guy Macon (talk) 18:31, 8 March 2021 (UTC)[reply]

Hi everyone, thanks for raising these issues, and documenting the problems so thoroughly. We're going to get a group of people from the Product department together next week to talk about these problems, and see what we can do about it. I'll let you know what we figure out. I appreciate you all bringing it up. — DannyH (WMF) (talk) 22:17, 7 April 2021 (UTC)[reply]

Thank you, Danny! I look forward to seeing what you come up with. Suffusion of Yellow (talk) 19:55, 9 April 2021 (UTC)[reply]

26 April update

Hi everyone, we talked in the Product department about the issues that are being raised in this conversation.

We're currently showing notifications to logged-in editors on mobile web, which appear as a number in a red circle at the top of the page. It's the standard design on mobile that indicates that there are messages for you.

We've been reluctant to do that for IP editors on mobile web, because mobile IPs shift around so much. Desktop IPs can change as well, so there's some risk of not reaching the right person on desktop, but the risk is a lot greater for mobile. People walk around with their phones and move from one wifi or cell tower to another. We haven't wanted to show a message bar to a mobile reader who happens to be picking up the same cell tower or wifi access point as someone who made an edit a year ago.

On the apps, the Android team has released improvements to the talk page experience in February and March. Echo notifications currently exist in the Android app, and user talk pages are also discoverable through the watchlist. Users can access article talk using a dropdown menu at the top right; you can see how this works in this walkthrough gif. There are some further improvements planned, including enabling in-line replies, and building onboarding features to help people discover both the watchlist and talk pages. You can learn more, and ask the team questions, on their Android communication project page.

The iOS team is also looking at improving the talk experience on their app. They're currently in the initial design and technical planning phase for enabling Echo notifications on iOS. Later this year, they're planning to fill in some of the missing collaboration features on the app, including making editing tools and talk pages more prominent.

There are some different things to discuss here, and I'd like to know what you think. — DannyH (WMF) (talk) 18:47, 26 April 2021 (UTC)[reply]

What are we doing about the block notification messages and the other edit screen notices?? —TheDJ (talkcontribs) 19:02, 26 April 2021 (UTC)[reply]
@DannyH (WMF):
  • About IP users: As myself and others have suggested, there's a solution to the "random unrelated reader" problem: Don't show the alert if the new message is over X days old. Or (if the privacy policy permits) set a cookie anytime they click "publish", and only show any new message alert to people who have edited in the past X days. Or even both. I think most people already understand that messages sent to IP users are not guaranteed to reach the user. But we do expect that when 1.2.3.4 edits Foo, we leave them a message, and then an hour later 1.2.3.4 edits Foo again, that they've seen our message. That's the disconnect between expectations and reality that's been bothering us. You're also making the assumption that users on mobile devices are also on mobile connections. What about the phone user on their home WiFi? That could be stable for months.
  • About logged in users: No, the red circle is not (only) the standard "you have new messages" alert. It's also the standard "we have some spammy garbage we'd like to sell you" alert. Of course experienced users know Wikipedia doesn't do that, but inexperienced ones are the people we're trying to reach. As matter of habit, I ignore similar-looking notices on unfamiliar websites.
  • About the Android app: Again, what about spam-weary users who have turned off push notifications. With no in-app alert, how are they supposed to know that there is an urgent message on their talk page?
  • About the iOS app: If users are currently in a total bubble, why enable editing at all? Why not wait until basic communication features are implemented, and keep the app read-only in the meantime?
I'm really getting the impression that the WMF thinks that user communication is an afterthought. Y'all didn't just forget one communication-related feature, you forgot most communication-related features. How did this happen in the first place? Suffusion of Yellow (talk) 20:15, 26 April 2021 (UTC)[reply]
@DannyH (WMF): Thank you for your time working on and responding to this. I recognize the difficulties in developing a good software product for the diverse projects that rely on MediaWiki software. However, I am deeply frustrated that this has been allowed to occur. Ensuring that existing community mechanisms for communicating with other editors, especially new editors, continue to function is a bare-bones requirement for any Wikimedia minimum viable product. To paraphrase Risker's related thoughts on Wikimedia software development in a different area: the intention behind a lot of this has been good, but sometimes I think engineers have no idea how our projects actually function and how significant some of these problems are. Frankly, if logged-out mobile editors don't have an interface to see messages, then the logged-out mobile interface should not contain editing functionality. Otherwise, this software is wasting many many hours a day of volunteer time tracking down and reverting and warning (not that they'll see the warnings) and blocking good faith IP users who are oblivious to community norms and this software is wasting just as much time spent by new editors trying to help out but unable to access any feedback about their editing. Best, KevinL (aka L235 · t · c) 10:01, 28 April 2021 (UTC)[reply]
Let me make more explicit a position that I suspect a broad swath of the English Wikipedia community may support: If the Foundation feels that it is impractical to build a communication system to communicate with logged-out mobile editors, then logged-out mobile users should be required to log in to edit. Wikipedia is a collaborative project; we simply cannot allow users to edit without being able to communicate with them effectively. KevinL (aka L235 · t · c) 10:05, 28 April 2021 (UTC)[reply]
Absolutely, thank you for the clear description of the situation. I was thinking of going rogue and just blocking any uncommunicative user/IP after a single warning. That would avoid mega-frustration and wasted time and would focus minds on fixing the problem rather than ticking boxes for the number of new edits from new users. Johnuniq (talk) 10:23, 28 April 2021 (UTC)[reply]
@DannyH (WMF): If fixing all the issues is going to take some time, and you don't want to disable editing entirely, can you break the Android app a bit more? See this. Using that hack a message can be conveyed to iOS users but the same can't be done for Android. It shouldn't take long to make the tweak, which would at least allow a custom mechanism to communicate a message to Android editors. Perhaps directing them to login via their browser app, for example. ProcrastinatingReader (talk) 03:16, 30 April 2021 (UTC)[reply]

Hi everyone, thanks for posting more thoughts. As usual, there's lots to respond to here.

It's true that the apps are late to including talk page features. That's partly because we didn't have a clear strategy for how we could improve talk pages sitewide — we knew that we wanted to improve the usability of talk pages, but the Flow project was not successful, and we knew that we needed to find a new direction. We determined that new direction with the Talk Pages Consultation in mid-2019, and then the Editing team started their Talk pages project to build tools for replying, starting new discussions and being notified when people comment in specific talk page sections. (If you haven't yet, you can turn on the new tools for replying and starting new discussions in the Beta preferences tab.)

As part of that project, the Editing team has developed the ability to break down wikitext conversations into individual comments, and all of that work is now informing the work that both the Android and iOS teams are doing to improve the talk page experience on the apps as well.

Now, one of the things that we do when a product team is working on a feature is to look at both the usage numbers and the revert rate for edits that are made using the feature. If the revert rate is higher than average, then clearly there's a problem with the feature that we need to fix.

Comparing the revert rates across desktop, mobile and apps, we see a similar pattern with both logged-in and logged-out editors. Looking at the last 30 days on English Wikipedia, mobile web edits have a higher revert rate compared to desktop edits. That's true for both logged-in users (10.2% revert on mobile web to 3.7% revert on desktop) and IP editors (35% revert on mobile web to 22% revert on desktop). Edits made through the apps are closer to the desktop revert rate. For logged-in app users, about 6.5% of app edits are reverted, compared to 3.7% on desktop. For IP app users, it's around 24% app edits reverted vs 22% IP edits on desktop. So while every single revert is a waste of time for somebody, we don't see app editing causing significantly more problems than desktop editing, especially compared to mobile web.

As I said earlier, the Android team has recently released improvements for talk pages just last month, and has plans to continue work on it, and iOS will be working on communication features later this year. So while those teams had a late start on these features, they are currently getting attention.

Some more specific points: Suffusion of Yellow, your suggestion about offering a time-limited message is interesting, and started a conversation in a couple of teams, so thanks for bringing that up. For your question about the assumption that mobile devices are used on the go: yes, there are definitely people who use mobile devices on stable IPs. However, it's a lot more likely that any given mobile device will be on an inconsistent IP than a desktop device.

Regarding people who ignore red circles and turn off push notifications, it's true that banner blindness is very strong, and that's a problem for web designers in general. However, we've found that when someone takes a specific step like turning off push notifications, responding with larger and more insistent notifications is not likely to help.

I'm happy to keep talking, if folks have more questions or suggestions. DannyH (WMF) (talk) 18:47, 30 April 2021 (UTC)[reply]

Danny, I'm intrigued and puzzled by your statement here. You have people here (and in many previous conversations) expressing frustrations at an inability to communicate with users. Some prior discussions have been about specific editors who have a mixture of constructive and troubling edits which are the kind of editors who can frequently be helped to stop the troubling edits. Your response, if I'm understanding it correctly, is that because there is no difference in revert rates for these editors compared to those on other platforms that the lack of communication doesn't matter. This might be true but would be a radical shift in culture in terms of how we handle disruptive editing and would be at odds with other foundation sponsored initiatives, including obligations to help new users in the UCoC. Can you help me either understand where I am failing to get what you're saying or if I do understand what you're saying how we, as an enwiki community, can square this circle. Best, Barkeep49 (talk) 19:17, 30 April 2021 (UTC)[reply]
Hi Barkeep49: What I shared about the revert rate was in response to a couple of things. First, Johnuniq commented on the fact that I'd only talked about edits from app users, and didn't acknowledge the impact on the editor community who have to clean up a mess. (The part about "ticking boxes for the number of new edits from new users.") It was also a response to the suggestion made in a few places that the apps shouldn't allow editing if the communication features aren't up to desktop standard. My point is that we do try to take the impact on the community into account, by making sure that features that we build don't result in a mess that's noticeably bigger than the mess that already exists.
But yes, this conversation is mostly about reaching specific editors who might be helped to stop making troubling edits. I agree that the communication features are important, and both apps teams have been and will continue to work on communication features. Some of the problems that we're talking about have already been addressed on Android; I think that in the case mentioned in the thread on Jimbo's talk page, they would have received talk page notifications as of March 30th — but that was sadly too late to reach that user. These conversations have inspired us to talk more about the communication features as a product team, and I appreciate the folks who have brought it up here. — DannyH (WMF) (talk) 20:37, 3 May 2021 (UTC)[reply]
DannyH (WMF), the desktop site is fully functional on modern mobile devices. The solution to this problem to shut down all apps and sites that are not fully functional, and redirect all users to the desktop site, which should be renamed the "fully functional site". That would save enormous amounts of money and draw a gigantic worldwide pool of new editors into the WMF free knowledge websites. Right now, we are erecting barriers to collaboration with people editing with mobile devices, and that is terribly sad. I speak as an editor who has been editing and more recently administrating with Android smartphones for ten years. 99+% of my edits are on smartphones. The WMF is spending buckets of money on a problem that does not exist, and making matters worse in the process. Cullen328 Let's discuss it
While this may have been a hypothetical, I would personally oppose such a proposal, solely because while the desktop site is functional on mobile, the text is still really small. The probably-crazy solution that immediately comes to mind is to switch the site skin to the new Responsive MonoBook, because that would display the content at a reasonable size on mobile while presumably allowing IPs to see the Orange Bar of Doom. (I haven't tested this, but I assume it works because unlike Minerva, MonoBook is maintained by the editing community.) Also, there are some plans to make Vector responsive too, but I don't know anything about that. —pythoncoder (talk | contribs) 22:19, 5 May 2021 (UTC)[reply]
At least a couple of us have disagreed with your view a few times, Cullen. The desktop site is not at all well optimised, and the apps are better for reading already. The solution is not to delete everything, rather than fix the issues. It's such an overly simplistic view anyway; compare this to this in terms of page size. I mean, the suggestion just isn't considerate of all the language projects and global users, and is just so unlikely to happen that it distracts from real solutions, which really is to disable editing in the interim / provide a roadmap, or at least allow the community to do that if it wishes to by consensus. ProcrastinatingReader (talk) 01:36, 6 May 2021 (UTC)[reply]
hear hear. —TheDJ (talkcontribs) 08:35, 6 May 2021 (UTC)[reply]
I agree that just nuking mobile and forcing everyone to use desktop is the wrong solution. What many people don't quite grasp is that not everyone is like them. They assume that because they have a large screen smartphone and a fast connection, then of course everyone does, and if a desktop website works for them then of course it works fine for for everyone else.
In the real world some people access Wikipedia on old flip phones, satellite phones with huge packet delays, rugged industrial phones with tiny screens, and ancient computers using modems.
I recently finished a preliminary design for a major toy manufacturer that includes a very low performance web browser with a really cheap display. That one got cancelled (90% of toys that make it to prototype do) but sooner or later you are going to see something similar in the toy aisle at Wal-mart for $29.95 USD. --Guy Macon (talk) 11:02, 6 May 2021 (UTC)[reply]
@DannyH (WMF): is this a joke or am I misunderstanding? You're saying that it's a deliberate design choice that mobile app editors are not seeing the messages being left for them? How do you suggest that we contact CejeroC, or does it not matter that thousands of volunteers' time (both newbie and experienced) are being wasted? — Bilorv (talk) 23:33, 29 May 2021 (UTC)[reply]
Hi @Bilorv: I think that you're misunderstanding slightly. It's a deliberate design choice not to show notifications for IP editors on mobile web, because there's a higher chance that we'll show the notification to the wrong person. It's more likely that a mobile web edit was made by someone who's moving around, so the notification would appear for a random reader who happens to be picking up the same cell tower or wifi access. We are showing notifications for logged-in editors on mobile web, and both logged-in and logged-out editors on the Android and iOS apps.
CejeroC was an editor on the Android app, which added talk page notifications in some changes made in February-March 2021. This was too late for the people trying to contact CejeroC, unfortunately, but it should be easier to contact Android app editors from now on. — DannyH (WMF) (talk) 18:35, 4 June 2021 (UTC)[reply]
Thanks for the reply, DannyH (WMF). I'm glad that I was misunderstanding, as the other option was deeply undesirable. My new questions are as follows: you're saying that it's a deliberate design choice that unregistered mobile web editors are not seeing the messages being left for them? Where can I see the WMF's data on the percentage of IP talk page messages that would have been seen by someone who was not the intended target, versus the percentage that would have been seen by the intended target? And how should a volunteer attempt to get in contact with an IP editor tagged as making mobile web edits, particularly when the IP has clearly been static for a non-trivial amount of time (based on the length of the editor's contributions)? — Bilorv (talk) 18:57, 4 June 2021 (UTC)[reply]
@Bilorv: I wish we could get data on who sees which notifications; it would make life easier. Unfortunately, we don't know. (There are a lot of stats that are typically collected by other big websites that we don't collect out of respect for users' privacy.) The judgment call that we're making right now is based on our understanding that a large number of IPs move around and are unreachable even on desktop, and that problem is obviously magnified for mobile IPs. For the question of how a volunteer could get in contact with a stable mobile IP editor, one potential workaround would be to leave them a message on the IP's talk page, and then when you revert one of their edits, you put a link to their talk page in the edit summary. That's obviously a hack, but IP editors having a talk page at all is kind of a hack. — DannyH (WMF) (talk) 20:58, 8 June 2021 (UTC)[reply]
I don't believe that the users I'm thinking of are aware that there's a page history—in fact, I often see behaviour that makes me think they are going "my edit didn't go through, why is it not there when I look again a few hours later?" after a revert (and I don't think the layout makes the page history obvious). I need to send a big fuck-off banner saying "SOMEONE IS TRYING TO TALK TO YOU ABOUT THE EDIT YOU DID" in order to engage attention. Unfortunately, no such functionality exists. I do appreciate the privacy afforded to readers and editors, but you're making a judgement call based on not very much—certainly not what the community wants—and using a 2001 IP-based system is not the solid foundation for communication that I need. (I understand the WMF is planning to anonymise IPs but not change them as the method of tracking unregistered contributors.) I don't necessarily want us to start tracking people with cookies, so I know every solution comes with a disadvantage, but this situation is honestly ridiculous. So much of my time is wasted with sending out messages to people who will never see it, and the alternative is just undoing what they did without explanation (what message is that to send to a newcomer? How can we get new editors involved by doing that?). — Bilorv (talk) 21:25, 8 June 2021 (UTC)[reply]
@Bilorv: As you say, the 2001 IP-based communication system is very flawed. The big f'off banner doesn't even work for desktop IP editors all too often, because IPs shift around, or just because the person who's making the edits doesn't understand or doesn't respond to talk page messages. For mobile IP editors, you're even less likely to make a connection. I think that if the folks who created MediaWiki twenty years ago were creating it today, they probably wouldn't use IP addresses as the foundation for communication, but this is the legacy system that we have.
I do think that the work that the Anti-Harassment Tools team is doing on "IP masking" will help with this, especially if we use cookies on mobile devices to associate the device with an auto-generated user name. There's a lot of planning and discussion left to do on the IP masking project, and figuring out how to communicate with "masked" IP editors will be one of many things to figure out. — DannyH (WMF) (talk) 22:42, 9 June 2021 (UTC)[reply]
@DannyH (WMF): We are showing notifications for ... both logged-in and logged-out editors on the Android and iOS apps. Can you link me to the phab task where the the lack of iOS notifications was fixed? I don't have an iOS device handy and phab:T274404 and its subtasks suggest work is just getting started. Also, the Android app still isn't showing me any alerts for logged-out talk page messages. And least no one has responded to my simple question at phab:T95396. So what have I missed? Suffusion of Yellow (talk) 19:37, 6 June 2021 (UTC)[reply]
@Suffusion of Yellow: Sorry, you're correct about iOS. I just checked my own post at the top of the section and realized that I made a mistake when I replied to Bilorv. Android has already made the changes; iOS is getting started on that work. I looked at your question on that ticket, which I think was not the correct ticket for that bug report — it looks like that ticket was closed in May 2020, and may not have been the right ticket anyway. I just asked the PM to take a look at it, and tell me where that report should go; I'll let you know when I get an answer. — DannyH (WMF) (talk) 21:06, 8 June 2021 (UTC)[reply]
Ah, I see that you've already made that connection on phab:T276147. At least, I think so. Let me know if I'm not correct. — DannyH (WMF) (talk) 21:22, 8 June 2021 (UTC)[reply]
@DannyH (WMF): So I understand there is still a subset of logged-out mobile editors not getting talk page notifications, yet they are still editing? This is unacceptable.
As has been stated above, if an interface does not have basic communication capabilities, then the interface should not have editing capabilities. --DB1729 (talk) 02:17, 8 June 2021 (UTC)[reply]
@DB1729: I understand your dismay; I agree that communication is essential for productive wiki collaboration. I think that at the root, this is actually a flaw in the concept of allowing people to edit without an account on Wikipedia. Twenty years ago, it may have been roughly accurate to assume that IP addresses were mostly stable, because everybody had a desktop and mostly a dial-up connection, so if you posted a message for a particular IP address then you were likely to reach the same person. Today, the use of laptops at wifi hotspots and phones and tablets using cell service has basically broken that model. A few years ago, we reached the point when mobile pageviews hit 50% of our traffic, and by now the majority of Wikipedia readers are accessing our site with a mobile device.
I think that your suggestion of restricting IP editing on mobile is an interesting one, and it's possible to argue that that should apply to desktop as well as mobile. But that's a much bigger conversation, and I don't think we'd be able to settle it here. — DannyH (WMF) (talk) 21:19, 8 June 2021 (UTC)[reply]
I don't have the data, but edits I make using my phone usually come from the same IP (my home or work wifi) that my desktop edits come from. (I use responsive monobook, so my phone edits count as "desktop"). What's inhibiting communication with some mobile editors is not that their IP changes, it is that the software they use is not fit for purpose. Do you know any of the people who can fix the software? —Kusma (talk) 08:28, 10 June 2021 (UTC)[reply]
@DannyH (WMF): Speaking of notifications Danny, for some reason I never got that ping from your last reply.(ironic) Did you get a confirmation it was sent? Thank you for the reply and for sharing your thoughts. In the meantime, yes I understand the dynamic IP problem, but these users are notified (I hope) when their IP addresses are blocked, are they not? Presumably when they open an edit window? Similarly, a talk page notification could be displayed only when there is an attempt to edit. It could then time-out or become invisible after a set duration, much like I assume a block notice will disappear once the block expires. DB1729 (talk) 15:48, 12 June 2021 (UTC)[reply]

#suggestededit-add 1.0

I think it would be a good idea to also bring up what I think is the related issue of the #suggestededit-add 1.0 process, as this seems to a mobile idea. See for example Jomart Allaguliyev (talk · contribs), a new mobile user who has made over 1000 edits exclusively through this process. Most are fine, but some are wrong, and some are almost nonsensical. Sometimes they re-do and worsen their own better work! [2] [3]. They've also a few times made the same edit twice after being reverted [4][5], which feels like something popped up and they simply repeated the action? The only documentation seems to be on Wikidata, so it is unclear how exactly these are happening or where they're happening from. There is an old Phab task (T227623) closed suggesting the process is working as intended. CMD (talk) 02:42, 22 April 2021 (UTC)[reply]

I'm confused about how this is a suggestedit issue. That editor was given exactly one warning, as far as I can tell. If an editor is editing disruptively, the first step is to notify them on their talk page, isn't it? (Also, I have fixed your broken link above.) – Jonesey95 (talk) 04:26, 22 April 2021 (UTC)[reply]
Thanks for the fix. The user is not editing disruptively, on the whole. The point is, this user's edits are being solely guided by some program out there providing editing suggestions to new users, provided by WMF, of which there seems to be little documentation. How is it not a suggested edit issue, when any potential disruptiveness would presumably be due to this feature? It would be nice to have documentation. If the edit summaries are automatically generated, why don't they include a wikilink to such documentation? The Mediawiki FAQ states only that it is to "Add short descriptions to articles that are missing descriptions", which is clearly not the case given these are edits to existing short descriptions. CMD (talk) 09:14, 22 April 2021 (UTC)[reply]

As an update here, the page Wikipedia:Suggestededit-add 1.0 has been created by Guy Macon, but I'm still seeing edits like these ones which add the short description "Overview of the topic", and am no less enlightened as to whether these somewhat meaningless descriptions are being suggested by Wikimedia software. CMD (talk) 05:21, 13 September 2021 (UTC)[reply]

Another block. Any progress?

[6] Didn't seem like there was any other option. Any progress on resolving these issues? As I requested somewhere, any chance we can break the Android app some more so we can use a hack like Filter 1139 (for iOS) for Android users as well? That hack works due to the fact that iOS edit filter disallows do not parse the page but just display the page title instead. Android unfortunately uses a hardcoded vandalism warning, so this does not work there. It should be trivial for WMF engineers to make Android behave the same as iOS while they do proper fixes. @DannyH (WMF)? ProcrastinatingReader (talk) 14:19, 15 July 2021 (UTC)[reply]

@ProcrastinatingReader: It looks like the fix for edit filter messages on Android has made it to the official (app store) release. So it should be possible to "communicate" with Android users through the filter now. However, links in the edit filter message will open in the browser. And if they're viewing a wiki that isn't their default language, the links will go the wrong language wiki. e.g., if we (on enwiki) send them to Special:MyTalk or WP:EF/FP/R, they might end up at fr:Special:MyTalk or de:WP:EF/FP/R. I don't know if that bug is being actively worked on, but we're getting somewhere. Suffusion of Yellow (talk) 23:34, 17 July 2021 (UTC)[reply]
Suffusion of Yellow I don't know a lot about edit filter, but I (maybe) have an idea for a work around. Can we redefine all edit filter links as fully defined [external links] and explicitly point them to https://en.wikipedia.org/_whatever_ ? Alsee (talk) 12:34, 18 July 2021 (UTC)[reply]
@Alsee: Tested here. That seems to work. The first link (Foo) opens at frwiki (because that's the first language in my settings), but both testwiki:Foo and https://test.wikipedia.org/wiki/Foo open at testwiki. That should work for a filter like 1139 (hist · log) but I don't think we should "fix" the dozens of other messages to work around this bug. Suffusion of Yellow (talk) 20:06, 18 July 2021 (UTC)[reply]

Some progress - see the latest update at mw:Wikimedia Apps/Team/Android/Communication. Nthep (talk) 21:00, 2 August 2021 (UTC)[reply]

Some progress: logged-out web

From T284642: Add yellow talk page message banner to non-main namespace pages on mobile, they (Reading product team?) have created an alert bar for logged-out mobile web users. It is displayed when the user taps edit or visits a non-mainspace page. ⁓ Pelagicmessages ) 22:10, 13 January 2022 (UTC)[reply]

P.S. For reference, T278838: Mobile user communication issues (WP:THEYCANTHEARYOU) appears to be the master task, it has a good long list of sub-tasks. ⁓ Pelagicmessages ) 22:10, 13 January 2022 (UTC)[reply]
Yes, this was deployed a while ago but because of a caching bug it only worked some of the time. The caching bug has supposedly just been fixed, but I haven't tested this recently. I would not assume that all mobile IPs can "hear us" without extensive testing. But some certainly can. Suffusion of Yellow (talk) 04:57, 15 January 2022 (UTC)[reply]

Wishlist

m:Community Wishlist Survey 2022/Mobile and apps/Better warning display for mobile users ⁓ Pelagicmessages ) 22:00, 13 January 2022 (UTC)[reply]

Drop everything and focus on the collaborative issues!

While the apps may be works-in-progress, this project is a collaborative one, and an app that allows you to edit but does not allow collaborating means a lot of good-faith editors who would be competent if editing with a browser are getting blocked for reasons they don't even understand. WMF added dark mode to their app before they allowed IOS users to access the talk namespace. I say, if you want the app to be decent, drop cosmetics, drop the rare (or even somewhat common) bugs, and get this issue over with. While users may have issues viewing certain pages, or their eyes may be strained looking at certain layouts, or it isn't quite ergonomic enough, that's small potatoes compared to the inability to see other editors' warnings. And then AN/I is not viewable on Android. The version shown starts with a thread from 2020 about the BLM protests. All of this means that editors who edit on mobile are not able to collaborate properly.

A proposed roadmap would be

Of course, you should take everything I say with a fifty-gallon drum of salt given that I have no background in web engineering and have no idea what issues WMF is facing. If someone more qualified than me steps up and says that this is not feasible, I will gladly retract it. ☢️Plutonical☢️ᶜᵒᵐᵐᵘⁿᶦᶜᵃᵗᶦᵒⁿˢ 15:54, 10 February 2022 (UTC)[reply]

Human Rights Policy

Just a note that the Board of Trustees has passed a Human Rights Policy. See foundation:Human Rights Policy. (as a global policy it applies to the English Wikipedia too, I believe) ProcrastinatingReader (talk) 15:25, 10 December 2021 (UTC)[reply]

Apparently a range of consultants were used to develop the policy.[7] It doesn't seem like the community was really consulted during the process or pre-approval by the board. Also, at first thought, I'm not sure about the value of a 'human rights policy' in an organisation that, at its core, develops an online website, but I will acknowledge I've only skimmed the policy and not read it thoroughly along with the various simultaneously-published FAQs, blog posts, etc. (which I imagine would take several hours). In my skim, I found it a bit vague/opaque and I find it hard to picture any practical changes. ProcrastinatingReader (talk) 15:32, 10 December 2021 (UTC)[reply]
I am not sure how it will have impact on our daily operations. I do think it's going to codify the way legal performs its balancing tests in some situations. This is reflective of the work done this year around challenges to articles, for instance, which did result in changes though I can only find the blog post introducing it as a topic for discussion. Best, Barkeep49 (talk) 17:29, 10 December 2021 (UTC)[reply]
When did this go live for consultation @Barkeep49:, do you know? Also pinging the two adders @RGaines (WMF) and GVarnum-WMF: I remember a re-write of the text on when Legal would take cases, but have absolutely no recollection of seeing this for consultation, and I am perhaps being optimistic and assuming that even the BOT wouldn't have made a significant global policy (itself calling on to a not yet finished or ratified UCOC) without major public consultations. Nosebagbear (talk) 09:19, 13 December 2021 (UTC)[reply]
No, of course they wouldn't do such a thing, they always remember that they are here to serve Wikipedia, not to rule it (or to help themselves and their dearest). How dare you even suggest such things? Luckily the policy is a purely empty promo gesture, a non-entity that will change nothing (but again reinforces the image that the BoT sn't really concerned with what actually makes things work around here, or what people actually donate money for). Lofty but completely untenable ideals if taken literally like "we believe that everyone acting in good faith should be able to participate and feel respected." Good faith but in the end unhelpful editors are shown the door (respectfully): we don't have to accommodate every good faith editor, no matter how incompetent they are. If that's a human rights violation, then we have a problem; but I guess that's only a human rights issues in the eyes of our BoT. On the other hand, there are many good faith long-term editors who feel thoroughly disrespected by the WMF and the BoT, so it seems as if the BoT is violating their own policy already. Quelle surprise... Fram (talk) 09:50, 13 December 2021 (UTC)[reply]
@Nosebagbear and Fram: I'd recommend a perusal of the Wikimedia-l mailing list thread. Many good points made there. --Andreas JN466 10:20, 13 December 2021 (UTC)[reply]
I believe the consultations were done specifically with the French and German Wikipedias @Nosebagbear. Best, Barkeep49 (talk) 18:45, 13 December 2021 (UTC)[reply]
@Barkeep49: One argument I have seen elsewhere, made by a Chinese Wikipedia editor, is that it makes clear that commitment to human rights trumps commitment to neutrality. (This is in the context of the political situation affecting the Chinese language community.) That's the best argument I have seen, though I am not sure that it would have required a policy as broad as this, based on human rights documents that also cover aspects such as minimum pay, right to healthcare (see [8] for a poignant post from Tito Dutta) and right to form unions – human rights that are clearly not well modelled in the Wikimedia movement, and in part, the WMF would surely argue, not applicable to it. --Andreas JN466 10:34, 13 December 2021 (UTC)[reply]
I wouldn't be at all surprised. We've seen several infiltration campaigns by certain countries under the guise of 'participation' and 'freedom of speech', while pressuring editors and running propaganda editing campaigns. China, russia, belarus, israel, but also the situations in the arabic and croatian communities we have seen all come to mind. These worries also came up in the movement talks a couple of times; how wikipedia is fundamentally founded in western liberties and how some editors were concerned if we would be able to uphold those liberties in our various projects with how the internet was globally evolving. —TheDJ (talkcontribs) 15:57, 18 December 2021 (UTC)[reply]
Does this policy mean admins will no longer be allowed to use fabricated death threats as justification for removing talk page access? That would be nice, actually. (WMF had no problem with it, Ombuds is officially still pondering the case) Does it also mean they won't ban Fram again? That would be nice. I think may be interested in the LGBTQ+ part. — Alexis Jazz (talk or ping me) 06:50, 19 December 2021 (UTC)[reply]

Hey, now maybe we can use their Human Rights Policy against them and force them to do something about discrimination against the visually impaired? Maybe @Guy Macon: can email talktohumanrights@wikimedia.org and see if those guys will force the WMF to put its million dollar warchest on fixing a major issue from 15+ years ago. Headbomb {t · c · p · b} 15:25, 18 December 2021 (UTC)[reply]

I just sent the following email:
Extended content

From: Guy Macon [ email redacted; I can be reached at https://en.wikipedia.org/wiki/Special:EmailUser/Guy_Macon ]

To: "Human Rights" <talktohumanrights@wikimedia.org>

Subject: Fifteen years of discriminating against the blind

On February 3 2006, it was reported to the WMF that our CAPTCHA system discriminates against blind people.

See [ https://phabricator.wikimedia.org/T6845 ]

This appears to be a direct violation of the Americans with Disabilities Act of 1990 ( https://en.wikipedia.org/wiki/Americans_with_Disabilities_Act_of_1990 ) and leaves Wikipedia open to discrimination lawsuits.

"National Federation of the Blind v. Target Corporation" ( https://en.wikipedia.org/wiki/National_Federation_of_the_Blind_v._Target_Corp. ) was a case where a major retailer, Target Corp., was sued because their web designers failed to design its website to enable persons with low or no vision to use it. This resulted in Target paying out roughly ten million dollars.

I have been repeatedly told that the proper way to request that Wikipedia stop discriminating against the blind is through phabricator, but clearly this was not effective in this case. I do NOT consider 15 years of refusing to answer to be reasonable behavior on the part of the WMF. I have been asking this question since 3 August 2017.

What I expect from the WMF:

I expect a yes or no answer. Either the WMF makes an official statement saying "No, we have decided not to fix this" or an official statement saying "Yes, we have decided to fix this."

If the answer is "Yes", I expect a page to be created (preferably on the English Wikipedia, but I will accept a page on Meta) that gives us the requirements (a testable definition of "done"), a schedule with milestones and updates, and budget and staffing information.

The WMF has made multiple statements saying that they intend to be more open about these sort of thing, and this is an excellent place to show that the commitment to openness is more than just talk.

Related:

-- Guy Macon (Wikipedia user page https://en.wikipedia.org/wiki/User:Guy_Macon ) 18 December 2021

Feel free to send copies of the above email to anyone at the WMF that you think might listen. Also feel free to add it to any appropriate mailing list.
Those of you with social media accounts, please publicize the above email with the hashtag #WikiforHumanRights [9]
In January I plan on organizing a huge online "Celebrating 16 years of Wikipedia discriminating against the handicapped" party and inviting a bunch of journalists. Watch my talk page for details.
--Guy Macon Alternate Account (talk) 06:10, 19 December 2021 (UTC)[reply]
Message confirming email arrived:
This is the Postfix program at host smtp4.irbs.net.
Your message was successfully delivered to the destination(s) listed below. If the message was delivered to mailbox you will receive no further notifications. Otherwise you may still receive notifications of mail delivery errors from other systems.
<talktohumanrights@wikimedia.org>: delivery via localhost[127.0.0.1]:5020:
250 Ok <talktohumanrights@wikimedia.org> Queued for delivery,
MTA response: 250 2.0.0 Ok: queued as 4JGsmS2CTsz3cBd
Reporting-MTA: dns; smtp4.irbs.net
Arrival-Date: Sun, 19 Dec 2021 01:11:19 -0500 (EST)
No response yet, not even an autoreply.
I requested a return receipt, which will tell me that it reached a human. --Guy Macon Alternate Account (talk) 01:53, 21 December 2021 (UTC)[reply]

Did anyone else notice this bit (I think one of the bullet points under Scope):

When I read that, to me it sounds like they're planning to take up international/global lobbying of various governments and other powerful entities around the world in an effort to promote and advocate for the ideals contained therein...is that an accurate interpretation, or do y'all interpret that passage to also be largely lip service and hand waving? If THAT were what their plans are, I suppose that would partially explain the WMF's continually ratcheting up of their feverish rush for ever-increasing (on an exponential curve) amounts of cash. 2600:1702:4960:1DE0:E915:C0E7:63E2:3E2C (talk) 07:18, 20 December 2021 (UTC)[reply]

Like Bono? They're not gonna sing are they? — Alexis Jazz (talk or ping me) 09:52, 20 December 2021 (UTC)[reply]
  • I am shocked -- shocked to find[10] that the WMF has once again not responded in any way to being informed that they are breaking the law. Who would have guessed that I would see the exact same stonewalling that all previous efforts to open a discussion saw? --Guy Macon Alternate Account (talk) 19:56, 9 January 2022 (UTC)[reply]

I got an actual communication from the WMF! And they say that the age of miracles is past. Keep in mind that this is in direct response to me reporting that the WMF is violating the law and could be sued for millions of dollars.

(Redacted) (Someone objected to me publishing the email and redacted it. The content was basicly "Stay off of phabricator for two weeks, and when you come back stop telling the W?F that the only acceptable solution to the W?F breaking the law is having the W?F stop breaking the law. If you keep saying that you will be blocked.")

So there you have it. Tell the whistleblower to STFU. Problem solved! :( --Guy Macon Alternate Account (talk) 13:30, 31 January 2022 (UTC)[reply]

Ah, Aklapper and the other similar ones at Phabricator and surroundings. Rather typical, that. No answer (or no useful answer), no answer, "when will you finally answer!", oh, poor conduct, block. Aklapper doesn't seem to have added anything useful to this phab task (or most others I have seen), but still feels the need to add "Could the signal vs noise ratio be decreased on this task, please? Thanks." when people are suggesting all kinds of ideas and trying to get an idea of the status of the task. Same AKlapper, when someone is finally enthusiastic about this task and wants to try to solve it (after 13, 14 years?), the very same day they assing the task to themselves: "Could you elaborate on your plans to go forward, code-wise?" Yes, no one at the WMF or Phabricator can solve this, but when someone offers to try, they have to present their plans, "code-wise", the very same day. How encouraging! I avoid Phabricator like the plague. It's useful (sometimes) for urgent requests, when the Thursday updates have once again broken something important or obvious. But otherwise, the whole atmosphere there (and the ridiculous "priority" assignment which is an after-the-fact experience, not an actual priority setting) is quite offputting. Fram (talk) 13:59, 31 January 2022 (UTC)[reply]
ah look who is here —TheDJ (talkcontribs) 14:05, 31 January 2022 (UTC)[reply]
I know you have a terrible disdain for both me and for the enwiki community, but you are not obliged to post otherwise empty potshots. If you have anything constructive to add, feel free. Otherwise, don't bother please. Fram (talk) 14:30, 31 January 2022 (UTC)[reply]
No Guy, you have been repeatedly told to stop being confrontational, argumentative and to contribute in a constructive matter in what many ppl consider their workplace (Phabricator) and/or place of joy (hobbyists). On this issue, but also on several other Phabricator issues in the past. You are repeatedly ignoring ppl trying to talk you out of scaling the reichstag in a spiderman suit and instead you choose to make Phabricator your place of war with WMF. Take it to twitter or something. —TheDJ (talkcontribs) 14:05, 31 January 2022 (UTC)[reply]
Perhaps the people who see Phabricator as their place of joy where no actual complaints about the WMF and its handling of bugs may be uttered, and the way some of their cronies try to stifle even the slightest frustration (or, as seen above, try to actievly discourage others from even working on such long-standing bugs or from posting helpful suggestions), should find another place, instead of the people using Phabricator to raise issues with the software and trying to get them resolved? Phabricator shouldn't be the private playground of some WMF'ers and hanger-ons, where external intrusion is seen as a threat and the never-ending issues with e.g. the "priority" system aren't adressed but rudely dismissed. Fram (talk) 14:30, 31 January 2022 (UTC)[reply]
I find it interesting that TheDJ objects to my attempts to get the W?F to follow the law, but apparently has no objection to the W?F doing illegal things. Purposely discriminating against the handicapped isn't just illegal. It is also evil. Looking the other way while others do evil is also evil.
The sad part is that multiple W?F employees and consultants (none of them in management or in a position of authority to assign someone the job of fixing the problem) have expressed to me privately that they are frustrated and ashamed with how the W?F is discriminating against blind people, but cannot say so publicly without being fired. --Guy Macon Alternate Account (talk) 20:23, 31 January 2022 (UTC)[reply]
repeatedly told to stop being confrontational, argumentative and to contribute in a constructive matter, I fail to see what is non-constructive about asking the WMF to DO ITS DAMNED JOB and fix a longstanding accessibility issue that's been going on for OVER FIFTEEN YEARS. It's not like the dozens of times where a more collegial tone was employed got us anywhere. Headbomb {t · c · p · b} 20:43, 31 January 2022 (UTC)[reply]
Obviously the W?F breaking the law by discriminating against the handicapped isn't the problem. Miscreants like you talking about the W?F breaking the law by discriminating against the handicapped is the real problem. All you have to do is shut your pie hole and the problem is solved. --Guy Macon Alternate Account (talk) 17:04, 8 February 2022 (UTC)[reply]
Without commenting on the discussion, as of 2022-02-14, trial removal of the CAPTCHA is blocked pending internal review by WMF Security, WMF Legal, and Tgr: https://phabricator.wikimedia.org/T299629#7704471 Enterprisey (talk!) 06:41, 19 February 2022 (UTC)[reply]
Has WMF Security, Legal or Tgr actually actually been assigned the job of making a decision on this? Or is this something with no budget, staffing or deadline that everyone can ignore for another 16 years without it in any way affecting their performance reviews? --Guy Macon Alternate Account (talk) 21:42, 19 February 2022 (UTC)[reply]
(...Sound of Crickets...) --Guy Macon (talk) 21:59, 5 March 2022 (UTC)[reply]
(...Chirp...) --Guy Macon Alternate Account (talk) 02:47, 21 March 2022 (UTC)[reply]
(...Chirp...) --18:29, 26 March 2022 (UTC) — Preceding unsigned comment added by Guy Macon Alternate Account (talkcontribs)
Whilst your point is important to many readers and editors of Wikipedia and other projects, it's clearly of less interest to the WMF than the unwanted projects they actually spend money on. I suspect that the only way forward is for someone, possibly a U.S. or Californian disability charity, to bring enforcement action. I should state per WP:no legal threats that I am not doing nor intending to do this myself. That policy and sub judice rules may also prevent anyone who does act from keeping us informed. Indeed, for all I know, prosecution may already be in progress. Certes (talk) 19:17, 26 March 2022 (UTC)[reply]
I doubt that either would prevent us from being informed. I doubt that a simple, neutral, statement that legal action has been taken would fall foul of our policy, and sub judice rules in California are not nearly as strict as in the UK. Phil Bridger (talk) 19:44, 26 March 2022 (UTC)[reply]
I really don't want to see the W?F sued over this, especially because I might be called as a witness. I would have to tell the truth; that I have contacted every board member, every recent CEO, everyone I could find at W?F legal, talktohumanrights@wikimedia.org, Trust and Safety, etc., and the only official response I got was to tell me to stop asking questions about this on phabricator. --Guy Macon Alternate Account (talk) 00:42, 28 March 2022 (UTC)[reply]

Luis Bitencourt-Emilio joining WMF and the danger of NFTs and/or crypto becoming part of Wikipedia

The Wikimedia Foundation has recently announced that a fella named Luis Bitencourt-Emilio joined the Board of Trustees. Glancing at his Twitter profile one can see a lot of red flags, like for instance him describing himself as an "investor" and expressing huge interest in blockchain and NFTs. One cannot help but be quite worried about the potential crypto lobbying that may be done by him or on his behalf – I am definitely not looking forward to seeing some ridiculous ideas like tokenizing articles which would be "owned" by individuals as a funding method for the foundation.

Is this an unnecessary worry? Is there nothing to worry about? Would any drastic change like this need to be community approved? What do other editors think? BeŻet (talk) 15:47, 15 January 2022 (UTC)[reply]

I don't think that there is any great danger to Wikipedia articles, but I do worry about people joining the board who are obviously more willing to follow fashion than to put the few seconds' thought in necessary to determine that NFTs are the 21st century equivalents of Tulip mania. And I also worry about the people who gave such a person a job - they are obviously just as thick. Phil Bridger (talk) 16:59, 15 January 2022 (UTC)[reply]
I agree, his background isn't entirely encouraging either - real estate, gig worker apps etc., however maybe he will focus on what he was doing for Reddit which apparently involved overseeing "all data, machine learning, spam/abuse protection and search efforts for the platform". Not saying he won't do any good, but still I think it's good to express concerns. BeŻet (talk) 17:14, 15 January 2022 (UTC)[reply]
He's a software engineer with experience in important positions in big tech companies. The question is what skill/experience he has that the board wants/was lacking. It's not that he's into crypto, certainly. I get that we all know at least one person for whom crypto seems to have taken over how they see the world, but a whole lot of people are interested in it without being transformed into a full-koolaid cryptopyramidologist. Being interested in the stuff doesn't negate what other experience you have. If there's a concern here, it's the WMF taking one more step towards the technology industry and away from community-focused nonprofits IMO. — Rhododendrites talk \\ 14:57, 16 January 2022 (UTC)[reply]
The Board has always had a mixture of tech industry-types and NGO-types as far as I know. I don't think this appointment represents any change there. As for NFTs, personally I wouldn't touch them with a hundred foot barge pole, but to be fair it's probably no worse a hobby than online poker. --RaiderAspect (talk) 23:15, 16 January 2022 (UTC)[reply]
BeŻet, 11 January 2022: m:Requests for comment/Stop accepting cryptocurrency donations. 12 January 2022: Luis Bitencourt-Emilio joins the Wikimedia Foundation Board of Trustees today. Holy crap I've never seen the WMF act that fast. Alexis Jazz (talk or ping me) 05:34, 29 January 2022 (UTC)[reply]
I'm pretty sure that's just a coincidence. BeŻet (talk) 14:55, 31 January 2022 (UTC)[reply]
Adding my two cents: the sooner cryptocurrency becomes an accepted part of the ecosystem, and and off wiki, the better. Piotr Konieczny aka Prokonsul Piotrus| reply here 15:55, 9 February 2022 (UTC)[reply]
It's already off wiki, unless you mean you want it to be a part of wiki?? BeŻet (talk) 18:10, 9 February 2022 (UTC)[reply]
@BeŻet Yes, I meant, on wiki. And for the record, I am not looking at this as a "thing for WMF", but a "thing for editors". This technology has the potential to give editors a tangible stake in Wikipedia, something they could even - gasp - monetize. This project, since day one, has suffered from the problem of not sufficiently rewarding its contributors (all we get is some self-fulfillment, an occasional barnstar and a ton of stress), and this technology offers a solution for balancing this inequality. Piotr Konieczny aka Prokonsul Piotrus| reply here 09:13, 10 February 2022 (UTC)[reply]
This is a horrible, horrible, horrible idea. I'm not going to call you a "Luddite" though. BeŻet (talk) 10:52, 10 February 2022 (UTC)[reply]
I don't understand what you are talking about. There are many good reasons not to pay contributors to Wikipedia, while there already exist ways to do so with existing non-crypto technology. —Kusma (talk) 11:01, 10 February 2022 (UTC)[reply]
I disagree with you there, I'm afraid. I think adding financial incentives to edit would be extremely toxic to the community, if people are getting paid to edit then you add a perverse incentive and encourage editors to perform actions that are not in the best interests of the project but result in pay-outs. If you pay people to create articles then you just encourage people to spam low-quality single sentence stubs that technically pass some SNG. If you pay people per edit then you encourage bot like minor editing that doesn't really improve the project. If you pay based on reader engagement then you incentivise spamming links into places they don't belong. We had enough trouble with #WPWP last year where people were spam-adding low quality/irrelevant/incorrect images to try to win gift cards, applying the same thing to all editing would be a disaster IMO. 192.76.8.77 (talk) 11:16, 10 February 2022 (UTC)[reply]
Exactly all of this. It's just a dreadful idea on so many levels. Wikipedia has been very successful without editors being reimbursed. Moreover, I don't understand how introducing such horrible mechanics like asset speculation would help the community, and not be exploited by big owners of capital, just as everything crypto-related has been thus far. It would frankly discourage many editors from contributing - why would I want to contribute to an article if someone else would financially benefit from it, either immediately or in the future? We would suddenly have labour exploitation. Wikipedia is a collective effort for a collective benefit, not for some individuals to profit from it. This idea is just so horrible that I cannot fathom why anyone would want to support it. BeŻet (talk) 12:06, 10 February 2022 (UTC)[reply]
The moment money plays a part in anything but just running the servers and keeping the lights on, Wikipedia will fall faster than anything I've seen. The whole beauty is that we do this not for a reward but out of a conviction that the benefit for others is better than the time we could be using elsewhere. If someone tries to pay me for this I will instantly lose all joy. There's a reason many artists warn me not to monetize my hobbies, associating pleasure with financial reward sucks the soul out of a lot of nice things. A. C. SantacruzPlease ping me! 20:25, 25 February 2022 (UTC)[reply]
We may be conflating two issues here. There seems to be a strong consensus against paying editors. If that ever changes, those of you who choose to stay won't need a digital currency to receive your payments, let alone any new "on wiki" crypto technology. Certes (talk) 11:55, 10 February 2022 (UTC)[reply]
I just read your comment saying that "the Luddite opposition to this emerging tech is baffling". I wish you spent more time familiarizing yourself with the critique of cryptocurrencies before calling people Luddites. BeŻet (talk) 18:12, 9 February 2022 (UTC)[reply]
Hmm... yeah, I'm hardly a Luddite. Perhaps my opposition to cryptocurrencies is not based on opposition to automation, computerisation, or new technologies in general but rather on a solid (technical) understanding of blockchain technology and its societal impacts. Just an option to ponder; not everyone who disagrees with one is therefore an idiot. Vexations (talk) 18:27, 9 February 2022 (UTC)[reply]

Thanks everyone for your input. BeŻet (talk) 11:32, 17 January 2022 (UTC)[reply]

I'm disappointed in this too. This project is supposed to be about freeing digital information, not "monetising" it the polar opposite of the crypto/fintech world Bitencourt-Emilio is from. It seems like a continuation of the long-running tendency of some upper echelons of the WMF to play at being a tech company rather than an educational foundation. – Joe (talk) 12:26, 10 February 2022 (UTC)[reply]
Also, the announcement is full of the kind of corporate doublespeak that we regularly burn out of articles. Apparently Rappi isn't an Uber-style middleman that will send an underpaid and precariously employed courier (maybe a child) to your house if you're too lazy to go to the supermarket, it's "focused on serving consumers in Latin America". Loft aren't venture capital-backed real estate speculators, they're "further[ing] the goal of home ownership for Latin Americans". But I suppose that's "supporting bottom-up innovation"? – Joe (talk) 13:42, 10 February 2022 (UTC)[reply]
Yes, that wording is indeed baffling. BeŻet (talk) 14:35, 10 February 2022 (UTC)[reply]
I've followed up on Rappi's unethical business practices in the wikimedia-l thread, if anyone is interested. No response from anyone at the WMF yet. – Joe (talk) 12:28, 14 February 2022 (UTC)[reply]
Hi Joe, has there been any reply? BeŻet (talk) 15:53, 11 March 2022 (UTC)[reply]
Nope. Nothing at all. – Joe (talk) 11:34, 21 March 2022 (UTC)[reply]
Yeah that's the point, it should have been a factor. – Joe (talk) 08:51, 11 February 2022 (UTC)[reply]
It not being a factor in the selection says nothing about him potentially trying to lobby for crypto features. It's good to hear that Dariusz isn't a fan of cryptocurrencies though. I disagree however that there is no need for a unified stance about this - there should be a statement that unequivocally rejects any possible official crypto integrations and features. BeŻet (talk) 11:15, 11 February 2022 (UTC)[reply]
Telling us it's unproductive to discuss on-wiki the position of a WMF board member is unproductive. It rather inclines people to ask "what are they trying to hide?", even if they aren't trying to hide anything. DuncanHill (talk) 15:10, 11 February 2022 (UTC)[reply]
(n.b. see Yair's followup below) I've no reason to think Dariusz is not telling the truth when he says it wasn't factored in, and unlike others, I also don't think it had to be factored in. However, a Board member saying on-wiki discussion of it is non-productive...that I disagree with, very firmly. Discussing who the WMF's Board members are, and their positions (and potential positions) is inherently a reasonable area of discussion. This is especially true while the BOT believes that they have a Movement governance role, rather than being made by the communities. Nosebagbear (talk) 13:54, 19 February 2022 (UTC)[reply]
@Nosebagbear: ? I don't think any Board member suggested that. I hope it didn't look like the second sentence of my comment was attributed to Dariusz? That was just my own opinion, that on-wiki discussion of it ("it" being crypto itself, not the trustee selection) would be unproductive. --Yair rand (talk) 17:32, 20 February 2022 (UTC)[reply]
@Yair rand: ah, thank you for clarifying - I had indeed taken your second sentence to be (also) attributed to Dariusz Nosebagbear (talk) 09:05, 21 February 2022 (UTC)[reply]

Wikimedia servers

Hi, a few days ago I read that Wikimedia servers are located in Europe and the U.S.A. I don't recall where I saw that but it seems plausible. Considering the current war and the possibility of expansion beyond the Ukraine, I wonder whether a third location might be prudent. Australia and New Zealand are obvious possibilities. Regards, ... PeterEasthope (talk) 03:17, 27 February 2022 (UTC)[reply]

@PeterEasthope: the main servers hosting the wikis are in Virginia and Texas. There are also servers providing caching services in California, Amsterdam, and Singapore. stwalkerster (talk) 16:42, 27 February 2022 (UTC)[reply]

Don't worry, Wikipedia never delegated authority over the domains to outside the US. In the worst case scenario, all Wikipedias hold a .org domain, which is controlled by US (verisign), in the event of any dispute, Wikipedia can just ask verisign to redirect connections to their US servers. The only way to intercept communications would be to compromise Root DNS servers on a region-per-region basis, but even then, HTTPS certificate infrastructure would need to be compromised, and that is probably hosted in the US, and such an attack would exceed Wikipedia Scope. As a country with almost 30% of it's state budget invested into the military, the US is well prepared to avoid this attacks on their network (remember the Internet was born in the Department of Defense), especially after the 9/11 attacks and the congress-mandated reinforcements on network sovereignty

In short, Wikipedia is a US organization first and foremost, Europe clusters are just replicas without the real power.--TZubiri (talk) 00:10, 4 March 2022 (UTC)[reply]

(link elided) A current copy of the current revisions of all pages of the English Wikipedia, in all namespaces, for satisfying any paranoia. That's just 40GB, worth actually downloading and saving somewhere just because you can. ~ ToBeFree (talk) 15:51, 10 March 2022 (UTC)[reply]
@ToBeFree, my apologies, but I've deleted the link to the dump file. I would imagine many people have clicked on that not realizing they were starting to download a 40 GB file which will almost certainly be of no use to them. I agree that we should let people know about the dumps (and encourage other organizations with the required resources to mirror them), but a better way to do it is to point them to m:Data dumps where they can learn about the file formats and download all the data from every project, not just enwiki. -- RoySmith (talk) 14:17, 14 March 2022 (UTC)[reply]
enwiki-latest-pages ...bz2 is a good idea; although connectivity and storage don't permit a copy here. Never put all your eggs in one basket even if absolutely convinced that you can never be influenced by a tyrant. =8~) Thanks ... PeterEasthope (talk) 13:34, 14 March 2022 (UTC)[reply]

Quarterly Community Safety survey

Starting the week of 28 March 2022, the Wikimedia Foundation will conduct a quarterly anonymous survey about safety perceptions among the English Wikipedia community members.

This survey responds to a Universal Code of Conduct community recommendation, and we encourage you to participate.

There are more details about the survey on the project page, and you can also leave comments.

Best regards, Community Safety Survey team –– STei (WMF) (talk) 10:47, 21 March 2022 (UTC)[reply]

A recommendation from a draft, which wasn't retained in the "final" page which is right now being voted on. Clearly a high priority investment of WMF time, unlike, oh, other stuff discussed on this page, or some of the many Phabricator bugs from years and years ago, or the community wishlist, or... Still, they won't collect any personally identifying information when you enter the surbey, apart from, uh, your IP address apparently (and for some reason the page you were reading when you answered the survey). Still, the results of this yes-no question will be incredibly useful to support whatever claim the WMF wants to make about the results of UCOC or IP masking I guess (more people feel harassed? We need more WMF actions! Less people feel harassed? WMF actions clearly work!). Fram (talk) 11:46, 21 March 2022 (UTC)[reply]
@STei (WMF): For my own personal curiosity, what was the specific UCoC community recommendation you are referring to? Is it Wikimedia Deutschland's specific recommendation from the Enforcement draft guidelines review or something else? –MJLTalk 16:40, 22 March 2022 (UTC)[reply]

UCoC message

A message above my watchlist says that "Voting on the ratification of the Universal Code of Conduct (UCoC) enforcement guidelines is open until 22 March 2022." Has the deadline been extended from 21 March, or do we need to fix the message so no one waits until tomorrow and misses out? Certes (talk) 12:39, 21 March 2022 (UTC)[reply]

Confirm that my watchlist also says "Voting on the ratification of the Universal Code of Conduct (UCoC) enforcement guidelines is open until 22 March 2022." with a link that leads to a page that says "The ratification voting process for the revised enforcement guidelines of the Universal Code of Conduct (UCoC) is now open! Voting commenced on SecurePoll on 7 March 2022 and will conclude on 21 March 2022. Please read more on the voter information and eligibility details." --Guy Macon Alternate Account (talk) 13:35, 21 March 2022 (UTC)[reply]
@Xaosflux chose this wording at MediaWiki:Watchlist-messages. —Kusma (talk) 13:50, 21 March 2022 (UTC)[reply]
@Certes according to SecurePoll the poll is now open until 20220322T0000. — xaosflux Talk 14:13, 21 March 2022 (UTC)[reply]
Ah, so I suppose "open until [00:00 UTC] 22 March" is technically correct, though someone in the US could be forgiven for expecting "until 22 March" to allow a vote this evening. Certes (talk) 14:18, 21 March 2022 (UTC)[reply]
Is the goal to be technically correct but misleading or is the goal to be clear and unlikely to be misunderstood? In general, deadlines should not be set at exactly midnight. Something like "voting closes at 23:59 on 21 March (UTC)" is far less likely to be confused. --Guy Macon Alternate Account (talk) 18:16, 21 March 2022 (UTC)[reply]
The problem is not that the deadline is midnight. The problem is that "22 March 2022" is a vague and incomplete description of a point in time. Either of "until 23:59:59 21 March 2022 UTC" or "before 00:00:00 22 March 2022 UTC" would have been precise and unambiguous ways to say this. The idea that a website which is used by people around the world should be publishing times without explicitly indicating a time zone (and that time zone being UTC) is mind boggling.
A bunch of years ago, at a large company which you've heard of, one of their top-tier products suffered a 1 hour lapse in support coverage because the crew in California and the crew in Sydney botched a handoff when daylight savings time started or ended at one location or the other and the extremely smart people who work there ran out of fingers to count time zones on. -- RoySmith (talk) 19:55, 21 March 2022 (UTC)[reply]

My watchlist now says "Voting on the ratification of the Universal Code of Conduct (UCoC) enforcement guidelines is open until 2022-03-22T00:00 (UTC)." --Guy Macon Alternate Account (talk) 20:15, 21 March 2022 (UTC)[reply]

Where do we go to warn the WMF about new security threats?

They probably already know about this one, but in case they don't I want to warn them.

Where can you post a message that someone in the WMF will actually read?

The threat: Hackers Gaining Power of Subpoena Via Fake “Emergency Data Requests”

00:39, 31 March 2022 (UTC)2600:1700:D0A0:21B0:8981:FEBD:4662:A3B0 (talk)