Wikipedia:Village pump (WMF)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

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.

• Discussions of proposals which do not require significant foundation attention or involvement belong at Village pump (proposals)
• Discussions of bugs and routine technical issues belong at Village pump (technical).
• Consider developing new ideas at the Village pump (idea lab).
• This page is not a place to appeal decisions about article content, which the WMF does not control (except in very rare cases); see Dispute resolution for that.
• Issues that do not require project-wide attention should often be handled through Wikipedia:Contact us instead of here.
• This board is not the place to report emergencies; go to Wikipedia:Emergency for that.

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)

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

Tracked in Phabricator
Task T240976

(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."

Tracked in Phabricator
Task T240889

(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)

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)

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)

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 (talk • contribs) 09:26, 18 February 2021 (UTC)

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

Tracked in Phabricator
Task T263943

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)

Tracked in Phabricator
Task T275117

Tracked in Phabricator
Task T275118

I have filed T275117 and T275118. ProcrastinatingReader (talk) 10:22, 18 February 2021 (UTC)

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)

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

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

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)

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)

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)

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.Cullen³²⁸ Let's discuss it 18:34, 18 February 2021 (UTC)

• In some parts of the world, laptops and desktops are common, and people's phones are their second screen. In an environment like that, yes, it makes sense for mobile devices to be thought of as a read-mostly interface. On the other hand, in other parts of the world (particularly India in the context of English language users), mobile is how people access the internet.[1] There's no doubt that building a good editing interface for mobile is a hard thing, but we should be investing more effort there. Poor mobile editing tools disenfranchises a large segment of the world's population. -- RoySmith (talk) 14:41, 18 February 2021 (UTC)

• @Suffusion of Yellow: Thank you for basically expressing exactly the same problem I wanted to. I have blocked a few editors who seem to be editing in good faith but just don't communicate, which eventually end up at ANI and after much agonising, get hit with as friendly a WP:ICANTHEARYOU block as we can muster. In the last instance, Mdd97 (talk · contribs), I specifically made a custom block template that said "CLICK HERE TO READ YOUR MESSAGES" in a way that they surely couldn't miss .... but again, following the block they've not edited again. We have to get to the bottom of this; if it's got to the stage where I've got to block people and the root cause is a software fault, it needs to be fixed. Surely the WMF can't be happy that I've needed to issue blocks on good-faith editors in this manner. Ritchie333 ^{(talk) (cont)} 16:10, 18 February 2021 (UTC)
• To address a reaction some might have, yes, the vast majority of users on mobile are readers, not editors, and no, I wouldn't want the community totally in charge of redesigning the mobile interface, since we'd end up with the phenomenon we have at desktop where e.g. the tools section of the sidebar is visible to every user on every page despite it being of zero use to 99.9% of them. But this request is not just editor-centrism; it applies to users who have already edited and who badly need a notification to help them not get lost. {{u|Sdkb}} ^talk 18:55, 18 February 2021 (UTC)

  I agree 100 % with the your 99.9 % comment. ( :-)). The user interface is editor-centric, is an example ofConway's law to extremes and [[Design_by_committee]]. To add to the list, the bottom part of the [[Main_Page]] and worse of all all the uncollapsed header tags on Talk and Article such [[WP:NPOV]], which emphasis Editing or reading. To continue the Cool Hand Luke topic name reference, we are making readers eat too many boiled eggs of information Wakelamp d[@-@]b (talk) 00:48, 9 November 2021 (UTC)

• I think the mw:Talk pages project, especially now that they are beginning to work on subscribing to notifications for talk page sections, could be interested in this discussion. Pinging User:PPelberg (WMF) and User:Whatamidoing (WMF). It also touches on UCoC Enforcement, highlighting that there needs to be funding for software dev. in addition to other measures. Pinging User:SPoore (WMF) and User:BChoo (WMF) for want of knowing who to contact regarding Phase 2. Pelagic ( messages ) – (09:51 Sat 20, AEDT) 22:51, 19 February 2021 (UTC) ... Adding User:Xeno (WMF) after seeing section above. Pelagic ( messages ) – (09:55 Sat 20, AEDT) 22:55, 19 February 2021 (UTC)

  Pelagic: Thank you for the ping and highlighting how this is a related need for my current project. I've been following this thread and will be including the comments (and phabricator links - thank you for those!) in my work categorized under important requests for additional human or technical resources to assist with on-wiki workflows. Xeno (WMF) (talk) 15:02, 14 March 2021 (UTC)

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

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

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)

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)

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)

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)

• Does anyone with a (WMF) account plan on commenting in this thread? Suffusion of Yellow (talk) 17:21, 8 March 2021 (UTC)

  Don't hold your breath. For most WMF employees, commenting on Wikipedia using a WMF account is a quick way to get yourself fired. You might, if you make enough noise, get a department head to respond by saying that mobile users are very important to us and we will do everything we can to address this, up to but not including doing anything differently that we are doing them now. --Guy Macon (talk) 17:39, 8 March 2021 (UTC)

  @Guy Macon: When they did the same thing with desktop IPs, it was fixed within hours of being pointed out. Serious, not rhetorical question: what's changed about WMF culture since 2013? Suffusion of Yellow (talk) 17:58, 8 March 2021 (UTC)

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)

