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, 5, 6, 7

Update: Scheduled shutdown of Wikidata descriptions on EnWiki

Background: Some time ago some Foundation staff thought Wikidata item-descriptions could be used as convenient short-descriptions for Wikipedia articles. They began displaying them in several locations on our articles or as descriptor/links to the articles. Several concerns arose when the community noticed and examined the practice, resulting in consensus against using Wikidata on/for our articles in this fashion. (Link to one of several discussions.) Several editors and I discussed collaborative resolution with staff. The Foundation created a new feature allowing us to create and manage these descriptions locally (see WikiProject Short descriptions). The Foundation wanted to avoid suddenly blanking all descriptions, so Wikidata descriptions continued to appear when no local description is present. The Foundation agreed to shut complete the shutoff of Wikidata descriptions once we had created approximately 2 million local descriptions.[1]

I am happy to announce there are now 2,250,000 mainspace pages with short descriptions - approximately 1,939,000 articles, approximately 312,000 disambiguation pages, plus thousands of other assorted pages in and out of mainspace (portals, help pages, drafts, redirects, project pages etc).

Almost two months ago I created Phabricator task T248457 for the WMF to implement the agreed shut-off. The task appears to have slipped through the cracks unnoticed/forgotten. Ping DannyH (WMF) who gave the original shutoff commitment (or any Liaison or other staff) to get the ball rolling on this. I am eager to celebrate successful collaboration and resolution on this issue. Thanx. Alsee (talk) 13:39, 15 May 2020 (UTC)

In case it is unclear from the above, the WMF committed to disabling short description Wikidata fallbacks: the WMF plan is to switch from a Wikidata-fallback to full enwiki control when there are 2 million non-blank short descriptions on enwiki (quoting DannyH (WMF) from the discussion linked above). They have not done so yet, even though en.WP has exceeded that criterion by over 10%. – Jonesey95 (talk) 16:53, 15 May 2020 (UTC)

Alsee, Thank you for the update. —¿philoserf? (talk) 17:12, 15 May 2020 (UTC)

It's worth reminding DannyH (WMF) of his statement at the time: "the WMF plan is to switch from a Wikidata-fallback to full enwiki control when there are 2 million non-blank short descriptions on enwiki". Nevertheless, we are going to have to wait for somebody to triage phab:T248457 and then get it assigned and finally get it implemented. There's no timescale for that, nor is there any likelihood that anyone other than DannyH will feel under any obligation to do the job. I can only suggest that everyone who thinks that it's important for staff to respect their promises to the community, should post on that phabricator thread to urge some progress on implementation. --RexxS (talk) 00:05, 16 May 2020 (UTC)

• It would be good to see enwp control. We have a large number of editors working and we can do this. Wikidata is a super fine project, there is no doubt on it. However several things continue to disturb me: example, one Wikipedia article has an IMDb or Twitter external link or some other article value being called from Wikidata. Now you go to Wikidata, and find they are linking back (imported from/Reference) to English Wikipedia. This is confusing and make things circular (note: this particular topic is not in scope in this discussion, and we may discuss somewhere else if you want). Coming back to short descriptions, if we really need short descriptions, we should do it following our own guidelines and thoughts, and not from another project, specially where generic item descriptions are mass-created using QuickStatements and other tools. Regards. --Titodutta (talk) 00:49, 16 May 2020 (UTC)

  @Titodutta: one of the first features I implemented in Module:WikidataIB was to filter out values that were unsourced or referenced only to Wikipedia, That facility has been available for four years now, so there's no excuse for having the feedback loops you describe. If you let me know whenever you find those sort of problems, I'll fix them. --RexxS (talk) 01:20, 16 May 2020 (UTC)

  • I did not prepare a list. I'll create one on the go now. Anyway, a couple of (not the best) examples I can find now: Jan_Schmid external links "FIS Nordic combined skier ID" is on Wikidata, Wikidata says it is imported from English Wikipedia. Similarly "EL" section Official website at WePay. It might be a good idea to directly link, than going to Wikidata and learn it was imported from Wikipedia. --Titodutta (talk) 02:04, 16 May 2020 (UTC)

    Okay - that shows up because Zyxw used #property which doesn't filter. I can fix it by using a Wikidata call, but are you sure you need references for an identifier? An identifier will link to the entry in the relevant database, so following it will verify the id almost always. I don't usually worry about sources for images and their captions for the same reason. Anyway, I'll have a look at any list you want me to. --RexxS (talk) 02:35, 16 May 2020 (UTC)

    First, this is unrelated to the WMF so perhaps discussion should move elsewhere. The last Wikidata RFC was a long time ago, a lot of issues are unresolved, and I would welcome some clarity. If anyone gets the ball rolling on that, please ping me with the location. RexxS: On a personal note I've noticed some of your comments elsewhere to the Foundation, particularly in relation to Wikidata descriptions, and I wanted to express my appreciation. Back to the immediate topic, it sounds like you're considering a "fix" of filtering out values that are sourced from Wikipedia. In this case, I don't think that was the concern. If you recheck Titodutta's comment they didn't want the value gone. They were suggesting that the info should be "directly link"ed from Wikipedia, rather than coming through Wikidata. See my diff. I want to know whether or not the community wants edits like that applied broadly. I think it's an improvement, I believe(?) that is what Titodutta was suggesting, but we're in consensus-limbo on it. Alsee (talk) 11:11, 17 May 2020 (UTC)

• It's truly a pity to have wasted so much efforts adding clutter to articles. Nemo 14:21, 17 May 2020 (UTC)
  • If you mean the short descriptions are clutter then I very strongly disagree - they're extremely useful and the big shame is that they're going to disappear from the majority of articles if wikidata fallback is turned off (if it must be turned off, waiting until local coverage is close to 100% would achieve the goal without the any unnecessary accessibility issues). If you mean that the local (vs soured from WikiData) descriptions are clutter, then I'm not sure I agree - they're certainly unnecessary duplication of effort but a single line in the page source isn't really what I'd call "clutter". Thryduulf (talk) 14:27, 17 May 2020 (UTC)

    I wouldn't mind relying on local short descriptions. A few days ago, someone changed wikidata descriptions to label iCarly seasons as "child pornography" and "isis propoganda", but I only noticed because they bragged on Twitter. Changes to local short descriptions will show up in people's watchlists. Schazjmd (talk) 22:52, 20 May 2020 (UTC)

    Can't we just make wikidata changes show up on watchlists on an opt-in basis? Enterprisey (talk!) 04:07, 11 June 2020 (UTC)

    Can't wikidata get some form of ClueBot running to revert vandalism like that? It's such a big problem. {{u|Sdkb}} ^talk 04:41, 11 June 2020 (UTC)

• I wasn't involved in the prior discussions about Short Descriptions, so I don't have a well-formed opinion about them, but since this is the WMF page, I think the scope of the discussion here ought to be limited to encouraging the WMF to abide by the agreed-upon community consensus, not challenging that consensus, which inappropriately muddles things. As a new page, we need to set down some strong norms about what is okay to post here. That said, there does seem to be a fair amount of sentiment questioning where we are at with short descriptions, so I think it might be appropriate to open up a conversation at a more appropriate venue to take stock of where we are at with short descriptions and to potentially reassess whether we ought to go ahead with using 2 million as the point to cut off Wikidata imports. One piece of data that I can't resist sharing (despite what I just said above) since it might help frame the discussion is this: of the 43,000 Level 5 Vital Articles (example of the kinds of pages in that group here), currently 19,000 (44%) have no short description. {{u|Sdkb}} ^talk 19:43, 20 May 2020 (UTC)

  Sdkb we're all figuring on the scope of this page together. For what it's worth: My concept when I created this page, and according to the notes at the top, this is the correct page for discussing and forming consensus on the relevant topics. Therefore this would be the correct place to consider a new/different consensus. That said, I was also a central participant in the previous discussions. The consensus was actually to eliminate the Wikidata descriptions immediately, effectively blanking everything while we rebuilt local descriptions. Waiting for 2 million descriptions before shutoff was a compromise with the WMF, insofar as it wasn't particularly unreasonable and no one pressed the issue any further. At that time not shutting off wikidata, or waiting for "close to 100%" local descriptions, were pretty well WP:SNOWy territory. I expect that remains true today. Alsee (talk) 22:27, 20 May 2020 (UTC)

  Alsee, that makes sense. I'm concerned a little, though, that having too many conversations directly on this page (given how sprawly they can often get) might make it harder for WMF folks (who are understandably very busy) to follow along with it all. For some issues, it may be better to discuss them elsewhere as a sort of staging area, and then to come here once they're decided enough that we can present a more straightforward "this is what the community thinks" message. (We'd of course link to the full discussion; the idea isn't to hide anything, but just to keep this page more readable.) {{u|Sdkb}} ^talk 08:03, 24 May 2020 (UTC)