• User:Suffusion of Yellow broadly you have two factors. Firstly there is little incentive for WMF people engage people here were they will get a bunch of people shouting that them (which is not fun). Secondly there has been a longstanding unwritten understanding that mobile is the WMF's turf while the community has more ownership of the desktop.©Geni (talk) 11:21, 11 March 2021 (UTC)

  Well, imagine this. Someone is standing on your foot. You politely ask them to move off of it. They don't. You repeat your request more loudly. They continue to ignore you. It still hurts. At some point, does shouting and shoving come into play?

  If WMF doesn't like being shouted at, well—certainly, no one does. But people do not like being ignored either, and doing so is an excellent way to get them started shouting just to be heard at all. Seraphimblade ^{Talk to me} 21:42, 14 March 2021 (UTC)

• Action from the WMF! One two three new mobile bugs I discovered while investigating this have been triaged as "low" priority, and a fourth was lowered to "medium", after a volunteer developer had raised it to "high". All without a word of explanation. The first (unparsed spam blacklist messages) isn't a huge deal I'll agree. But why is not telling users why they're blocked or falsely telling registered users that they're blocked personally not a major concern? That's how we lose people. Suffusion of Yellow (talk) 22:55, 22 March 2021 (UTC)
  • Can we locally block these apps from editing English Wikipedia? That would force the WMF to fix them. Fences&Windows 00:02, 26 March 2021 (UTC)

    @Fences and windows: Yes, this can be done with the edit filter. It could even be limited to users with no confirmed email address. But there's a catch. The apps don't properly display custom edit filter warnings, either! The iOS app just displays the title of the page where the message is stored. And the Android app doesn't display custom messages at all. The mobile web editor does display messages properly, however. Suffusion of Yellow (talk) 00:10, 26 March 2021 (UTC)

    If this were a lower-priority issue, I would say we should come back in a month and see if the WMF fixed it. But this is such a glaring oversight that I feel this may be the only option if we want to fix this. Question: would this apply to just the app, or to the mobile site as well? —pythoncoder (talk | contribs) 15:06, 29 March 2021 (UTC)

    It's app only (the user_app variable in the edit filter). ProcrastinatingReader (talk) 15:12, 29 March 2021 (UTC)

  Thanks, ProcrastinatingReader. If we prepare an RfC, where would it be held? It would need advertising on cent. Fences&Windows 23:47, 29 March 2021 (UTC)

  @Fences and windows: Any RFC will need some very careful drafting first. If it fails (for any reason) the WMF could interpret the failure as "see the community doesn't really care about this issue". Suffusion of Yellow (talk) 23:51, 29 March 2021 (UTC)

  We might want to move this thread to WP:VPT; this noticeboard is not widely watched. –xeno^talk 23:54, 29 March 2021 (UTC)

  I really don't want to rush into an RFC, though. There are many questions. Should we also disallow mobile IP web editors? Should we disallow edits from users with a confirmed email address? Which bugs, exactly, do we want fixed? How long do we give the WMF to fix them? This is a nuclear option. It should not be taken lightly.

  But please don't move the whole thread to VPT. It's here so it doesn't get buried in the archives. Suffusion of Yellow (talk) 00:33, 30 March 2021 (UTC)

  (edit conflict) Two-question RfC maybe? Initial brainstorm - Question 1: consensus 'letter' to WMF requesting resources be allocated to promptly fix the issues. Question 2: if not done within 90 days, mobile apps blocked from editing enwiki by edit filter. Best to move this particular matter to VPI. ProcrastinatingReader (talk) 00:36, 30 March 2021 (UTC)

  It has to be noted though that disallowing edits, if it comes to it, is really not great and rather bitey, as the editors will hardly have any clue what's going on due to EF messages being iffy. Maybe bugging Jimbo and/or Doc James to contact someone in engineering is a viable option? ProcrastinatingReader (talk) 00:43, 30 March 2021 (UTC)

  As I said. Nuclear. Suffusion of Yellow (talk) 01:09, 30 March 2021 (UTC)

  Yes, IDEALAB is the best place (for a new thread). That will discourage any supporting and opposing until we figure just what we're asking for. Suffusion of Yellow (talk) 01:09, 30 March 2021 (UTC)

  This needs caution—an overly enthusiastic RfC or proposal at WP:VPI is bound to be voted down and that would cause a lot of people to automatically vote down any future proposals of a similar nature. I'm thinking of masked IPs—any proposal to impede or block such users could easily fail if it appeared to be similar to an earlier idea to block "good faith" users who were unaware that communication was even possible, let alone required. Johnuniq (talk) 08:34, 30 March 2021 (UTC)

• I wish I could say I was surprised by any of this but I've long assumed that something like this was the cause of numerous editors I've come across who display quite clearly that they have never seen their IP/user talk page, and simply have no idea why their edits "aren't going through" (because a human editor keeps undoing them). A thorough waste of thousands of hours of volunteer time, on both ends. There are some countries or regions in which accessing the internet is only financially possible for the everyday person via a mobile phone, so the WMF's inaction here is another built-in systemic bias which prevents some cultures from effectively contributing their knowledge and skills to Wikipedia. — Bilorv (talk) 06:51, 29 March 2021 (UTC)
• Tracked in Phabricator
  Task T278838
  
  
  User:Suffusion of Yellow/Mobile communication bugs seems to be an excellent overview but it would get more attention if it were on phab. I have tried to roughly copy it to https://phabricator.wikimedia.org/T278838 which can probably be used as a parent task for all these issues. – SD0001 (talk) 15:04, 30 March 2021 (UTC)

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)

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

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)

What are we doing about the block notification messages and the other edit screen notices?? —TheDJ (talk • contribs) 19:02, 26 April 2021 (UTC)

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

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

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)

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)

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

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)

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)

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)

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. Cullen³²⁸ 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)

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)

hear hear. —TheDJ (talk • contribs) 08:35, 6 May 2021 (UTC)

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)

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

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)

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)

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

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)

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

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

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

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)

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

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

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)

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

#suggestededit-add 1.0

Tracked in Phabricator
Task T227623

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)

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)

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)

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)

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)

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

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)

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

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

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. ⁓ Pelagic ( messages ) 22:10, 13 January 2022 (UTC)

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. ⁓ Pelagic ( messages ) 22:10, 13 January 2022 (UTC)

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)

Wishlist

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

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

• Drop everything until the issue is dealt with
• Direct all resources to creating a way for mobile users to collaborate in the same way desktop users can (Especially IOS users, who are worse off than their android companions)
• Fix the bug affecting AN/I, as it is one of the most important pages for dealing with certain editors or issues
• Unblock any users who were blocked for CIR or refusal to communicate on mobile.
• Return to whatever you were dealing with before.

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)

Technical Decision Forum: community representatives

This week's Tech News reports that the Technical Decision Forum is seeking community representatives. You can apply on wiki or by emailing TDFSupportwikimedia.org before 12 August. Prerequisites include +2 rights on the mediawiki ACL on Wikimedia's Gerrit instance. Certes (talk) 10:56, 19 July 2022 (UTC)

Note: The WMF has doubly outdone itself in abusive propaganda here. The WMF has explicitly forbidden any decision making by this group, and the WMF has explicitly forbidden any community representation in the group.

• The documentation explicitly states this group does not make decisions. (I am not the one who decided to make that text screaming-red, the WMF made it screaming red in the original source.) The group's sole purpose is to offer opinions and feedback to WMF product teams - who make decisions. Anyone can already show up and offer teams opinions and feedback.
• Aside from egregious constraints on eligibility, the document explicitly states all members will be selected and appointed by the WMF itself. As such, they by definition represent the WMF. Furthermore any member who displeases the WMF can be unilaterally dropped from the group by the WMF Chief Officer on a twice-yearly reappointment schedule, or banished immediately by a vote of staff in the group.

Alsee (talk) 16:42, 29 July 2022 (UTC)

the WMF has explicitly forbidden any community representation in the group — you're going to have to run that one by me again.. the WMF has done no such thing as far as I can see? — TheresNoTime (talk • she/her) 17:16, 29 July 2022 (UTC)

@TheresNoTime: I think Alsee means that members appointed by the WMF cannot truly be community representation, regardless of whether the WMF claims they are. * Pppery * _{it has begun...} 16:06, 30 July 2022 (UTC)

@TheresNoTime, what would you say if Russia announced some organization to deal with the Russia-Ukraine conflict, and Russia announced the committee would include "Ukrainian representatives" unilaterally selected by Russia? What if China appointed "Taiwanese representatives"? Comparing the WMF with Russia may be overly harsh, but it clearly establishes a valid point: Trying to appoint "representatives" for someone else is obviously invalid, if not outright abusive.

I created Village_pump_(WMF) as part of my long work informally representing community concerns and community consensus to the WMF. The WMF has a bad habit of shooting the messenger, treating it as "disruptive" for anyone to accurately represent community concerns and consensus whenever that conflicts with their pre-established plans. In my experience WMF staff are good people with good intentions, they love the mission, they want to support the community, they want to listen to us and consult us. The problem is that they do not respect the community as a partner. When they don't understand why consensus says what it says, or when they they disagree with our expert experience or values, they believe they have righteous-authority as benevolent overlords. The WMF likes to select "community representatives" because it lets them tell themselves how much they love the community, it lets them tell themselves they support community input and participation, while desperately seeking any effective means of duly subjugating the community back down to their proper role as powerless peasants. Alsee (talk) 00:37, 7 August 2022 (UTC)

I think Alsee is a little harsh in their evaluation, but I do get where they're coming from. A selection process which consists of "We will decide who your representatives are" doesn't inspire confidence. But, more than that, I can't tell what this group is supposed to do. I've experienced some friction with the WMF regarding how the cloud services (Toolforge and VPS) work. When I first heard about this, I thought, "Hmmm, maybe it would be good for me to be part of this, because then I would have some influence about the things that bother me". But when I read https://www.mediawiki.org/wiki/Technical_decision_making/Forum, I honestly had no idea what this group would be doing. That page says, "The purpose of the Forum is to provide feedback to teams making decisions". Well, I do that now. It doesn't often have any effect, but it's also not clear how that would change if I were to join this group. -- RoySmith (talk) 00:56, 7 August 2022 (UTC)