Ping Whatamidoing (WMF). The Foundation agreed that this would be done once we hit two million descriptions. There has been no effective response on phabricator T248457 since March 25, and DannyH (WMF) hasn't responded to the ping three weeks ago. Can you help get a response on this? Thanx. Alsee (talk) 23:13, 4 June 2020 (UTC)

We don't appear to be having much luck with this do we. Any ideas for next steps?©Geni (talk) 16:38, 10 June 2020 (UTC)

Given that Danny is active, and his line manager is probably Katherine Maher, probably suck it up. And stop adding short descriptions. Unless someone can get her attention on Twitter. I do not think she is paying any attention to what is happening on Wikiprojects. I am not going to resign an admin bit over it.--Ymblanter (talk) 18:12, 10 June 2020 (UTC)

And do not forget to take it with the candidates on the Board elections which are going to happen next year. Some of you (not me) may even try to check with the candidates from affiliates.--Ymblanter (talk) 18:15, 10 June 2020 (UTC)

One option is to effectively shut off Wikidata descriptions from our end. Right now there is a filter in place to prevent us from setting a description that is blank or only punctuation. We could modify {{short description}} to check if the value is blank, and then fill in some non-blank value of our choosing. (Perhaps "No description yet.") Then we can do a bot run to make sure {{short description}} is present on every article.

Another option (and we can proceed with both options simultaneously) is to draft a message to Executive Director Katherine Maher and submit it as a formal consensus message from the EnWiki community. My concept would be to start by expressing serious community concern at the poor relationship, poor alignment, and poor level of partnership between the Foundation and the community. I'd suggest phrasing it like 'perhaps you are unaware of these systemic problems', as I suspect staff aren't reporting these issues up to the Director. Then we briefly lay out the Short Description case, that Wikidata descriptions were deployed without consulting the community, that there was a commitment to shut off Wikidata descriptions once we created 2 million descriptions, and then lay out how long the Phab task has been ignored, how long the manager who made the agreement has been non-responsive, and how long the liaison has been non-responsive. (Note: The liaison was only pinged 6 days ago, which is not good but also not badly excessive yet. However those figure will presumably be higher if/when we deliver the message.) Then I would close by requesting her help improving Foundation-engagement, and that we have other specific concerns we hope to be able to bring to her attention. I tend to procrastinate, but I'd be willing to draft it and open the proposal if there's support for this route. (Ping me for quickest action.) I have other specific issues that I want raise for consensus-discussion, but I think we should start with this one simple item. Asking the Director to follow through on an existing Foundation-commitment should be comparatively easy, and it will hopefully establish the path for trying to resolve other issues. Alsee (talk) 20:45, 10 June 2020 (UTC)

I pinged DannyH on 16 May in this very thread as he's the one responsible for keeping the promise he made, so he has no excuse for not having enough time. I can't help but wonder whether we could take the unusual step of discussing the issue on Jimbo's talk page first and asking for his help and advice. That would at least make sure that we try all of the avenues available to us before starting a formal complaint to the CEO. It would also perhaps raise the profile of the problems we've encountered because of the number of talk page watchers there. I almost made that very post there today, but I thought it would be reasonable to leave it a few days yet, just in case we do get a reply from WAID as she was only pinged a few days ago. --RexxS (talk) 23:45, 10 June 2020 (UTC)

The end of the fiscal year is always a busy time of year for him. He and I are usually in a meeting together on Mondays; I'll try to ask him about this the next time I see him. That may be more effective right now than asynchronous communication. Whatamidoing (WMF) (talk) 17:39, 11 June 2020 (UTC)

thanks WAID.--Ymblanter (talk) 17:57, 11 June 2020 (UTC)

@Whatamidoing (WMF): It's now been more than a week. * Pppery * _{it has begun...} 15:23, 21 June 2020 (UTC)

Hi everyone, I'd like to let you know that we are currently working on plans to make the switch to entirely using local short descriptions on English Wikipedia, without the Wikidata fallback. We really appreciate that people have put in so much time and work populating the local descriptions.

I don't have an estimate yet for when we expect the work to happen, because there are a few use cases that we need to figure out. Right now, the Wikipedia apps allow people to write and edit short descriptions on their phone, and that's a popular feature that helps readers who may not typically be Wikipedia editors to contribute new descriptions, and to keep existing descriptions accurate. We want that feature to only use the local descriptions now, so we're going to work on that. We also want to make sure that the descriptions work properly when they're dynamically generated from an infobox, as Template:Infobox settlement currently does.

Engineers are talking about this now, and you'll see activity on the Phabricator ticket. I can let you know when we have a stronger idea of how and when the changes are going to be made.

One thing that I'd like to ask about is the point that Sdkb brought up above: how do we get from ~2 million descriptions to ~6 million (minus disambiguations and lists)? When we make this switch, descriptions are going to "disappear" on a lot of articles, and as Sdkb points out, that will include some important articles. I know that some people have been using automated tools to import descriptions from Wikidata, and I'd like to know if folks plan to continue doing that, and if we can help. I'm interested to know your thoughts. — DannyH (WMF) (talk) 21:46, 22 June 2020 (UTC)

@DannyH (WMF): thanks for your announcement, it is very welcome. I'm sure we will all be happy to hear your estimate for when the work will happen as soon as you have that information.

I'd like to suggest that the solutions to the issues you raise could lie in a change of mindset. When you consider the short description text that accompanies searches on mobile and acts as a subtitle on the app, it may be helpful to forget about Wikidata and to think about short description text as being sourced authoritatively from the enwiki short descriptions; then to refocus your efforts into finding ways of making the enwiki short descriptions as comprehensive as possible. These are some examples that come to mind:

• Support a proposal to import missing enwiki short descriptions from Wikidata on a one-off bot run. This won't be easy to generate support for, but it would represent a way of closing the old chapter and starting a new one.
• Redirect mobile apps that allow editing of short descriptions to creating enwiki short descriptions. Worry about getting those descriptions into Wikidata as a secondary issue.
• Support moves to allow bots to update the Wikidata description field periodically to import enwiki short descriptions as the authoritative text. There will be resistance from Wikidatans but it should be possible to offer a good case for doing it.

I know you'll think "that's what I'm already proposing", but I wanted you to consider principally the focus of where the short descriptions come from. While you think about the issue as an uneasy hybrid between enwiki and Wikidata, you can't hit the targets you want. If you embrace the concept that the authoritative text resides on enwiki, you'll mobilise the large workforce on enwiki (who have already done so much amazing work) to continue to improve and expand the coverage of enwiki short descriptions. Having that sense of ownership of our content is fundamental to keeping work going on it. --RexxS (talk) 22:35, 22 June 2020 (UTC)

RexxS: Well, that is still what I'm already proposing. :) We are now thinking about enwiki as the authoritative text for English short descriptions, and with that as the focus, we want to help to get descriptions on those x-million more enwiki articles. I think we're on the same page. — DannyH (WMF) (talk) 05:58, 23 June 2020 (UTC)

that's a popular feature that helps readers who may not typically be Wikipedia editors to contribute new descriptions, and to keep existing descriptions accurate Well, it is also a feature that turns existing descriptions into inaccurate ones and allows people to create new inaccurate ones where no description existed. This seems to be common for Indian caste articles, where glorification and denigration is the name of the game, and it is difficult to track. - Sitush (talk) 09:27, 29 June 2020 (UTC)

-

@DannyH (WMF) How do we get from 2M descriptions to 6M? Make them visible on the article page in desktop web and mobile web. People won’t edit what they can’t see. Once they get used to seeing the shortdesc on good articles, they’ll want to add them to others.