I should also add that having +2 rights is a requirement to membership. So, I do realize that I'm not eligible and my note above is moot. -- RoySmith (talk) 01:00, 7 August 2022 (UTC)

> Well, I do that now. It doesn't often have any effect

Most of your comments likely are more "product" related. And that is not something that this group would involve itself with, that is mostly up to the individual teams and/or WMF management.

The forum (as stated in its FAQ and background page) mostly deals with large engineering questions that will effect multiple WMF technology teams and Mediawiki developers and is a continuation of it's previous TechCom RFC process and before that the Mediawiki architecture committee. It's mostly to make sure that teams/developers have a way to choose a direction where topics have interteam overlap in terms of responsibilities and impact, especially when those topics have long term impact. As such, a deep understanding of MediaWiki but also of the WMF specific configuration and engineering problems is required to participate. A specific example would be the decision that led to the selection of Vue as the next major frontend framework to be used by MediaWiki and the WMF teams. A decision that will impact MediaWiki and all its developers for 10+ years. This forum historically has not been very active and/or effective for various reasons (hence why there have been so many different versions of this process). —TheDJ (talk • contribs) 15:25, 8 August 2022 (UTC)

footnotes

References

Discussion at Wikipedia:Village pump (proposals) § Communication issue

 You are invited to join the discussion at Wikipedia:Village pump (proposals) § Communication issue. This relates to the unilateral rollout of a new external link icon. {{u|Sdkb}} ^talk 14:38, 29 July 2022 (UTC)

new resource for movement discussions.

There is a whole new set of forums being utilized now, which are available for discussion of any and every topic that pertains to Wikipedia, and our community and the Wikimedia movement. please feel free to go there and sign up for an account, and participate as often as you may wish. I hope you will click the link below to do so. we would welcome your input. thanks!!

• New discussion venue: the MS Forums
  • link to join: https://forum.movement-strategy.org/invites/9n1gJhfJeH

thanks. --Sm8900 (talk) 17:25, 29 July 2022 (UTC)

Why are discussions about Wikipedia being held at another site? We have talk pages here. --User:Khajidha (talk) (contributions) 21:34, 4 August 2022 (UTC)

The domain registrant for movement-strategy.org claims to be Wikimedia Foundation, Inc., so this appears to be yet another Meta. We already have too many other WMF sites that few Wikipedians ever visit trying to control us; let's hope the latest diversion dies quickly. Certes (talk) 22:47, 4 August 2022 (UTC)

Hear hear. We have meta for that. We don't need yet another external site. Headbomb {t · c · p · b} 22:50, 4 August 2022 (UTC)

I appreciate the replies above. In reply, I would note that we do already have multiple platforms that are external and off-wiki. if you prefer to not use those platforms, or if you find them counter-productive, then of course that is fine, and one is fully entitled to one's own opinion on that. however, there is no objective basis for precluding the existence of an individual off-wiki platform, in view of the context of multiple other platforms being in existence and fully accepted, prior to this.

the off-wiki platforms that are already fully active, and used regularly, include: Telegram, Discord, IRC, Slack app, (such as the slack channel listed at this page).... et cetera. this is not a full or definitive list. please note that, just as one example, the usage of the app "Telegram" includes multiple groups (i.e. threads) there. the thread on Telegram that is labeled as being for the "Wikimedia movement" as a whole, has over 700 members, and is fully active. in addtion, on Telegram alone, there are additional active threads for Wikimania, for Wikimedia Hackathon, for WikiVibrance, etc. and several other active topics as well.

So Telegram is clearly an existing active external platform. not only is it not on any Wikimedia site, it is clearly an app that is not under control of WMF in any way. the main difference with the MS Forums is that they are indeed fully designed by Wikimedia itself. so in that sense, they are a resource that is much more focused on the WMF community itself. I hope that is helpful. --Sm8900 (talk) 17:31, 5 August 2022 (UTC)

• Not only is this yet another demonstration the WMF's pathological hatred of their own Wiki platform,
• not only does this perpetuate the WMF's disastrous pattern of cooking up plans off-wiki which end up in hot conflict with actual community consensus,
• community members are prohibited from the site if they declined to register an e-mail address on their wiki account.
  • According to WMF figures I came across, somewhere between 20% and 45% of users decline to provide an email, and an outright majority do not have a verified email.

Note that Wikimedia Foundation Privacy Policy says Because we believe that you shouldn’t have to provide personal information to participate in the free knowledge movement, you may:

• Read, edit, or use any Wikimedia Site without registering an account.
• Register for an account without providing an email address or real name.[7] Alsee (talk) 01:44, 7 August 2022 (UTC)

A bad idea doesn't cease to be a bad idea just because someone else has already done it. --User:Khajidha (talk) (contributions) 14:43, 7 August 2022 (UTC)

true true. perhaps go to the threads onTelegram, and address these thoughts to them? I didn't know that alternative processes for open and free expression would attract such opposition here. perhaps you should go to the Telegram thread, and tell all 700 people to discontinue all discussion? if you're right that such interchanges is a bad idea.,how then can we address those errant individuals who seem to persist in this practice? perhaps wikipedia has some articles on some historical methods for pummeling such practitioners of untrammeled discourse? I'm deleting my own tongue-in-cheek remarks. I guess I'm trying to say, in a large, diverse, dynamic and vibrant community such as the wikipedia world community, isn't it good to have some diverse methods and platforms for discussion? it seems to me to have some obvious benefits. Sm8900 (talk) 13:54, 8 August 2022 (UTC)

Just a note that anyone can anonymously create an email address at protonmail aka proton.me —TheDJ (talk • contribs) 14:50, 8 August 2022 (UTC)

@Sm8900: Could you clarify whether you're inviting us on behalf of the Wikimedia Foundation, and what particular benefits beyond the wiki interface this forum brings? Best, KevinL (aka L235 · t · c) 18:28, 8 August 2022 (UTC)

hi. no, I am simply an ordinary editor. as far as the benefits of this forum, it is basically that threads there are serving as semi-permanent communication threads, to reach out to communities that are less-represented, and to enable the wikimedia movement to be more inclusive. for one thing, one good feature there is that it can translate mutliple languages easily. Sm8900 (talk) 19:28, 8 August 2022 (UTC)

It's important to distinguish between "official" platforms set up by the Foundation and unofficial platforms created by a group of volunteers. For an official platform, decisions can be made that will apply to a broader community, and there may be an expectations that those who wish to talk about, say, movement strategy are aware of the discussions taking place on the platform. In contrast, I don't think there's any expectation that Wikipedians need to follow what's said on Telegram, Discord, IRC, etc., in large part because the guardrails we have in place ensure that no big decisions can be made there that will affect the broader Wikipedia community. They're for more casual chat and collaboration, or for working on wiki-adjacent projects like planning edit-a-thons or coordinating with museums.

That said, let's be real: MediaWiki stinks for trying to work in multiple languages at the same time. Good for encyclopedia that anyone can edit, bad for multilingual discussion forum. This looks like interesting software that may make it easier to do just that. I'm all for a trial run to see how it might fit in and/or what it might replace. But if you're going to tackle an important, consequential process like movement strategy with that trial, I'd hope the WMF is clear that it's unofficial and optional -- that Meta is still the primary site where decisions are documented and decided. Perhaps a staffer can clarify this (or perhaps Sm8900 knows the answer?). — Rhododendrites ^talk \\ 19:39, 8 August 2022 (UTC)

@Rhododendrites, thiose are all very good and valid points. I can absolutely attest that the MS Forums are not to replace any official processes, any currently-existing forums generally accepted by the community, such as Village Pump, or any and all internal decision-making processes in any way. none.

this is purely meant as a way to give a forum and a voice to communities and to groups who have previously been under-represented here. thanks. Sm8900 (talk) 20:35, 8 August 2022 (UTC)

Necesito ayuda

Hola, si alguien es Bibliotecario/Administrador en Es~Wiki, necesito que me hagan el favor de enviar el código de mi página de usuario a mi correo electrónico joabinfante2016 @gmail.com porque allí me bloquearon injustamente y deseo el código para usarlo en otra Wiki. Yo me comuniqué con ellos pero me contestaron de mala manera y no me quisieron ayudar.
Joab Israel Infante Lee (talk) 21:15, 5 August 2022 (UTC)

@Joab Israel Infante Lee: Hola, no solemos involucrarnos con problemas y cuestiones relacionadas con otras Wikipedias. ¿Quizás probar Meta-Wiki? — TheresNoTime (talk • she/her) 21:25, 5 August 2022 (UTC)

Muchas gracias! Joab Israel Infante Lee (talk) 21:32, 5 August 2022 (UTC)

Video streams to view events at Wikimania 2022, this week

Wikimnania 2022 is now taking place. feel free to use the links below to view any part of the events! You can view live video anytime. Enjoy!

• LINK TO MAIN PAGE:
  • https://wikimania.wikimedia.org/wiki/Wikimania
• LINK TO WIKIMANIA PAGE ON META:
  • https://meta.wikimedia.org/wiki/Wikimania_2022
• TENT1:
  • https://www.youtube.com/watch?v=B6IzvTjjspM
• TENT 2:
  • https://www.youtube.com/watch?v=5ZVHwu0z9rQ
• TENT 3:
  • https://youtu.be/Yb55e54mgBw

thanks! Sm8900 (talk) 21:00, 11 August 2022 (UTC)

Below are some additional helpful links. Wikimania 2022: The Festival Edition! August 11-14, 2022

LINKS:

• Program Schedule: https://wikimania.wikimedia.org/wiki/Program/Schedule
• Hackathon schedule: https://wikimania.wikimedia.org/wiki/Hackathon/Schedule

Pheedloop conference platform:

• website: https://pheedloop.com/wikimania2022/virtual/
• mobile web: https://go.pheedloop.com
• Android app: https://play.google.com/store/apps/details?id=com.pheedloop.go
• iOS app: https://apps.apple.com/ca/app/pheedloop-go/id1551987961

Conference Telegram chat groups:

• Wikimania Help Desk: https://t.me/+SRPuzZZDC41mMmU5
• Wikimania General: https://t.me/wikimaniachat
• Wikimania Social: https://t.me/wikimaniasocial

thanks. --Sm8900 (talk) 21:02, 11 August 2022 (UTC)

EMERGENCY DISCUSSION: WMF prohibits community from voting for candidates of our choice in Board seats election

Note: Currently seeking clarification. I will withdraw this discussion if the new voting only procedures only apply to "affiliate" seats, and community seat elections continue without constraint.

Short statement: There is no time for a conventional RFC. Voting for the Board of Trustees election is scheduled to begin August 16. There are 12 candidates confirmed as eligible, however the WMF is only allowing us to vote among 6 committee selected candidates. Hopefully this discussion will rapidly manifest clear consensus on whether this is acceptable, and if not, discussion for swift action. Alsee (talk) 09:36, 12 August 2022 (UTC)

Extended explanation: Last year the WMF ran a Call for feedback: Community Board seats. The section #Problems to solve essentially objects to the outcome of past community votes as a "problem" to be solved. The Call for feedback proposes several possible plans for eliminating or restricting community voting. As far as I saw, feedback on these proposals generally ranged from negative to hostile.

12 candidates were certified by WMF Trust&Safety as eligible for the upcoming election: 12345 6 7 8 9 10 11 12

The WMF has established a new Analysis Committee. The Analysis Committee considered the 12 candidates' positions on various issues. 6 candidates were approved, 6 candidates were eliminated.

On August 16 the WMF is going to open the voting website. Only the six approved candidates will appear on the ballot. The community is de facto banned from voting for any of the other 6 certified-eligible candidates. I believe they have also excluded any ability to cast any sort of "oppose" vote. Either you vote for one of the candidates that they want you to vote for, or you are denied any vote or participation at all.

Discussion

• Illigitimate election process. This is an Iranian style sham election, were the people are only permitted to vote for candidates approved by the Theocratic committee. If others agree, I would support almost any action to reject this sham election. In addition to informing the WMF and the Board of our objections, we can ban any any attempt to advertize this sham election on this wiki. That would specificaly include a ban on any sitewide notice. We can also spread the word to other communities. Alsee (talk) 09:36, 12 August 2022 (UTC)

  The candidates haven't been "approved" by the WMF. They've been elected by Wikimedia affiliates (WMUK, WM Indonesia, WM Canada etc) by proportional representation. If I understand this correctly, the two people who will be chosen by the community will join Shani Sigalov on the Board as representatives of the interests of affiliates. Apart from Jimbo, the Board currently has 10 people, of whom the community has elected four, two are those elected by the affiliates (without a community vote, unlike this time) and the other four are appointees selected "for specific expertise"; the meta page seems to imply they've been chosen by the rest of the Board, not the WMF's corporate apparatus. One of the members appointed by affiliates, Natalia Tymkiv, now holds an appointed seat as Board Chair. W. Tell DCCXLVI (^{talk to me!}/_c) 10:50, 12 August 2022 (UTC)

• False alarm. The board members which are being replaced were the board members proposed by the affiliates, not by the community. (There is an extension of the Board, this is why now we have more seats, irrelevant for the discussion). We did not even ever vote for them, the affiliates decided themselves. Now the affiliates selected six candidates and we have given a chance to vote. I do not see in any way how this is out of order.--Ymblanter (talk) 09:54, 12 August 2022 (UTC)

  Indeed, this is an vast improvement over the past processes. Maybe not perfect, but this ensures that affiliates seats have community support. Headbomb {t · c · p · b} 10:15, 12 August 2022 (UTC)

  @Ymblanter I did not see / was unaware of any indication that this vote was for Affiliate seats. I will happily withdraw this discussion if you (or anyone) can point me to some page showing that the next election is not going to filter candidates. Alsee (talk) 10:45, 12 August 2022 (UTC)

  @Ymblanter: Er, no. The distinction between affiliate seats and community seats was abolished last year, and the process used this year was explicitly advertised as a process that "may refer not just to the two seats mentioned, but also to other, Community- and Affiliate-selected seats." Andreas JN466 11:12, 12 August 2022 (UTC)

  @Wilhelm Tell DCCXLVI @Fram. The answer was found by @Andreas JN466, thanks. The Foundation is eliminating the distinction between Affiliate and Community seats. Therefore the community is to be restricted to voting for approved candidates in all future elections. Alsee (talk) 11:27, 12 August 2022 (UTC)

  Looking further, the situation is clear as mud. I am digging for more info. Alsee (talk) 11:52, 12 August 2022 (UTC)

  @Alsee: The board refuses to be drawn on the method to be used for future elections, saying either nothing when asked about this or restricting themselves to saying that this is a decision to be made later, they're not thinking that far ahead, etc. See [8]. But it seemed to me the insistence on mentioning that the seats contested this year are former affiliate-selected seats betrayed a desire to "shoehorn" the new method in, by telling people, "Look, last time the affiliates alone voted for these seats, and nobody asked you at all. So this change is in your favour." Given that these seats are now, following the bylaws change, "community-and-affiliate-selected", what happened last time around is immaterial. Andreas JN466 14:12, 12 August 2022 (UTC)

  @Andreas JN466 I share your concern that this election may be used as silent justification to do the same in the future. However unless there is a shift in responses, consensus may be leaning in the direction of not making a fuss over this election. Alsee (talk) 14:47, 12 August 2022 (UTC)

  Other than the linked mailing list discussion there was a fairly significant fuss about it in German Wikipedia a few weeks ago where volunteers have drawn the same comparison to the Iranian election method. Whether this will have been enough to impress upon the WMF that this approach to democracy and community representation is perceived as suboptimal remains to be seen. Given all the current hubbub about the Elections Committee on Meta-Wiki (here and here, for example) and the way the UCoC was pushed through, I fear that "our way or the highway" is pretty much the new modus operandi of the WMF and the various committees operating under its aegis. Cheers, Andreas JN466 15:14, 12 August 2022 (UTC)

  It won't take much more of this to drive me to the highway. Certes (talk) 15:15, 12 August 2022 (UTC)