Perhaps, as Alsee suggested, display "No description yet". But now that we have way more than a critical mass of articles with local descriptions, that mightn’t be necessary.

I know the en-wp community tends to be resistant to changes that are opt-out rather than opt-in. But if we can get consensus on this, will the Foundation support us?

Aside: another team at W?F is looking at simple structured tasks to engage new users, short descriptions could be a good fit for that.

Pelagic ( messages ) Z – (12:19 Sat 04, AEST) 02:19, 4 July 2020 (UTC)

Instead of backsliding, and playing for time, if WMF actually did what they said they would and shut down the displays of Wikidata descriptions, now that we have basically paid up on the extortion, it might encourage Wikipedians to add more short descriptions. · · · Peter Southwood ^(talk): 13:04, 8 July 2020 (UTC)

@Pelagic: The worst part is that some non-W?F editors literally implemented all of the features that W?F keeps saying they'll "get around to adding on desktop" in the short description helper gadget. It displays short descriptions at the top of the page under the title; tells whether they're defined locally, being pulled from Wikidata, or were generated automatically by an infobox or similar template (or if they don't exist in any of those places, which is pretty rare at this point); and it gives options to easily and quickly edit them and import/export them from Wikidata. Literally all the W?F needs to do is flip on that gadget by default and pretty much everyone's problems would be solved. Actually, the community could just flip on that gadget by default: setting a gadget as default doesn't require Foundation action and could just be done by an interface admin after getting consensus. Nathan2055^{talk - contribs} 22:38, 8 July 2020 (UTC)

Nathan2055, I don't think the gadget actually does all of those things, though it is a great gadget. · · · Peter Southwood ^(talk): 12:55, 9 July 2020 (UTC)

@DannyH (WMF):: I actually don't think these problems are quite as difficult to solve as they sound. Our own short description helper gadget already handles displaying and editing locally defined, pulled from Wikidata, and infobox-generated descriptions fine, and allows for one-click importing and exporting between Wikidata and enwiki. That gadget could be flipped on by default for logged-in editors, with a MediaWiki extension-based solution eventually adding a version of it for logged out users as well. As for handling descriptions "disappearing" from articles that only have one defined on Wikidata, I think the easiest solution to that is adding an optional imported=yes parameter to {{short description}}, having that parameter stick the pages in a Category:Pages with descriptions automatically imported from Wikidata category or something similar, and then having a single-run bot go through and import in the Wikidata descriptions for every article which doesn't have one defined locally. Then we can just work through that category and verify that all the descriptions look acceptable. I certainly think that's a better choice than just leaving automatic Wikidata population on, because we've already seen just how ridiculously prone to abuse that system is. It was a good idea in theory, but I think we have enough evidence at this point to say that no project should be displaying data stored on another project that hasn't been checked manually by a human first. It's just too dangerous. Nathan2055^{talk - contribs} 22:54, 8 July 2020 (UTC)

@Nathan2055:, If I remember correctly this is one of the proposals that was specifically turned down previously. Not to say you cannot propose it again, but I fear it would still face opposition on the basis that the descriptions in Wikidata should be checked by a Wikipedia editor before inporting them, and that the person who imports a description from Wikidata is personally responsible for ensuring that it is, if not necessarily very good, at least not very bad. A semi-automated tool to run through a list of pages lacking a short description, using the helper would be OK, as an editor would be checking before importing, at least in theory, and can be held accountable for any harm done due to lack of diligence. I might use such a tool myself. · · · Peter Southwood ^(talk): 11:23, 16 July 2020 (UTC)

• Perhaps the Shortdesc helper should become a default feature for all users (or at least all registered users); I've noticed that my adding short descriptions to articles has skyrocketed since then, and I believe that the acceleration of adding short descriptions to articles will far outweigh the possible increase in vandalism. – John M Wolfson (talk • contribs) 03:00, 16 July 2020 (UTC)

  I agree that higher visibility could greatly accelerate the addition of short descriptions. Making the helper a default feature would make short descriptions more visible, so it could help accelerate addition, if it does not start another flare-up of the squabble over whether they should exist in the first place. Unfortunately, the history of how they were basically forced onto Wikipedia will be dredged up and revisited, both by the people who opposed it in the first place, and probably also by a whole batch of people who have managed to remain unaware of the details of that dispute, and possibly even unaware of the existence of short descriptions. Could be worth a try. This would call for an centralised RfC as it would affect everybody, and as I was heavily involved in the original dispute, I would prefer not to draft it myself. My own feeling is that it is time for WMF to display a little good faith and do what they promised. If and when that happens I am willing to support such a proposal. If it does not happen, that failure do deliver on a promise will be used as a weapon to resist making the gadget a default, which could delay or prevent long term predominance of articles having a short description, which to my mind would be a lose-lose result.· · · Peter Southwood ^(talk): 10:57, 16 July 2020 (UTC)

  Given that installing the gadget increased my own short description adding probably around fivefold, I think it should be the default for registered users, which would accelerate the process of making short descriptions near universal. I can draft an RfC to that effect if you'd like, seeing as it might be inevitable. I wonder what the hold up with the Wikidata-description deprecation is given that more than 2 million mainspace articles (albeit including disambiguation pages) that have them, which was the benchmark as I recall. – John M Wolfson (talk • contribs) 08:42, 17 July 2020 (UTC)

As far as WMF Product is concerned, we'd be happy for the short descriptions to have more visibility on desktop or mobile, either opt-in or not. I agree that being able to see them would help to motivate people to add and update them. People were so adamant in previous discussions about not displaying them, that we didn't know if having them 100% hosted on enwiki would make a difference. It's good to know that's on the table, and I'd be happy to talk more about how to get to consensus, and how we can help.

To respond to the questions above about whether we are doing what we've promised, work on the change has begun — if you're into Phabricator, you can see the progress that's being made on this ticket. — DannyH (WMF) (talk) 18:50, 21 July 2020 (UTC)

While we wait for the squabbling at phabricator about avoiding doing something they are ethically obliged to do to finish, perhaps we should do a bot run to add a short description to all articles where a local short description does not already exist, putting them into a maintenance category and with content stating that they have no short description yet, but anyone can help by adding a suitable short description. This would use existing code to discontinue the use of Wikidata content and make the missing descriptions more visible and findable. Then it would no longer matter how long the issue is avoided by those who want to push Wikidata content into English Wikipedia against community consensus and against the word of WMF that it would be stopped. Cheers, · · · Peter Southwood ^(talk): 11:04, 30 July 2020 (UTC)

That sounds like a great idea in theory, but what short description would be displayed in practice? I believe that WMF has technical measures in place to prevent us from overriding an inappropriate or vandalised Wikidata description with a blank one. Certes (talk) 11:43, 30 July 2020 (UTC)

Something like:"This article needs a short description - Click here if you think you can help" The link should take the editor to an explanation of what is needed in a short description, and after reading it they could click a button indicating they understand and will comply with the requirements, which would skip this stage in future and open the short description gadget on the page they clicked from, which should display the usual options, including copying the SD from Wikidata if it is good enough. This cannot reasonably be described as an inappropriate or vandalised short description, nor a blank one. It would serve the purposes of Wikipedia and incidentally also WMF in a way that maximises usefulness to all, and does no harm to Wikidata, so if WMF were to override it it would be strong evidence of unethical and counterproductive behaviour on their part. Or have I missed something? Logged out users would unfortunately have to go through the instructions every time, or maybe a cookie could help here. · · · Peter Southwood ^(talk): 12:43, 30 July 2020 (UTC)

Those editors who have encouraged the adding of missing short descriptions by bot and user-assisted scripts might like to have a look at the miniproject which is currently being planned at Wikipedia talk:WikiProject Short descriptions#Bot proposal to create short descriptions from scratch, for articles requiring one. Given the sensitivities of some editors to the importation of Wikidata descriptions, we will create new SDs for articles that need them from local information only, without pulling anything from Wikidata. Contributors are welcome. MichaelMaggs (talk) 16:56, 14 August 2020 (UTC)

Phab:T248457 has now been triaged and classified as "Later". Will Wikidata descriptions still be removed as promised, or has the WMF's half of the bargain been postponed indefinitely? Certes (talk) 15:17, 2 September 2020 (UTC)

Clarification from the WMF folks would be appreciated - are you going to do this on your end, or do we need to set up a bot to do this ourselves? Tazerdadog (talk) 23:18, 2 September 2020 (UTC)

Summary

So, in summary:

• The WMF implemented, years ago, the addition of Wikidata descriptions to enwiki articles without informing enwiki of this, without providing any way to monitor or overrule this, ...
• After an RfC which overwhelmingly opposed this, they promised to turn this off, but did this only for some uses and not for all
• When this was found out, the opposition was reaffirmed, but the WMF then, instead of finally keeping their original promise, haggled for a compromise based on rather fanciful data, and got us to agree to add 2 million descriptions, and only then they would turn it off.
• In March, this goal was achieved, and the WMF asked to keep their side of the bargain. It then turned out that while many people on enwiki had worked hard to keep our side of the bargain, not a single thing had been done at the WMF side to keep theirs.
• Some six months later (and three months after it was promised that we would see "work being done" at the phabricator ticket), there is zero progress, and the task is in fact scheduled for "later" and not assigned to anyone at the WMF.

Is this somewhat correct? And if so, why is this in any way acceptable? Fram (talk) 08:38, 4 September 2020 (UTC)

Pinging DannyH (WMF). What steps can the volunteer community here at en.WP take to ensure that WMF staff are able to keep the commitment that you made? – Jonesey95 (talk) 16:08, 4 September 2020 (UTC)

Hi, thanks for the ping — this is a misunderstanding based on ticket numbers. :) The ticket that Certes posted about a couple days ago is Phab:T248457 — that ticket was submitted by Alsee, and that's not the one that the developers are using. I mentioned above that the correct ticket is Phab:T256817, which is currently being worked on — you can click on some of the subtasks to see that discussion and work are happening on them today. I posted a link to the correct ticket number above on July 21st, but I didn't stress enough that it was a different ticket; I just linked the phrase "this ticket". Sorry that I didn't make that clear enough. I agree that we have promised to make this change happen, and we are working on making it happen. Let me know if you have more questions. Sorry about the mixup. — DannyH (WMF) (talk) 20:19, 4 September 2020 (UTC)

Thank you for the explanation, Danny. It's comforting to know that this is still a priority for the WMF. Certes (talk) 20:27, 4 September 2020 (UTC)

Off topic

DannyH (WMF) sorry to change the subject, but while you're here I wanted to give you an important update on the Talk Page project. A quick recap for you and everyone else: Back when the Flow prototype was being built, editors told the project manager that correct wikitext support was fundamental and necessary, and that the project could never be deployed without it. The project manager said he had no intention of fixing it, and cut off communication saying further discussion was a waste of time, and proceeded to build a system with needless wikitext corruption issues. Eventually I had to organize an effective Global Community Consensus across three wikis before the Foundation finally acknowledged there was a problem. You stepped in and did an excellent job running the Talk Page Consultation, genuinely listening to what we wanted. You cancelled the last phase of the consultation, and handed the project over to a new manager. That manager has essentially cloned Flow's back-end design problem. Instead of simply inserting the new comment into the page, he decided to needlessly translate everything through Parsoid before inserting the new comment, then retranslate the combined content back through Parsoid for saving. Again, like with Flow, this round-trip double-translation causes wikitext corruption to the page. Again, the manager has declared that he has no intention of fixing it. Again, the Foundation has terminated communication. I honestly can't understand why the Foundation becomes actively-hostile whenever we say "don't screw up wikitext". It's such a simple and basic requirement. I thought you might want to look into this. I'm hoping you can avert an RFC against the new Talk Page Project. Alsee (talk) 23:28, 4 September 2020 (UTC) @Alsee: I think you are exaggerating a bit here. The developers of DiscussionTools seem to care about edits using their tool not corrupting unrelated parts of the page. * Pppery * it has begun... 21:56, 5 September 2020 (UTC) Hi Alsee: I'm working closely with Peter on this project, and I'm aware of your concerns about wikitext corruption. From what I recall from a few months ago, Peter asked you for examples of wikitext that you said were corrupted by the tool, and looked into the problems. Other active contributors appear to be satisfied with the team's progress on the tool; some folks on Meta are discussing it on Meta:Babel, with a lot of support. — DannyH (WMF) (talk) 20:40, 9 September 2020 (UTC)

So, instead of a ticket that is unassigned and "later", we have one that is unassigned and "blocked/waiting"... Still doesn't explain why nothing had been done on the WMF side in the years since their promise and while we were active keeping our side of the (WMF-forced) bargain. Looking at the underlying tickets, it seems that some initial activity in early August was the last that actually happened. Fram (talk) 07:05, 7 September 2020 (UTC)