• Unsure of resolution - if you create an RfC (or equivalent) @Alsee: you should note the desired resolution you have. Here, the BOT, unfortunately, has the right to tell us to go away and select the trustees by whatever method they wanted. They even, somewhat bizarrely, can do so counter to their own articles (blame the state law - UK law requires getting the charity commission's permission to change the rights of 3rd parties to select trustees). As such, your method would need to be of the "break the railtracks" type (e.g. down tools). I do think this election methodology is poor, hence why I created an election compass question exactly on it, to see if there were candidates who were in the final six who would encourage a move away in the future. Nosebagbear (talk) 09:58, 12 August 2022 (UTC)

  Addendum - apologies, I'd somehow missed we were on en-wiki. I'm not sure why, but is that not just a tad arrogant? Nosebagbear (talk) 10:03, 12 August 2022 (UTC)

  @Nosebagbear I absolutely agree that this is issue is not remotely limited to EnWiki. However this an easier place to quickly get significant discussion. I planned to open the issue on Meta (and further) if-and-only-if the issue gets traction here. Alsee (talk) 10:55, 12 August 2022 (UTC)

• Not sure if this is an emergency or not of interest, as the election pages at meta are extremely confusing and contradictory. Fram (talk) 10:46, 12 August 2022 (UTC)

  I don't think it's an emergency. It appears the Board is in a state of transition from a 10+Jimbo Board to a 15+Jimbo Board, and is adopting new electoral procedures - instead of affiliates simply appointing their two members like before, they shortlist six, from which the community chooses two. The meta pages are indeed arranged unintuitively though, and I may be wrong. W. Tell DCCXLVI (^{talk to me!}/_c) 10:54, 12 August 2022 (UTC)

• Possible explanation: The members being elected now are being elected to fill the traditional two seats on the Board reserved for the representatives of the interests of affiliates. Since 2008 these two members have been elected by Wikimedia affiliates and user groups (single transferable vote, with each affiliate organisation and user group getting one vote), initially for two-year terms and since 2016, for three-year terms. The last election was in 2019 and elected Shani Sigalov and Nataliia Tymkiv to the Board, it's now 2022 and it's time for the affiliates to elect two new people. What's new is that instead of just the affiliates voting, as in the past, now the community also gets to vote once the list has been whittled down to six. The source of confusion could be that the meta page for the affiliate-selected seats and its FAQ haven't been updated to reflect this new procedure. It is also unclear what Shani and Nataliia are going to do now - will they retire, or will they stay on in appointed positions as the Board steadily expands to a strength of 16 from a strength of 11? Nataliia already holds an appointed position as Board Chair, maybe she'll continue. W. Tell DCCXLVI (^{talk to me!}/_c) 11:10, 12 August 2022 (UTC)

  Shani stands for re-election and has been approved by the affiliates. Ymblanter (talk) 11:13, 12 August 2022 (UTC)

  Nataliia's term ends in 2025; her status changed from affiliate representative to appointee in March of this year. Andreas JN466 11:33, 12 August 2022 (UTC)

• Sorry, I don't see the issue here. If the references in question said what the OP says they say, then we might have something. The entire set of objections seems to be invented out of whole cloth by the OP, for reasons that I cannot fathom. Their characterization of the "Problems to solve" thread is particularly problematic. The discussion there is primarily about expanding the voices heard at the board level, especially from minority languages outside of the large Western European and North American ones. The OP, for some reason, characterizes this as a desire to restrict the community? I have a hard time getting behind any proposal by someone who writes such blatant mischaracterizations. If there is a problem here, the OP is doing themselves no service by inventing nonexistent problems to get everyone riled up. Additionally, it appears that the new voting procedure this year seeks to expand community participation by allowing wider community voting that was previously only done through the affiliates. This is really not what the OP says it is. --Jayron32 11:16, 12 August 2022 (UTC)
• Comment Please let us not have people arguing that these used to be affiliate seats, and therefore the community is now better off by being given a voice at all on these seats. The distinction between affiliate seats and community seats was abolished last year, so this is now the only type of seat the community has any input on. Moreover, the Iran-like process used this year was explicitly advertised as a process that "may refer not just to the two seats mentioned, but also to other, Community- and Affiliate-selected seats." --Andreas JN466 11:19, 12 August 2022 (UTC)

  See also the exchange between myself and Dariusz shown in this Wikimedia-l post. There has been no commitment whatsoever from the board that the election process next year will be any different from this year's. Andreas JN466 11:28, 12 August 2022 (UTC)

  Odd oldid to use, given that the current page bolds "affiliate" and "community" differently based on how the members were voted there. This is probably what you're looking for. W. Tell DCCXLVI (^{talk to me!}/_c) 11:30, 12 August 2022 (UTC)

  To be clear: that bolding was introduced here by a volunteer (User:Sänger), merely to mark who elected these board members. It does not represent any formal difference in status between the various board members, that difference having been abolished in the bylaws last year, as your diff shows (thanks for adding it). Andreas JN466 11:41, 12 August 2022 (UTC)

  The loss of fully community-appointed seats makes me uneasy and apprehensive about possible power struggles in the future between the community and affiliates, which could make whoever was elected by this split process suscpetible to feeling like they have to choose a side... should they stand for the affiliates or for the community? Meanwhile the WMF appointees are relatively shielded from having to owe allegiance to anyone, which could result in them voting as a bloc to advance WMF's superiority while the elected members wrangle with their confusion. I don't know, maybe the views of affiliates do not differ too much from those of the community, or maybe having six choices for every two seats (or a similar ratio) allows us to choose members sufficiently aligned with the community...

  I don't think the current slate of WMF-appointed people would behave dictatorially, but this merging of affiliates and community makes it possible in the future. Not saying it will happen, but it could... W. Tell DCCXLVI (^{talk to me!}/_c) 11:46, 12 August 2022 (UTC)

  Wait, what am I saying, there won't be WMF appointees, will there? The non-elected ones will be chosen by the rest of the Board. W. Tell DCCXLVI (^{talk to me!}/_c) 11:53, 12 August 2022 (UTC)

  So essentially the Board will end up with 8 elected members voted for by the mixed affiliate/community method, and 7 chosen by the elected ones. Sounds less bad, yes, but I still don't understand why the community-only seats were abolished. The affiliates need representation, yes, but not like this. W. Tell DCCXLVI (^{talk to me!}/_c) 11:57, 12 August 2022 (UTC)

  The potential problem if this is the method that will be used for all future community-and-affiliate-selected seats is that all candidates will be filtered according to affiliate interests. For argument's sake, imagine a candidate arguing that former Wikimedia CEO Sue Gardner was correct when she said: "I believe that currently, too large a proportion of the movement's money is being spent by the chapters. The value in the Wikimedia projects is primarily created by individual editors: individuals create the value for readers, which results in those readers donating money to the movement ... I am not sure that the additional value created by movement entities such as chapters justifies the financial cost, and I wonder whether it might make more sense for the movement to focus a larger amount of spending on direct financial support for individuals working in the projects." What are the chances of such a candidate making it through today's affiliate selection process to get into the shortlist?

  There is another potential effect of board enlargement on board vote mathematics. In the new 16-member board structure, the seven appointees need two community-and-affiliate-selected members to outvote the rest of the board. In the old board, this would have been five appointees joined by two affiliate or community representatives. The difference is that with the old board structure, two community or affiliate seats represented 40% of those 5 seats. Under the new structure, two community-and-affiliate-selected board members are 25% of those 8 seats. This is academic at the moment, as the board has not (yet) been expanded to 16 members, but perhaps worth bearing in mind. Andreas JN466 14:05, 12 August 2022 (UTC)

• This seems to be a misunderstanding of the election process. Reading m:Wikimedia Foundation elections/2022, it seems there was a pool of twelve candidates approved by WMF; the affiliates shortlist this to six, and then the community votes on those six. The "Analysis Committee" provides advice on the candidates to the affiliates, but did not decide the shortlist. The meta pages could perhaps be made a little clearer about this process, but it is not an "Iranian style sham election" by any stretch of the imagination. It's one method to balance the various interests; others have been tried in the past, and others will no doubt be tried in the future. Sure, we can debate how good they are, but we don't need to scream about shutting the whole thing down like this. Andrew Gray (talk) 12:14, 12 August 2022 (UTC)
• 12 candidates, affiliates narrowed the field to 6, now the community votes for 2 of those 6. That's the process this time around. There's no emergency. — Rhododendrites ^talk \\ 13:03, 12 August 2022 (UTC)
• I've had a decent amount of my own concerns with this election process (ElectCom...), but the voting style wasn't one of them. The affiliates voted via STV on the 12 candidates to narrow it to 6, and a community election will select 2 from the 6. I didn't particularly agree with the Analysis Committee's results, and their second batch of results was basically completely unhelpful (almost everyone was ranked the same?), and we (Wikimedia Stewards User Group) basically ignored it in casting our vote. Best, Vermont (🐿️—🏳️‍🌈) 14:17, 12 August 2022 (UTC)
• 
  Maybe next time you could ask for clarification on the process first instead of posting ALL CAPS warnings everywhere? —pythoncoder (talk | contribs) 03:43, 13 August 2022 (UTC)