Is there anything we can do to help unblock it or end its wait? Is the Android app board the best place for the ticket (or is it also in other work flows – I'm unfamiliar with Phab "boards")? Certes (talk) 09:14, 7 September 2020 (UTC)

One thing we as a community could do is to never again modify our behavior based upon any promise from the W?F, citing this example of them not keeping their promises. A would be interested in hearing about any other examples of unkept promises by the W?F. If any come to mind please drop me a note on my talk page. --Guy Macon (talk) 17:51, 7 September 2020 (UTC)

Guy Macon, I'm sure it is challenging to be a Wikimedia developer, but there are multiple examples of this phenomenon. Take ISBN magic links (please!). We sure have worked quite a bit, and continue to work, to transform ISBN magic links into ISBN templates after T145604 (follow links there for discussion) and a related en.WP RFC about magic links. Four years later, we're still waiting on WMF developers for the ability to turn off magic links here at en.WP. – Jonesey95 (talk) 04:07, 8 September 2020 (UTC)

I'm starting to see an underlying theme here. I'm sure we're all grateful to the WMF for providing a stable computing and comms platform and for being the legal body which a project with BLPs and other controversial content needs. The problems seem to start when the WMF imposes technical changes: ISBN must be a magic word; short descriptions must be imported; you will change to this text editor or that talk page format. If they are appropriate for and welcomed at some projects then by all means make them an option, possibly even the default with due notice. However, it should be a requirement of any breaking change that it either have community consensus or be easily turned off by local sysops where it is not wanted. We may have differences on other issues, such as the WMF's proposal to share Wikipedia's title and the UCoC, but making unwanted technical change optional would go a long way towards restoring the WMF's former status as a welcome partner. Certes (talk) 10:30, 8 September 2020 (UTC)

The problem is that that would mean that every technical change would result in two version going forwards which becomes a maintenance headache.©Geni (talk) 00:08, 10 September 2020 (UTC)

Certes, as problematic as the foundation can be. I don't think you have a clue how hard it is to develop this platform. Things you are saying are fun if there were 4000 developers working on all this. —TheDJ (talk • contribs) 07:39, 10 September 2020 (UTC)

According to phab:T257486 it's blocked because there isn't an API to allow editing local descriptions from the mobile app (they don't want users being able to edit descriptions but not able to see those descriptions) yet, but building that API seems to be currently being worked on. – Majavah ^{talk · edits} 05:59, 9 September 2020 (UTC)

What happens when the mobile app edits the description of a page which has a local short description? Do they edit the {{short description}} in the WP article, or the Wikidata description? If the latter then the problem they are trying to avoid already exists for two million articles, so it may be wise to disable app description editing anyway, which would unblock the fix. Certes (talk) 10:18, 9 September 2020 (UTC)

Hey all, I want to let you know that work is still continuing on this. I know that seeing something called "Blocked/waiting" seems disheartening, but in this case, that just means another team needs to do something before the first team can pick it back up. I've been assured that the platform team is working on their part this week, and then the Android team will be unblocked. This is taking a while, because we want to make sure that it's actually done correctly — that every place where someone can edit a short description, we're getting the old description from the correct place (English WP page) and the new description is added/edited in the right place (again, English WP page). I know that it's exciting to accuse the WMF of lying and betraying everyone, and I would be the last person to try to deny folks that particular form of entertainment. In this case, we made a promise that we are currently in the process of keeping. — DannyH (WMF) (talk) 17:39, 10 September 2020 (UTC)

Any reason why the work on this didn't start at the time of the promise? Apparently this isn't easy (considering that we are now 6 months since our part of the deal was done), so shouldn't have some planning, analysis, work ahead have been done? It almost looks as if everyone at the WMF was surprised that this needed to be done, and had to start working on this years too late. Surely that can't be true? And I guess Certes would like a reply to his post of 10:18 9 september directly above, which seems rather on point. I notice that Task 257488 only got someone assigned two days ago (well, it was assigned in July, then almost immediately declared "blocked/waiting", and just now assigned to someone else). This sudden revival is of course unrelated to this thread.

It's just that some of us are rather sick of still getting vandalized Wikidata descriptions in various enwiki displays. E.g. a few dating from at least 4 days ago and still active at the time of writing, some simply rather unprofessional (2020 New South Wales Rugby League gets the description "202p new South Wales"), some weird (Verghese Kurien, 600 pageviews per day, is "Indian founder of dairy-cooperative Amul. Atali buttely delicious amul", 2020 Saskatchewan general election gets "Photo of Current Premier of Saskatchewan -Scott Moe".

Or if you want really high-profile pages, take e.g. Karl Marx, with a vandalized description now since more than a day[2] (visible e.g. at the Commons infobox, not just an enwiki problem). Nalanda, world heritage site, vandalized description since almost 24 hours. BLP violations, like for Jacek Kurski, where the description of this politician/journalist was changed 22 hours ago to Polish politician and government propagandist.

To be fair, anti-vandalism at Wikidata sometimes does work. Sodapoppin, a BLP, had his alias "little genitalia man" removed a few days ago[3], after it had been added in December 2018... On the other hand, Baby Phat is still named AMIT KUMAR on Wikidata, since May 2020[4]: this has been copied to other languages through smart bots... It's a good thing that despite the exaggerated claims of having so many editors and views, very few people actually ever look at Wikidata. The only way most people come into contact with it is when it is being pushed into Commons or enwiki.

So perhaps the pressure we put on this is not just a desire to accuse the WMF of bringing on the end of the world, but also a genuine concern that this (descriptions, and more generally vandalism on Wikidata perpetuated to other, more visible sites) is still not being taken serious by the WMF, and that only pressure from groups like enwiki eventually gets some result, perhaps, someday. Fram (talk) 07:32, 11 September 2020 (UTC)

Just an FYI that work is currently being done to unblock the switch to only use local descriptions: [5][6]. Ryan Kaldari (WMF) (talk) 00:34, 18 September 2020 (UTC)

Current work

Hi all, there was some confusion in the conversation above about which Phabricator tickets you should look at if you want to follow along with the work being done. We've cleaned up the tickets so it's easier to follow now, and the easiest place to look is "T256817: Replace Wikidata descriptions on enwiki with local descriptions". If you click through the subtasks in that tree, you'll see that there are patches currently being worked on and reviewed right now. I hope that helps folks who are monitoring the progress. Please ping me if you've got questions, or something that you want to talk about. — DannyH (WMF) (talk) 19:44, 22 September 2020 (UTC)

It’s hard to see what's progressing with all the sub tasks in Phab, but I observe the following now. Joseph Henry Maiden (Q2583058) has "Anglo-Australian botanist (1859-1925)", "botaniste anglais", "australischer Botaniker". At w:en:Joseph Maiden I see "Missing article description (Add)" on desktop shortdesc helper, no desc on Timeless or mobile/Minerva search drop-down, nor in Related Articles from Margaret Flockton. Desc shows in iOS app at the head of the article, but not in search drop-down. For comparison, w:fr:Joseph Henry Maiden has "botaniste anglais" both below the title and in the search drop-down on mobile. Seems to be mostly turned off now for en. Would that reflect your understanding, DannyH? —Pelagic ( messages ) – (22:20 Thu 15, AEST) 12:20, 15 October 2020 (UTC)

Too late now, but ...

Wikidata descriptions generally aren't bad, maybe because few vandals discovered how much "fun" could be had there. The problem seems to be that lack of visibility meant problem descriptions didn’t get fixed as quickly as desired. With the luxury of hindsight, all this could have been avoided if:

1. Changes to Wikidata descriptions were logged as revisions to the linked articles in the same language (perhaps a null edit with summary like "Description on Wikidata (Q93462772) changed from "..." to "..."). Then they would show in watchlists, recent changes, etc.
2. Descriptions were displayed on articles for web platforms, not just search results and related-articles lists. Sure, search results are where they have great value as disambiguators, but being rendered at the top of every page would help readers notice problems.

The horse has bolted for w:en, but please, Danny (and for #1 maybe Lydia), for the sake of the larger non-English Wikipedias, could you consider those as potential improvements? —Pelagic ( messages ) – (21:04 Thu 15, AEST) 11:04, 15 October 2020 (UTC)

Hi Pelagic, Thanks for the ping! I am the right person for the first one. It is in fact already on my list of next things to ask my team to tackle. The ticket for it is at phab:T191831. --Lydia Pintscher (WMDE) (talk) 12:01, 15 October 2020 (UTC)

Thanks, Lydia Pintscher (WMDE), that's great to know. I found Phab:T257588 "Improve the integration of description and label fields with other Wikimedia projects" but that seems more general. Pelagic ( messages ) – (19:47 Fri 16, AEST) 09:47, 16 October 2020 (UTC)

Pelagic extensive previous discussions have made it clear that the points you list would not be sufficient to address the problems or wikidata-item-descriptions acceptable. It never made sense in the first place to try to store language-local content remotely on wikidata. Alsee (talk) 10:08, 16 October 2020 (UTC)

Desktop redesign

mw:Reading/Web/Desktop Improvements/Features.--Moxy 🍁 11:28, 25 September 2020 (UTC)

the W?F has come up with yet another really, really bad idea: "Sticky site and article headers will allow users to access important functionality (logging in/out, edit, talk pages, etc.) without requiring people to scroll to the top of the page." Just what we need: a part of the screen that never scrolls and makes the readable area smaller. And of course the W?F will start small and then slowly grow the nonscrollable area by adding more and more clutter. --Guy Macon (talk) 12:47, 25 September 2020 (UTC)

I made a similar point in July. However, I fear that it's now too late for anyone to listen. If another skin lets me keep the screen height I've paid for, I'll probably use it, otherwise it'll be time to remove Wikipedia from my ad blocker's whitelist so I can get rid of the space wasting elements. Either way, I am reluctant to stop seeing Wikipedia pages as readers see them, which will reduce my effectiveness as an editor. Certes (talk) 13:17, 25 September 2020 (UTC)

64% of readers are on mobile, so if you are interested in what they see, I am sure you will switch to the Minerva skin (which is what is on the mobile website) with a significantly reduced browser viewport width ;). This is only half-facetious; the other half is that we need to be reading/editing with these elements in mind already, yet we have an active desktop editor-ship that either doesn't know or doesn't care about it. I switched to Timeless (Minerva hamstrings editing TBH) so I see a bit more of the impact of changes like the ones that the WMF are implementing as they rework Vector; the implementation of an always-present leader bar in Timeless is quite nice actually. (You should try it.) --Izno (talk) 14:02, 25 September 2020 (UTC)

Izno, I certainly agree that every pixel is precious on mobile. That being said, one of the things I find really frustrating on mobile is having to scroll-scroll-scroll all the way back up to the top to get to the header links. -- RoySmith (talk) 14:29, 25 September 2020 (UTC)

The answer -- something the rest of the world has known for over 20 years but the W?F somehow cannot grasp -- is to give users a choice. Does RoySmith want his header links to stay on his screen? Make that an option in the preferences. Does Guy Macon want the header links to scroll up like the rest of the page? Make that an option in the preferences. Want to make the sidebar go away? Option. Preferences. Alas, instead of giving us more choices, the W?F thinks they know better than we do what we do and don't want on our screens.   :(   --Guy Macon (talk) 15:09, 25 September 2020 (UTC)

You have the ultimate customization in a CSS sheet or a Javascript script for yourself which you or Roy can remove or add to at your leisure. As for what the rest of the world has done, have you looked at any other websites? WMF is making these changes because it's what the rest of the world has recognized will be a good UI (for reading at least; wikis are rare in that we must write and maintain as well). Lastly, every (optional) feature has a cost, and since I know you know how much the WMF spends, spending money maintaining features like that, indeed with access to a rich stylesheet/Javascript system already that you can customize yourself, makes 0 sense in the budget tradeoff that occurs when they figure out what they want to spend money on. --Izno (talk) 15:35, 25 September 2020 (UTC)

Please explain in detail exactly what combination of CSS and Javascript will give me the following IU changes:

• The sidebar on the left goes away, leaving the entire width for content.
• The items on the sidebar are still available if I need them (a menu, a hide/show button on the sidebar... I don't care how.)
• RoySmith gets what he wants (a floating header that stays on the screen while he scrolls) without imposing that "feature" on me, a person who hates it.

Finally, considering finances, you are using the classic "Admiral's Yacht" argument, presumably in responses to my essay at WP:CANCER.

The Admiral's Yacht argument goes like this: if anybody argues that the US is spending too much on the military (See note below) someone proposes that we stop buying bullets for the army or that we stop buying food for the navy. Nobody ever proposes getting rid of the general's private jet or the sdmiral's yacht.

Note: In 2019 the US spent 732 billion dollars (up from 649 billion in 2018) dollars on the military. The combined military budget of the next ten countries (China, France, Germany, India, Japan, Russia, Saudi Arabia, South Korea, Brazil and the UK) was 726 billion dollars, and the combined military budget of the rest of the world (139 countries) was $460 billion dollars.[7]

--Guy Macon (talk) 18:07, 25 September 2020 (UTC)

@Izno: WMF is making these changes because it's what the rest of the world has recognized will be a good UI

That's...actually not really true. There's a sizable group of people who strongly dislike these sorts of changes, and almost everyone agrees that things like the most recent Twitter redesign are objectively worse for desktop users than the previous version. The vast majority of the time, changes like the ones the WMF is proposing here and you're referring to in general are done purely in order to unify codebases so there's only one version of the site/app that has to be maintained. And, since mobile users comprise the vast majority of content consumption (but, importantly, not content creation) on the Internet these days, most of these "unified" site designs are designed for mobile users first and intentionally treat desktop users as second-class citizens.

Not a single interface expert in the world would argue that a hamburger menu is a good design choice for an interface designed to be run on a big 27" desktop monitor, because the hamburger menu was literally invented as a way to move navigation, settings, and tools into a collapsible menu to get them out of the way for mobile users with much less screen real estate. And yet many, many apps intended for desktop users include hamburger menus now. In fact, this very proposal includes six of them (the collapsible sidebar, collapsible language list, user menu, sticky table of contents, and the article tools menu). Which is even more hilarious here, since this is supposed to be a redesign of Vector, the desktop skin, and Minerva isn't even being affected. There's no screen real estate reason on desktop to hide this many tools away in menus. And any reason related to "unifying interfaces" doesn't make any sense here, either: this is wiki software. The entire point is that I should be able to dump correctly formatted wiki markup into it and in return it generates a (mostly) consistent output no matter what device or skin is being used to view the page.

On top of that, this redesign doesn't even accomplish the most basic things it claims to accomplish. Just look at mw:File:Header Logo reconfiguration - commons pt - GIF.gif, and pay attention to the Mona Lisa's hands. The "compact" header redesign literally uses objectively more screen space than the "big" header! And there's a ton of unused whitespace added as well, if I had ten minutes to fiddle with the CSS, I could easily fix it so it's actually smaller than the original header, and it would look way better. I mean, I don't actually understand why the branding needs to scroll with you; if they just had the strip of user links set to sticky instead of an enormous header and all of the attached whitespace, I'd actually be pretty excited because that's a far more useful thing to have access to.

Finally, I also want to point out that, starting with last year's move to iPads having a separate version of iOS, Apple set the default behavior on iPadOS Safari to be to request desktop versions of websites, not the mobile ones. Considering Apple has been aggressively pushing iPads as content creator devices these past few years, this is pretty much an admission from the company that basically designed the modern mobile web that the mobile web is inadequate for the tasks that content creators want to perform. That pretty much says it all, far better than I could. Nathan2055^{talk - contribs} 00:19, 28 September 2020 (UTC)

Right, I'm willing to agree that these changes are focused on the reader rather than the contributor. (Vector had some of those changes too, like moving the top-page portlets to a [sometimes disappearing] dropdown.) And I agree that some of them are pointed a slightly-wrong way for what are the right reasons. I do think if you have specific criticisms of the current design you should voice them somewhere (here? doubtful. maybe mediawikiwiki:Talk:Reading/Web/Desktop Improvements. phab: otherwise perhaps).

However, I do not agree or think that desktop users are being treated as second-class citizens by WMF, especially given the perpetual angst over increasing our contributor-base. (Twitter had another redesign? :) That it's been 10 years since a redesign is something of a miracle; I'm sure we can find some images of the top X websites and see a significant difference elsewhere, whereas we're making these tiny steps that do seem to agree with those bolder than our lovable WMF (the fixed width particularly, mobile-design first approach to reading). (Maybe some day the WMF won't need to maintain Minerva to the same degree or work so hard on e.g. "advanced mobile contributions" that they sank time into last year. That might be nice. So yes, making one codebase for mobile and desktop makes a lot of sense.)

I do think there's probably a future, as with Timeless, that we start taking the blank space left by the fixed width and filling it. Timeless went the more passive direction with another editing sidebar on the right, but I've seen discussion that would put images and infoboxes and the table of contents in those places. --Izno (talk) 16:06, 28 September 2020 (UTC)

Yeah, the hamburger menu is stupid, but introducing a maximum page width is definitely a good thing readability-wise. On the laptop I normally use to edit the text is longer than the optimal number but it’s not too bad. On my phone the text is tiny (which is to be expected when you’re using Vector on a small screen) but it’s a good length. Trying to read an article on a desktop screen, however, is a mess. —pythoncoder (talk | contribs) 20:10, 28 September 2020 (UTC)

Guy Macon, There's several problems with making things extensively configurable. They make the software more complicated, so it's harder to build and more likely to have bugs. If there's N configuration options (assuming they're binary options), there's N^2 combinations, and you have to make sure none of them have weird interactions.

From the user perspective, adding more options makes the software more complicated to use. Every configuration option is just another chance for somebody to mis-configure things. We've already got 9 tabs of options under Special:Preferences. Most of them I don't even know what they do, and many interact in non-obvious ways. -- RoySmith (talk) 23:22, 25 September 2020 (UTC)

• I feel bad for the WMF team implementing this; UI changes always take some getting used to and thus generate initial resistance, and when you combine that with Wikipedia's consensus model, well, that's how we've gotten stuck with the status quo for a decade and become miles behind all the other major sites on the internet (who, contrary to the assertion above, typically have no qualms about the "get used to it" mode of rolling out UI updates).

My advice for the WMF is just to continue actively soliciting feedback and to take on board the feedback that's useful, so that people have as little to complain about as possible.

And my advice to Wikipedians who want to leave constructive feedback is to do so at MW, where the temperature is cooler and it's possible to segment the discussion by feature (and which the desktop improvements team is presumably monitoring more closely than this board). {{u|Sdkb}} ^talk 16:53, 25 September 2020 (UTC)

Concur. The current design and interface is way behind what it should be in 2020. Time for Wikipedia to catch up. ProcrastinatingReader (talk) 12:47, 29 September 2020 (UTC)

• An alternative implementation of these changes that simply added a new skin, Vector2020 or something, would leave current users the option to keep what they have or actively switch to the updated version. My guess is that a greater number would stick with, or even switch to, a VectorClassic theme than use cologneblue - less than 3k total users, according to this 2016 phabricator comment. I also think it would be cool to have a new skin contest every few years to generate new ideas, not replace the default, with the winner added to the user preferences options. Dialectric (talk) 00:25, 26 September 2020 (UTC)

  The problem is of course is that most (if not all) custom gadgets are ski-dependent, which makes switching between skins really painful for active users (who are most likely to use the gadgets).--Ymblanter (talk) 06:14, 26 September 2020 (UTC)

  Do we have stats on gadget usage? I don't doubt that power users make use of them, and am interested in seeing which are the most popular. I don't think I have ever used any gadgets, but given that they are made up of css and javascript, modifying the most popular gadgets to work with the 2-3 most popular skins doesn't seem like too much of a barrier to new skins. The idea I floated, of a Vector2020 vs VectorClassic, would have a lot of overlapping css code.Dialectric (talk) 21:20, 27 September 2020 (UTC)

  Special:GadgetUsage, but that includes all users rather than active users, and obviously excludes non-gadget scripts and styling. I am pretty sure we have a database report that hits the same points with active user count included somewhere. You have most assuredly used things qualified as gadgets based on the fact we have a number of default gadgets (which is good that you didn't realize they were gadgets :). --Izno (talk) 15:44, 28 September 2020 (UTC)

  @Ymblanter: I'm not 100%, but I'm pretty sure that, assuming "Vector2020" was forked off of Vector and used similarly designed elements, most gadgets would still work fine with both skins. We hit this same issue with the Monobook to Vector transition, which IIRC was easily handled by simply making the backends of the two as similar as possible. Even now, almost all gadgets that advertise support for just Monobook or just Vector usually work fine in the other skin. It's just the "weird" skins like CologneBlue that wind up breaking gadgets because they change so many of the UI elements/code. And, just looking at what was proposed here, I don't really see any changes that would massively break gadgets. Everything in general is grouped the same as it's always been, it's just been moved to different places. Assuming the WMF hasn't done some tremendously unorthodox refactoring work behind the scenes to make these changes possible, I imagine that 95% of gadgets would work fine in either Vector or Vector2020 (after all, if they weren't, then the WMF would be shipping a massively breaking change to most people's workflows, and then we'd have a way, way bigger problem than just some minor interface changes). Nathan2055^{talk - contribs} 00:28, 28 September 2020 (UTC)

  WMF has already made a few gadget-breaking changes to the HTML for which we were dutifully warned. That said, most gadget authors have figured out they should design for more than 1 skin and where they haven't, editors like me have complained for nicer integration with their favored skin (Timeless). :) (Now if only the Twinkle interface could come into the 21st century; maybe the deployment of Vue.js will get us there.) --Izno (talk) 15:48, 28 September 2020 (UTC)

  The decision-making process for the current implementation of Vector20 was at phab:T234907. I've discussed offline and the decision has caused some spaghetti in the skin, so I'm sure WMF will eventually come around to having an actual new skin....

  I would guess most people who hadn't made an alternative skin selection would have been dropped into Vector 20 versus "I want Vector". There is a lack of an active "I want the 'default'" skin selection (whatever that might be at the time); that's ancient phab:T22553. --Izno (talk) 15:37, 28 September 2020 (UTC)

  They said they are keeping old Vector as a preference option for logged-in users, but it's to be renamed "Legacy Vector". So you do get choice, Guy Macon and Dialectric, though it’s all-or-nothing: can’t turn on collapsible sidebar and disable max-width at the same time. The new Vector2 (my preferred term) or Vector2020 (per Dialectric and Nathan2055) is to be called ... wait for it ... "Vector". I suggested this is a problem for communication, documentation, etc. but you can guess Olga's response. Blah blah we think our way is best. (Speaking as someone who's had to try explaining to end-users that the Edge blue e is different from the IE blue e, and that Chromium-based "Edge" is completely different from EdgeHTML-based Edge which is now "Legacy Edge", this is not as minor an issue as you might think. One solution is to call the new one "Edgium", but sadly that didn’t catch on.) Pelagic ( messages ) – (05:34 Fri 16, AEST) 19:34, 15 October 2020 (UTC)

Feedback requested on proposed changes to the WMF bylaws

The board of trustees is proposing changes to the WMF bylaws. You can view the call for feedback for more information. — Wug·a·po·des​ 03:44, 16 October 2020 (UTC)

Quick link to the list of proposed changes

• Substantive changes include:

1. Change in number of trustees, to a non-required target of 16
2. Community and affiliate positions merged
3. 8 Community roles, but the majority of the Board is not required to be community-based (in case of resignations etc)
4. These positions to be filled by a not fully stated “community nomination process” determined by the Board, rather than the current ratification of community vote and the affiliate process. Nosebagbear (talk) 19:19, 19 October 2020 (UTC)

IP Address Masking Confirmed As Mandatory

Per a recent update on the IP Masking project, Legal has apparently decided that IP masking is no longer desirable but mandatory, with consultation now limited to implementation form.

Thus far Legal have not provided reasoning on that, but they are set to give a statement (detail level unknown), likely in the next week.

As this will have a significant effect on anti-vandalism efforts, please provide your ideas, concerns, and comments on the discussion page on how to mitigate any negative consequences and utilise any potential positives. Nosebagbear (talk) 10:19, 19 October 2020 (UTC)

This link will be useful here--Ymblanter (talk) 11:01, 19 October 2020 (UTC)

Looks like we need, and will have, an RFC on this. Alsee (talk) 09:38, 23 October 2020 (UTC)

I believe that our traditional workflow is as follows:

1. The W?F proposes something on an obscure meta page. Nobody notices.
2. The W?F posts it somewhere else, and literally everyone who replies hates it.
3. The W?F reaffirms their commitment to listening to user feedback.
4. The W?F announces that they are going to go ahead and do it anyway and you can all go and pound sand.
5. An RfC is posted. Hundreds of people contribute. The result is overwhelmingly negative.
6. The W?F goes ahead and does what they were always planning on doing.
7. The shit hits the fan, admins resign, The Signpost does a feature. Wikipediocracy does a feature. The Register does a feature. The Guardian does a feature. The New York Times does a feature.
8. The board of directors tells the W?F to knock it off. Nobody gets fired or demoted.
9. Return to start.

I will make popcorn. --Guy Macon (talk) 17:19, 23 October 2020 (UTC)

Sometimes they skip step 4 and go straight to step 6, which we then follow with step 5. Extra butter, please. – Jonesey95 (talk) 17:58, 23 October 2020 (UTC)

Depiction of Wikipedia Foundation Wikimedia Foundation destroying Wikipedia with the Fram ban, IP masking, and the 2020 rebrand instead of making obvious but boring improvements to what we have. —pythoncoder (talk | contribs) 18:52, 24 October 2020 (UTC)

The W?F has thrown a lot of crap at us before, but basically saying "we want more vandals" is a new low. Popcorn tastes good. —pythoncoder (talk | contribs) 18:52, 24 October 2020 (UTC)

Wikitree

Is Wikitree a part of Wikipedia? — Preceding unsigned comment added by 2001:8003:2422:C900:2194:A827:975E:F3F6 (talk) 11:45, 20 October 2020 (UTC)

No. --Izno (talk) 13:36, 20 October 2020 (UTC)

See WikiTree. — GhostInTheMachine ^{talk to me} 14:34, 20 October 2020 (UTC)

• Also see Is WikiTree related to Wikipedia? -- RoySmith (talk) 17:23, 23 October 2020 (UTC)

RFC on Discussion Tools content corruption

As a result of the Talk pages consultation 2019, the Foundation ended their strategy to eliminate&replace Talk pages with Flow. It also resulted in a decision to keep existing Talk pages, to keep existing Talk page editing, and to build new tools on top of the existing Talk system. The current project is called Discussion Tools. Discussion Tools is, in general, a promising product. It aims to add a Reply link after comments, and help automatically insert the comment into the page wikitext at the right spot with appropriate indentation. I hope to see it ultimately improved and deployed. However the RFC below describes a design problem with the product, and the project manager doesn't want to fix it. The proposal below seeks consensus that the product not be deployed until the design flaw is fixed. Alsee (talk) 18:43, 28 October 2020 (UTC)

One of the reasons Flow failed was broken wikitext support, including a wide range of content corruption issues. Discussion Tools does not look like Flow, but the backend code basically clones Flow's design flaw. When Discussion Tools is used, it can and does cause corruption to existing Talk page content. I will try to keep the technical details to a minimum. Here is how Discussion Tools should work:

1. You click Reply and enter your comment.
2. Discussion Tools should insert your comment-text (with indents added) into the page-text, and save the page.

Simple, right? Any programmer knows that should never result in content corruption. Instead Discussion Tools is designed like this:

1. You click Reply and enter your comment.
2. Discussion Tools uses VisualEditor's Parsoid engine to translate the wikitext page content into something that isn't wikitext. (I believe it is called HTMLRDFa). It does this even if you explicitly avoid VisualEditor.
3. It inserts your comment into the non-wikitext translation of the page.
4. It (tries to) translate that back into wikitext, and the result of the round-trip-translation is saved.

In theory double-translation is supposed to return back to the original page content, and much of the time the theory works well enough that you never notice it. However the roundtrip translation is insanely complex with many hidden bugs. Below I document multiple different cases where the Discussion Tools round-trip double-translation causes content corruption to the existing page. The problem wouldn't exist if they didn't use round-trip-translation. Note an important point: The examples below are proof that that there is a systemic design flaw. There are likely hundreds, if not thousands of different examples that trigger content corruption. Arguments over the specific examples, or advocating fixing the specific examples, fail to address the systemic problem. The Flow team was never able to fix these problems, and even if the new team could magically fix each individual case there will still be new cases of corruption popping up with no foreseeable end.

Collapsed examples demonstrating Discussion Tools content corruption

Here is a diff reported from FrWiki. The </div> markup was deleted, and the 'Message envoyé' line was moved. Note that Discussion Tools deleted and moved content in an entirely different section from the section where the reply was. This is one staff member making a test reply to another staff member. Quiddity's edit should be be a one line diff, with Quiddity replying "test". Note that it made a various changes to six different lines of Whatamidoing's comment, and then proceeded to wrap both Quiddity's comment comment inside Whatamidoing's table markup. This is a related example, it should be a simple one line diff "Reply to reply 1". Instead it is a multi-page diff, grossly mangling multiple sections in a variety of ways. This test was another one-line-reply made with Discussion tools - "Reply 2." Note that Reply 2 deleted the </span> markup from the previous comment. That causes causing all current and future text to turn red, down to the end of the section. Note that the examples above document at least three completely unrelated cases that trigger corruption. They are surely just the tip of the iceberg of things that will trigger corruption.

Proposed: Discussion Tools not be deployed until it is fixed to avoid round-trip-translation content corruption, including both known and as-yet-unknown cases in this class. (This almost certainly means altering the design to avoid round-trip-translation.) Alsee (talk) 18:43, 28 October 2020 (UTC)

Discussion Tools RFC responses

• Support as nom. They should simply insert the new comment without a needless Rube Goldberg round-trip-translation. It is inexcusable that the Foundation has such gross disregard for fixable wikitext corruption. Alsee (talk) 18:43, 28 October 2020 (UTC)
• Support the need to fix this fundamental flaw before deploying this tool. Barring that, local WP instances should have the option to disable it until it is fixed. Developers might complain that these are edge cases, examples of GIGO, but garbage exists, and the Wikimedia software does not prevent it from existing. The reply tool should simply post an indented (LISTGAP-compliant, presumably) reply, regardless of the text around it. If it can't do a simple reply for some reason, it should emit an error message asking the editor to reply using regular editing. I would love to trust the developers to deploy a mostly working tool and then diligently fix bugs, but as we have seen with the still-in-beta Visual Editor, well-described bugs that damage wikitext and cause headaches for gnomes are not being addressed (e.g. three-year-old T162291; there are plenty more of those). Developers have moved on to the next shiny thing. – Jonesey95 (talk) 21:24, 28 October 2020 (UTC)

RfC Discussion

• @Alsee:, do you have a diff where developers have indicated they're not going to fix this issue? Like you I'm in favor of the goals of this project. I would love for the enwiki community to be able to work collaboratively with the foundation rather than in an us vs them manner. That might not be possible but I worry that the outcome of RfC being successful will be that the foundation writes of enwiki in terms of how it develops this and so we miss out on the value altogether. Frwiki is hardly a small wiki; has there been community discussion about the relative benefits to current drawbacks of the implementation there? Best, Barkeep49 (talk) 21:56, 28 October 2020 (UTC)

  @Barkeep49, I think the answer to your question would depend upon what you call "this issue".  I'm not so sure about these claims.  

  • In Alsee's first diff, Parsoid automagically resolved a stripped tag error on a talk page about six weeks ago.  Resolving Special:LintErrors is generally considered a good thing to do. Moving the blank line around the hidden HTML comment is less desirable, and I believe there's a bug report for this (it might be in the list that will get resolved this WP:THURSDAY).
  • In the second diff, my teammate and I were testing a bug report from Alsee at the mw:Beta Cluster testing site back in February.  This was early-stage testing, months before the tool was offered as a Beta Feature to any community.  This page was corrupted when a wikitext table had all of its formatting syntax with ::: inserted in front of it.  (Wikitext tables require the table formatting codes, such as {|, to be the first characters on the line.) Broken wikitext is expected to produce broken pages, especially when we're talking about super-early stages of software.  To make it harder to create this problem accidentally, the Reply tool hasn't let editors insert tables or templates for months now, unless you put the wikitext in yourself. A longer-term solution requires a significant technical change to wikitext, which may be discussed in the coming months.
  • In the third diff, Alsee ran a test with this content:  {#if:x|<span style="color:red;|<span style="}} font-weight: bold">This should be red 2.</span>.  I have seen Alsee post this string as a deliberate 'stress test' several times on at least three wikis now, but I've never seen an editor type anything like that in a real comment.   There's a bug report for this in Phab, and I understand that it's priority is set to reflect its rarity.

  These diffs are not representative of the everyday experience of using the Reply tool.  If you'd like to see real-world diffs, you can check RecentChanges here at enwiki.  

  You can also look at this table of diffs by wiki, if you want a quick way to find diffs that are more likely to be broken in some way.  The problem rate is low and falling.  Most days, about one out of 150 Reply comments have a whitespace change, and another 1 in 150 have a non-whitespace change.  (Fun fact:  Parsoid isn't the only software that causes 'dirty diffs' on talk pages.  WP:WikEd does, too.)

  If you're interested in why both the Reply tool and User:Enterprisey/reply-link.js are using Parsoid to place comments, then I can tell you more about that, but I think you might be better off trying out the Reply tool for yourself. Unless someone deliberately corrupts this page, then you can try it out right here. Click on https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(WMF)&dtenable=1 and look for the little [reply] links at the end of each signature. I recommend clicking over to the "Visual" section and using the toolbar to ping me or to add a link to your reply. Imagine a world in which you never have to remember how to spell or correctly capitalize editors' usernames. :-D Whatamidoing (WMF) (talk) 22:17, 28 October 2020 (UTC)

  Although I'll give you a hint now: @Izno replied while I was typing, and I didn't have to deal with the edit conflict that would have triggered in any of the regular wikitext editors. Whatamidoing (WMF) (talk) 22:19, 28 October 2020 (UTC)

  Whatamidoing (WMF), I'm not sure how much of your reply is really meant for me and how much is a "I'm going to reply to this comment so I can say everything I want to." Going off the idea that it's at least actually partially directed at me, I have tried the tool. I found it impressive at the early stage I tried it and I found the foundation responsive to the concerns I did raise - more responsive than I'd have actually expected. This is partly why I asked Alsee the questions that I did; I wanted to make sure I wasn't missing something/ Best, Barkeep49 (talk) 22:40, 28 October 2020 (UTC)

  @Barkeep49, if you copy the first happy lines from m:User:Whatamidoing_(WMF)/global.js (this diff), then you can use it all the time. I haven't tried out Enterprisey's reply-links myself, but it's obviously popular, especially with the improvements he made a few months ago. Maybe someday you can tell me how the two compare. Whatamidoing (WMF) (talk) 22:51, 28 October 2020 (UTC)

• As I've said at least once, this proposal is DOA. The technology stack powering DiscussionTools is coming whether you want it or not. I would invite other editors to read through that thread and the other forked thread that Alsee disruptively started twice to try to kill the implementation, as well as the responses from just about everyone else (to wit, the developers have worked issues identified where it is the tool that is at fault and asked for further specific details; Alsee failed then to provide them, so I guess I'm happy there are 3 observed questionable problems above).

  Further, in almost all cases I've seen where round-tripping has caused an actual corruption rather than a suboptimal edit, it has been the fault of frankly bad wikitext. --Izno (talk) 22:06, 28 October 2020 (UTC)