Wikipedia:Village pump (proposals)

"WP:PROPOSE" redirects here. For propose for deletion page, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
• Proposed policy changes belong at Village pump (policy).
• Proposed speedy deletion criteria belong at Wikipedia talk:Criteria for speedy deletion.
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.
• Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
• Software changes which have consensus should be filed at Phabricator.

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Defining a process for the discussion of making Vector 2022 the new default

Hi everyone,

We would love to see the Vector 2022 skin (see what it looks like) become the new default on desktop across all wikis, including English Wikipedia. The skin would be turned on for all anonymous users, and also all logged-in users who now use Vector (the current default). Logged-in users are and will be able to switch to any of our other available skins, including the current Vector. We will be ready to begin making the change at the end of August (and not in July, as previously announced), when the visual refinements and other deployment blockers are ready.

The goal of the project is to make the interface more welcoming and comfortable for readers and useful for advanced users. The project consists of a series of feature improvements which make it easier to read and learn, navigate within the page, search, switch between languages, use page and user tools, and more. The team has been working on this change for the past 3 years, ensuring that every change is thoroughly tested and proven to work.

Making this change is important for both readers and contributors.

We need your help and feedback on how to proceed. We have two requests:

1. We need to talk in a way that works well for the English Wikipedia community. What would be the best format and timeline to discuss the change? We have included a proposed format below, and are interested in what you think about it. If you agree, we can begin the deployment conversation in one week. Here is our suggestion:
   1. Have the deployment conversation that would take 2 weeks. The goal for that discussion will be to identify breaking issues or opportunities for improvement for the new skin. It will be important for us to reduce the risk of bugs or imperfections that would be particularly troublesome on English Wikipedia
   2. After the deployment conversation, we get back to you with a prioritized list of remaining work/fixes necessary prior to deployment
   3. Before the deployment,
      1. Banners announcing the change will be displayed for logged-out and logged-in users
      2. The announcement will be made both on the Village Pump as well as in the Tech News.
   4. We proceed with deployment once the agreed upon fixes are ready.
2. We need to understand the perspectives of different parts of the English Wikipedia community. What forms of communication would help to gather feedback and further raise awareness for the English Wikipedia community? We would like to have an open discussion, but are open to other forms such as requests for comments, office hours dedicated specifically for the English Wikipedia community, or guest presentations at community meetings. If necessary, we can also adjust the timeline of conversations based on your needs.

We welcome your replies here, or via email (olga@wikimedia.org, sgrabarczuk@wikimedia.org), as well as during our next office hours (26 July).

Thank you for your time and help. OVasileva (WMF), SGrabarczuk (WMF) (talk) 12:05, 13 July 2022 (UTC)

The comments from jawp above suggest that this change may not be entirely uncontroversial, with some editors feeling that it is not an improvement. Will enwp be allowed any say in whether the change is rolled out at all, or is it being imposed with our only input being into the details? Certes (talk) 12:48, 13 July 2022 (UTC)

No matter what change, there is a guarantee that a certain amount of people will not feel like it is an improvement. That in itself is a very bad metric for decision making. Are the points being made valid, is there an opt out, what other problems are we solving and are the people responding an accurate representation of the larger group of users. Those seem like much more critical questions to me. —TheDJ (talk • contribs) 13:08, 13 July 2022 (UTC)

I didn’t like it at all when I tried it, but I’ve been won over after spending some time with it. Doug Weller talk 13:14, 13 July 2022 (UTC)

Is there a list of blockers that are being accepted as blocking tasks right now?

• I think the table of contents handling parts are the biggest problem right now. We currently have a lot of control over the TOC placement and display, which seems much harder or impossible with vector-2022.
• Personally, I think with our "wide vector-2022" gadget option being an option for editors, general editors may be OK -- if we can ever get control over what is going on with the left sidebar - it comes, it goes, it is hard to control.

— xaosflux ^Talk 13:08, 13 July 2022 (UTC)

Here are 2 examples of the sidebar with the wide gadget: an article that doesn't for a TOC, and article that has a displayed TOC. In the later, the entire sidebar will collapse, but only at certain display sizes, there is a task out there about being able to collapse the TOC - but very notably, even when collapsed that sidebar stays open an empty. Is the "grid" work going to address that at all? The sidebar element seems to be part of the content container. — xaosflux ^Talk 13:11, 13 July 2022 (UTC)

I quite like the wide-vector-2022 layout and I'm sure I could be won over after a few weeks of it being the default. I think I'm in the minority when I say I like the ToC positioning on the left (but only on wide-vector). I strongly dislike the normal (non wide) version of Vector 2022, and I've left comments here on why this is. As for the OP's question: I don't think enwp will take kindly to a discussion about setting Vector as the default while these issues of narrowness, ToC placement, and unnecessary top banner whitespace exist. Anarchyte (talk) 13:31, 13 July 2022 (UTC)

I don't hate the side-bar based TOC in vector-2022 (even with wide mode) - I mostly hate that when all the sidebar elements (toolbar, and hopefully soon to be TOC) are collapsed or docked, that the sidebar can't be collapsed without also adding in javascript hacks - I'd think this should be possible with css and a layout that allows it to widen if there are contained elements pushing the margin. — xaosflux ^Talk 13:38, 13 July 2022 (UTC)

Hiding the TOC and then regenerating a custom TOC (as in this article does achieve what I'm looking for I suppose - not sure why that is so hard? — xaosflux ^Talk 13:42, 13 July 2022 (UTC)

Perhaps something the team could look into could be having the __TOC__ magic word forcing the TOC to exist within the page instead of in the sidebar. Anarchyte (talk) 14:38, 13 July 2022 (UTC)

Hey @Xaosflux - thanks for the feedback, and quick answer to the sidebar question (I'll follow up on your other points around magic words a bit later). Once the new ToC collapsing behavior is ready (phab:T306660), the gadget should work again to stretch the full width if both the sidebar and the ToC are collapsed OVasileva (WMF) (talk) 13:37, 15 July 2022 (UTC)

@OVasileva (WMF) thanks, looking forward to trying that out - I think it will at least alleviate some worry for logged-in-editors that have concerns about "too narrow" - likely some of the more heavy power editors that are using wide desktop monitors, I don't think it is a big deal for casual readers. From initial notes below, seems like the loosing control of Table of Contents styling in general is at least an emerging concern among editors - I'd hate to see ugly hacks get pushed by the community if there is an impasse (like the continuing problems going on in Wikipedia:Village_pump_(proposals)#RfC:_Showing_Editnotices_to_mobile_editors below with Mobile Front End and developers preventing certain elements from being controllable). — xaosflux ^Talk 13:52, 15 July 2022 (UTC)

• Regarding TOC handling in general, for example in these articles editors have specified a custom right-sided TOC, which vector-2022 overrides. — xaosflux ^Talk 13:34, 13 July 2022 (UTC)

  It seems quite inconsistent though, see this article in vector where editors have determined the best TOC layout type, compared to it vector-2022. — xaosflux ^Talk 13:46, 13 July 2022 (UTC)

  I think the primary reason we have customized TOCs is when they are very long. Of the most common variants, the floating variants ({{toc left}}, {{toc right}}), {{toc limit}}, and {{horizontal toc}} all exist to deal with a long table of contents. General point: except for people who customize their skin selection away from Vector22, I don't think we need to support these at all in the new skin. We can leave the templates alone right now for those people who do use the other skins, if we want. Specific points:

  1. Floating variants: simply don't care
  2. Toc limit: With a per-level collapsible table, totally obsolete.
  3. Horizontal toc: Maybe the only interesting one, since its major use cases are 'letter/number-driven' lists and large categories, and I expect that a TOC that long will be rough on the sidebar version (I haven't checked yet). I think there's probably a feasible feature request somewhere regarding category tables of contents.

  I think forcing the TOC to appear in page besides maybe that last one isn't needed at all (and I don't think that needs anything more than the customization we can already build with a template). Izno (talk) 19:59, 13 July 2022 (UTC)

phab:T306246 was mentioned above in #Consultation on Search improvements by CX Zoom and Ahecht and myself. That must be solved, and not by updating documentation, declaring it not a bug or closing it as a duplicate of $random other task. (I occasionally see tasks getting closed without a real solution so I'm just saying) I see plenty of open tasks on phab:T309972 so there's plenty to do. From a UI perspective, I suggested some improvements on phab:T302641, that alone is a hard deal breaker to switch for me personally. — Alexis Jazz (talk or ping me) 20:31, 15 July 2022 (UTC)

@OVasileva (WMF) / @SGrabarczuk (WMF) - I think the entire design/implementation/documentation/testing about page meta-content and collisions with content things like our "coordinates" templates (see also -Wikipedia:Village_pump_(technical)#Coordinates_in_Vector_2022, phab:T292617, and phab:T281974) may be a bit of a blocking issue here - seeing as we make use of these features on literally millions of pages. I fear there seems to be a bit of tension in layout/design goals between skin developers and community use. What are your thoughts on the best way to reconcile these sort of things? — xaosflux ^Talk 12:41, 22 July 2022 (UTC)

Visual Editor is still in beta as of July 2022

SGrabarczuk (WMF), if you choose to make this change, it will be important to the success of the change to have a team of developers available to monitor forums where bugs and feature requests are reported, create phab tickets actively, and resolve those tickets quickly. Too often, new features are rolled out in beta form (I'm thinking especially of the Visual Editor) and then the development team appears to move on to new projects, leading to bug reports that linger for years (I'm thinking especially of the Visual Editor). I encourage you to designate a place local to en.WP, de.WP, Commons, and other large MediaWiki installations, where editors can report problems without having to travel to unfamiliar sites with different interfaces and watchlists, like mediawiki.org. – Jonesey95 (talk) 14:38, 13 July 2022 (UTC)

Hi @Jonesey95. Oh, that's a very fair comment. I'm giving a bunch of quick replies to different parts of your comment. I hope these bits make sense together:

1. VE was launched, correct me if I'm wrong, like... 9 years ago? we've learned a lot since that. For example, earlier this year, when planning the current Californian fiscal year, we decided that we would dedicate some time this summer and fall (the first months of the fiscal year) just to further improve Desktop Improvements if needed. So that part's safe, not only in our hearts, but on the governance level, too.
2. As a result, some bugs and feature requests will definitely be handled. Depending on how much related to Desktop Improvements, these will either be just done or considered as part of future projects.
3. Vector 2022 is the default on ~30 wikis. On a few of these, incl. French Wikipedia, it has been the default for almost two years! So they've done a great deal of bug-reporting/feature-requesting already. I think both our team and other communities may be truly grateful for that.

SGrabarczuk (WMF) (talk) 15:04, 13 July 2022 (UTC)

Thanks. I wish you luck. If all goes well with desktop improvements and the developers find that the set-aside time is available for other work, maybe some of the team can work on the VE backlog and officially get it out of beta status. A bunch of us gnomes who clean up errors that it generates would be very grateful. – Jonesey95 (talk) 15:52, 13 July 2022 (UTC)

?? "Vector 2022" has been the default on frwiki since 2020? Does it have time traveling properties? — xaosflux ^Talk 18:22, 13 July 2022 (UTC)

@Xaosflux, you are kidding, right? Let's make it clear for everyone around: back then, it wasn't labelled as "Vector 2022", but it was there. We've been adding more and more features and changes, but the first ones (different logo, collapsible sidebar, limited width) have been the default on some wikis since July 2020. SGrabarczuk (WMF) (talk) 19:11, 13 July 2022 (UTC)

@SGrabarczuk (WMF) Yes, that was mostly humorous, just contrasting that the entire current incarnation it hasn't had 2 years of bake-in. — xaosflux ^Talk 19:17, 13 July 2022 (UTC)

Yeah, right. It's a good opportunity to make it clear that this interface isn't static, really. These incarnations are like ogres - both have layers. Some are two years old, and some (like the sticky ToC) are two months old. The older a layer is, the more people have actually used it, noticed bugs, advocated for improvements, everything. It's not like we're pulling Vector 2022 with everything about it out of a hat. I hope it's reassuring. SGrabarczuk (WMF) (talk) 19:29, 13 July 2022 (UTC)

Jonesey95, to sober up here's Growth-Team's profile on Phabricator. Two projects in active development, one project with a new owner and 11 projects with "passive maintenance" (read: unless the building is on fire expect nothing) with the note "New owner needed". Probably just some obscure projects, right? Yeah, it's just WP:WikiLove, WP:Echo, WP:Thanks, WP:Nuke, WP:Page Curation, Special:RecentChanges. Not anything people really use, you know. — Alexis Jazz (talk or ping me) 21:03, 15 July 2022 (UTC)

I suggest having a page somewhere that essentially functions as a press release and/or a list of FAQs. At the miminum, link this page in the banners (i.e. with a CTA: 'Read more about the upcoming change!') so that 1. non-registered visitors can read more about the impending changes (and possibly encourage them to register as editor even if it is just to revert back to the previous skin); 2. interested publications may organically pick it up as a story for their audience. – robertsky (talk) 18:08, 13 July 2022 (UTC)

Great idea, @Robertsky! We're working on a page on wikimediafoundation.org (for readers, media, the "general public"), and we'll definitely have a more detailed FAQ for editors. SGrabarczuk (WMF) (talk) 18:18, 13 July 2022 (UTC)

I'd recommend that said press release/FAQ page should also include instructions on how to revert back to the older vector skin. I imagine that there will be a fair few (including myself) using the current vector who would like revert back to the older form, and while I know how to switch skins, there are some who may not be familiar. Hog Farm _Talk 19:58, 13 July 2022 (UTC)

For this change to be a success you can't just impose this on enwiki; you need consensus from the community. Are you willing to open an RfC that seeks to obtain consensus to implement this change? BilledMammal (talk) 21:25, 13 July 2022 (UTC)

@BilledMammal, I think the proposal pretty much answers your question. Let me rephrase a part of the first message: in the next conversation, we'd like to talk what remains to be done instead of having a yes/no situation. And we do mention RfC there, too. SGrabarczuk (WMF) (talk) 22:36, 13 July 2022 (UTC)

Your comment comes across as if this is a done deal, with only small details (what remains to be done) to be worked out, but the community needs to be able to reject this. It needs to be able to say that it is not satisfied with the current version of Vector 2022, and instead ask you to come back and see if consensus has changed when you believe you have addressed the objections raised in the discussion.

To rephrase my question; are you willing to open an RfC that seeks to obtain consensus to implement this change, with an option that will permit the community to reject the change? BilledMammal (talk) 22:53, 13 July 2022 (UTC)

+1 to User:BilledMammal's comment. In that vein: Consider me an Oppose to switching the default. On my screen at least, V2022 has a very poor layout that looks unclean and would create a poor impression of Wikipedia, forced upon us by the WMF. I want to see a finished product before everyone without an account (that is the majority of users) are suddenly switched to a new (worse) look. Happy Editing--IAmChaos 21:44, 13 July 2022 (UTC) edited 01:50, 14 July 2022 (UTC)

We believe this change is extremely important for readers, and have a lot of data and research that can help us prove this.  That said, we understand that that community might need more from the skin than what is currently developed. That’s why we hope to get into the details so we can identify what needs to be changed before the conversation on whether and when that change will happen begins. That said, to be clear, we will not be rolling out the new skin prior to coming to such an agreement with the community. SGrabarczuk (WMF) (talk) 16:46, 15 July 2022 (UTC)

@SGrabarczuk (WMF): Thank you, I am glad to hear that. Are you able to provide us with the data and research reports so that we can consider this change in that context? BilledMammal (talk) 22:35, 16 July 2022 (UTC)

@BilledMammal see § UX research and usability testing below. There's a great deal available there and at other pages, so please specify what else you're seeking if you'd like additional research. {{u|Sdkb}} ^talk 22:40, 16 July 2022 (UTC)

Thank you, I missed that. BilledMammal (talk) 02:13, 17 July 2022 (UTC)

@IAmChaos Olga and Szymon explicitly structured this conversation as a meta-conversation about process, not a !vote on implementation. Let's respect that by avoiding bolded !votes, just as we do at VPI. {{u|Sdkb}} ^talk 23:02, 13 July 2022 (UTC)

I appreciate that. I will unbold. Happy Editing--IAmChaos 01:50, 14 July 2022 (UTC)

I think just waiting until the "final" release version is ready and usable before starting any discussions on adding it is best. While prototypes are still ongoing it isn't great to start any discussion on a non "final" version when signficant changes can still occur and the outcomes on changes are not released. Using the latest prototypes: Color schemes, borders, toc highlighting & logo choices should be able to be viewed at the point the discussion starts rather than lumped in at the end and not allowing anyone to voice their opinions on these choices specifically isn't a good idea. Terasail^[✉️] 22:02, 13 July 2022 (UTC)

@IAmChaos, @Terasail, we're not there yet. Please take a look at the proposal. You'll find the replies there. We don't have a definition of a "good enough" product. (In a way, it will never be quite "finished", just as most Wikipedia articles never are.) We'd like to make it together with the community, and now, we're asking how do you think we should do that. SGrabarczuk (WMF) (talk) 22:34, 13 July 2022 (UTC)

It sounds like this product, if approved, will see regular releases. Will these releases also be discussed with the community or will they be boldly implemented? BilledMammal (talk) 22:58, 13 July 2022 (UTC)

@BilledMammal, I'm not sure I understand your question. What do you mean? Could you elaborate on that? SGrabarczuk (WMF) (talk) 23:26, 13 July 2022 (UTC)

@SGrabarczuk (WMF): If I have understood you correctly this version of Vector 2022 is not the final version; instead, it will see regular significant updates. My question is what your process for implementing these updates will be; will you do them boldly or will you discuss them with the community first?

In some ways, this question is related to my question above from 22:53, 13 July 2022, which I believe you may have missed. BilledMammal (talk) 00:58, 14 July 2022 (UTC)

Thanks for clarifying your question! What we mean when we say that this is not the final version is:

• We still have some identified issues (documented as tasks) that are not resolved. This is the list that is under this task.
• The two-week conversation we're proposing would be meant to help us define the version upon deployment. We need agreement between our team, the needs of readers, and the community in the identification of what their needs from the skin are. What are the blockers to changing the default? That is the conversation we are currently trying to set up.
• Once deployed, we plan on continuing to work on the desktop experience. Our next focus will be on improving some of the features we’ve built here, but also using some of the things within the new interface to begin exploring goals that are even further-reaching, such as encouraging more interested readers to begin editing.  With Vector on most Wikipedias, we didn’t change the skin for 12 years. This project, while improving usability for existing tools, did not add or remove any current tools from the interface. Once it’s done, it gives us the opportunity to work with communities to provide new and necessary tools both for readers and editors. This is a process that is ongoing and will be done with the feedback and collaboration of the community here and across other projects.

SGrabarczuk (WMF) (talk) 17:18, 15 July 2022 (UTC)

Thank you for clarifying this as well. I am glad to hear that you will seek input and hopefully consensus from the community before implementing any significant updates. BilledMammal (talk) 22:35, 16 July 2022 (UTC)

@SGrabarczuk (WMF) Firstly, thanks for your reply, I appreciate you being willing to answer so please don't feel like I'm jumping on you specifically, its just that you brought this here and I figured I should voice my concerns with a switch to V22. @Sdkb replied to my earlier comment, and I agreed so I modified it with their suggestion. I strongly believe though, even in this so called "meta" conversation about process, we shouldn't be ignoring the issues. Logged out editors are the most populous user, even though they have practically no voice in ProjectSpace discussions. If we are to implement a change to what they see (ie default settings), we need to address this more than other things, because those affected won't discuss it. Here's a quick list of what I've found.

1. The TOC issues. They are being overriden against specific decisions by editors who chose to design a page a certain way. for example, see Alien, which is the first page alphabetically that uses {{TOC right}}, why should V22 override, there is no precedence in monobook, timeless, minerva which are the other skins installed on enwiki. I think overrides like that (and there may be others, this is just what I have seen conversation about above) should fall to editors, not to software.
2. The look of it. Not to be mean to the team who worked very hard on it, and I appreciate what you've done for the MediaWiki community, but I feel that there are (in the current state) some things objectively worse. Why is there just blank space to the right of articles when V(legacy) reaches the edge of my screen? Why is there space blank to the left of the sidebar that is just white? The sidebar is highlighted in gray which only makes the large blank more obvious.
3. In a similar vein to the blank space - the bar across the top is unbalanced - The user icon is all the way to the right over the blank space, but the arrow on the left is indented like the sidebar, it looks unbalanced.
4. This one is a much more niche issue - and probably one that you will never work on (and don't need to at least for enwiki), but for a user such as myself who has a long sidebar - multiple scripts add links to mine, the TOC is impossible to find for multiple sections - for example on Butetown - I have scrolled down to section 4 (#Welsh language) before the TOC is caught up with me. This may be a concern though for other projects that have added links to their sidebar, such as my private mediawiki site, which has many sidebar links for my convenience.

On the note that I have now spoken about your hard work in a less than stellar light, I again apologize if I came across as harsh, but these are things that I feel need to be addressed before such a big switch for such a prominent website in today's world. Again, I don't want to come across as rude, but I feel we shouldn't rush into this, and that as sdkb called it, the 'meta-process' should include the community's voice on the actual skin itself, and how it could work for enwiki, instead of just how it will be rolled out. (full disclosure: I havent looked at the deployment blockers you linked, because that's a long phab list, and I still don't quite understand all the lines on it, but I will and am open to the possibility that there are other concerns that are more pressing or maybe I'm a complete minority opinion.) Happy Editing--IAmChaos 02:20, 14 July 2022 (UTC)

I find myself agreeing with you here, particularly on aesthetic grounds, where it looks almost amateurish to me. I have not yet had the time to introspect on why I’m receiving that impression (perhaps I’ll update this later though), so take my take with a grain of salt. I definitely think it’s important not to rush this, considering the extreme outsized effect UX design seems to have on people. Yitz (talk) 03:29, 17 July 2022 (UTC)

@Yitzilitt, thanks for mentioning the aesthetic aspect. Look at this page. We simply haven't built that part yet, because we've been focused on changing the features. We'll implement the visual changes in the next couple of weeks. SGrabarczuk (WMF) (talk) 15:48, 18 July 2022 (UTC)

Hey @IAmChaos — thank you for your feedback, and apologies for my delayed response. We appreciate your honesty here.

Regarding your comments about whitespace and the look of Vector 2022: I’m curious if you have been able to take a bit of time to sit with the new skin, and if so, if that has changed any of your opinions so far? The reason why I ask is: several editors who have given feedback and collaborated with us over the past two years have initially disliked Vector 2022 (often for similar reasons), and then after a few weeks of using it they have come to appreciate the changes that have been made, and even ended up liking it more than legacy Vector.

Some design-specific notes regarding the whitespace: the majority of research on readability and reading comfort over the past ten years have concluded that limited line-length, and whitespace surrounding the text, are critical to a good reading experience (more info here). So we started by limiting the line-length, which ultimately leads to limiting the width of the entire interface (otherwise we would end up with even more whitespace). I know it’s a big adjustment, and it feels like there is a lot of “wasted” space. Fortunately there are several community members who have already begun to develop scripts and gadgets to address this, resulting in a more dense version of Vector 2022 (we were joking that it’s kind of like Monobook version of Vector 2022). You can find those gadgets and scripts here. From a process standpoint: the layout has been worked on and reviewed extensively by the entire WMF design team, supported by the majority of community members who have given feedback over the two year development process, and proven via testing to work better for both logged-in and logged-out people in various ways. So while it may not look aesthetically pleasing to you at this time, we wonder if you can go more in depth in terms of what makes it objectively worse. I am of course happy to discuss these topics further with you.

Regarding your comment about the long sidebar pushing the table of contents down the page: fortunately this is a functional issue so it is easier for us to discuss and agree on. In case you have not yet seen it I invite you to first look at our latest prototype here: https://di-collapsible-menus.web.app/Flamingo. You will find that with the tools menu moved to the article toolbar the sidebar becomes much shorter (and please note that the tools menu is able to be pinned to the right side of the article for immediate access upon page load). Secondly, due to the infrequent use of the remaining items in the main menu, we expect that over time most logged-in people will discover their experience is improved by collapsing the main menu (allowing for immediate access to the table of contents upon page load), and then opening the main menu when needed.

Thanks, AHollender (WMF) (talk) 23:27, 28 July 2022 (UTC)

Thanks for the reply @AHollender (WMF). I have looked a bit more, and noticed that I hadn't collapsed teh sidebar which addressed part of my issues mentioned above - particularly the long sidebar hiding the TOC. I will definitely look into the research on readability, I personally find it disconcerting as the software used at my day job is chock full of information too all four corners of my work desktop, all of which I need access to, so maybe it's a bit of Status quo bias in my comfortability with a crowded workspace, but I feel like after looking around there are a few places I don't quite feel fit together right. As for an example where it doesnt match up well: Clicking on Special:Random today brings me to an article in V22. The Categories box is the width of the article, followed immediately by a horizontal line the width of the screen and the footer info is full width across the bottom. I will definitely be looking into the community scripts with density, thanks for the link. Happy Editing--IAmChaos 03:46, 29 July 2022 (UTC)

Hey @IAmChaos — ok right, so this is related to your earlier comment about the width of the header. So how we've currently setup the page layout is:

- there's a max-width for the entire interface, which is currently 1514px. This is the max-width that the site-header, sticky header, and footer all have

- there is a max-width for the content, which is currently 1244px for pages that have a table of contents, or 960px for pages that do not. Again, this max-width is the result of first establishing a comfortable line-length for the article text, then finding a reasonable width for the table of contents. Once we move the tools menu to the other side of the page, if you decide to pin the tools menu this max-width will then be 1514px and everything will be balanced. To explain visually:

Currently this is the situation, with the blank space you're noticing called out in red:

Vector 2022 page layout schematic

However if your screen is less than 1325px wide (which most laptops are), there is no longer a blank space:

Vector 2022 page layout schematic (laptop screen)

Once we move the tools menu to the other side of the page, if you decide to pin the tools menu this max-width will then be 1514px and everything will be balanced:

Vector 2022 page layout schematic (with page tools)

Unfortunately, aside from having the tools menu pinned, there's not really an easy way to make these max-widths match. The easiest thing to explore would be limiting the max-width of the site header to 1244px. However if we did this, and then you decided to pin the page tools, the max-width of the site header would have to change in order to stay aligned.

I hope this is helpful. I can promise you that we are also concerned about possible imbalances in the page layout, are keeping a close eye on this, and are on the lookout for opportunities to achieve better harmony. Your comments are super helpful to us as we continue to explore our options here. AHollender (WMF) (talk) 16:39, 29 July 2022 (UTC)

A request for comment is an open discussion. It's just an open discussion that is geared towards assessing consensus rather than discussing something in the abstract, or as in this topic, having a discussion where you create a plan. So a request for comment, which often runs for 30 days but can go shorter if consensus is clear or longer if discussion remains active, advertised on WP:CENT feels like the right way of having this open discussion with the enwiki community. Best, Barkeep49 (talk) 01:34, 14 July 2022 (UTC)

One extra thought. If there's a sense that consensus might be initially hard but there's a courage of conviction that the skin will genuinely help, some sort of testing, whether through a trial period (owing to enwiki's massive reach lots of data can be collected in shorts period of time), or through A/B testing, with clearly defined metrics could lead to a consensus that wouldn't be there without that data. This is something the Growth Team has done to large success. Best, Barkeep49 (talk) 01:39, 14 July 2022 (UTC)

I like a lot of what Skdb has said below, particularily that it will be an uphill battle for it to gain acceptance. Another factor is that the enwiki users being asked what they think about the change would generally be the heaviest users; casual readers won't see any future RfC's. These users are probably most accustomed to Wikipedia's current look and would most likely be relatively quick to oppose in my opinion. I also think that starting an RfC about 'Should Vector 2022 become the default after it is modified' (so that the RfCs aren't forcing the community to do things and don't have that appearance, also forestalling complete skin opposition in other RfCs) and then following up with one about 'what should those modifications be' could be a good idea. That assumes the community would reject the skin in its current form. —Danre98^{(talk^contribs)} 00:05, 15 July 2022 (UTC)

I would second both thoughts by Barkeep. Specifically, (1) a full 30-day policy RfC, listed on CENT and following the requirements of WP:PROPOSAL, is the gold standard and the only realistic path to legitimacy for such a large change. (2) The change is much more likely to gain consensus with solid supporting data from A/B testing. Best, KevinL (aka L235 · t · c) 00:39, 15 July 2022 (UTC)

FWIW, I am a moderate user (just under 10 edits per day average over the past year, but with over 5,000 pages on my watchlist). After using Monobook for many years, I switched to Vector 2022 a few months ago. It felt a bit wierd at first, but I am now quite comfortable with it. Of course, you are much more likely to hear from users that don't like it than from the rest of the spectrum of user reactions. - Donald Albury 15:56, 15 July 2022 (UTC)

Agreed. Doug Weller talk 17:24, 15 July 2022 (UTC)

Re BilledMammal, Barkeep49, IAmChaos, Sdkb comments on this page about consensus...YES. Changing the editing experience by default for Vector 2010 users without an Opt in....not my favorite and would probably guarantee a strong blowback. Changing the editing experience around here is always fraught with challenges and difficulties (Yeah, VisualEditor...), the chief among them, for me at least, is that I am an editor. I am not someone who approached Wikipedia editing from a developer/programmer/coding/data point of view, I'm just an editing/researching/writing fool and I think there are many of my kind amongst named Wikipedia accounts. I just stumbled upon this discussion by accident and probably wouldn't have known that a change was coming/had been instituted until it happened...
And a plea for the future... If the Vector 2022 skin comes online can we please have clear/easy-to-understand Opt-Out instructions? Maybe have them come up for six months afterwards for Vector 2010? Maybe have an Easy-to-find/Clearly-labeled FAQ for the changes and for Opting-Out? When the "Section edit/Reply to individual posts" change came online recently (I'm sorry but I can't quite remember what the name actually is/was) it was Not Easy to find how to disable/Opt-out from the change. Heh, at least it was not easy for me and I have over 35K posts... That's about all, I'll try to keep up and follow this discussion so it won't be another Big Surprise to me. Shearonink (talk) 17:01, 15 July 2022 (UTC)

Hey @Shearonink, first of all, I understand you. I became a Wikipedian years before I was hired by the Foundation. I personally, as well as other staffers at the Foundation, know that there are thousands of people not editing every day, not engaging in the Village Pump discussions, and finding it difficult to adjust to technical changes impacting the editing experience. So the link to opt-out is and will be available in the Vector 2022 version of the sidebar (left menu). As we wrote, we are also thinking about putting up banners before the launch. SGrabarczuk (WMF) (talk) 17:46, 15 July 2022 (UTC)

It is unfortunate that the en.wiki editor community has been determined through all obstacle to keep this embarrassment of a UI stuck in the year 2001. Despite many excellent proposals for reform of the Main Page, it remains a dull and outmoded layout; the left sidebar is cluttered and unusable by all who have not become accustomed through years of use to its contradictions. Here we have a vector that is far more modern, far more intuitive and far more pleasant for readers—the only problem is that editors who have been here for many years can't possibly approve of it because they've optimised their workflow within the current janky hackjob we have, and the slightest change threatens that.

There are suggestions for changes to the skin that would be useful, but the website's design should not be motivated by the navel-gazing within the editor community. It is apparent in many editor discussions on design that articles are overly focused on how it looks on the editor's desktop view, when most readers will be on mobile. There are discussions for us to have on what the new layout will mean for ToC placement, but we cannot hash out every small detail before first agreeing the adoption of the new layout. There are complaints here about interaction with gadgets and Javascript: this means that those bits of code need to be changed, not the website layout. Many of these gadgets are operating under UI assumptions that are not some functional specification guarantee.

We should not hold back on improvements due to complaints of a vocal minority, but go forwards with the quantitative testing-approved solutions to the problems identified by readers and editors (see below for the WMF's explanation of each stage of this project). — Bilorv (talk) 20:46, 16 July 2022 (UTC)

discussions on design that articles are overly focused on how it looks on the editor's desktop view, when most readers will be on mobile - It's possible to give different views for mobile and desktop readers; I don't think we should be catering for mobile to the exception of desktop. I also note that even the current mobile view is less than ideal; I switch to desktop view when reading from mobile because even there it is easier to read the article in that format. BilledMammal (talk) 22:40, 16 July 2022 (UTC)

I think you've missed my point, BilledMammal, perhaps because I didn't make it clear enough. The issue is not that desktop layout doesn't matter, or that making a good desktop layout contradicts making a good mobile layout. It's that editors generally consider their own layout only (often a desktop layout and specific browser and specific skin) and give no thought to other layouts. As editors, we should be thinking as much about mobile (or more!) as about desktop. But we don't, and that is one example of how editors are not the best people to consult about UI changes. — Bilorv (talk) 08:03, 17 July 2022 (UTC)

Ah, I see what you are saying now - I fully agree, we do need to consider this on a variety of platforms, and even if it isn't currently suitable for all platforms it may be suitable for some. Below, I have actually asked for some data to be presented separately for desktop and mobile users. BilledMammal (talk) 02:53, 18 July 2022 (UTC) Struck following clarification that this is only proposed for desktop. BilledMammal (talk) 04:43, 23 July 2022 (UTC)

Sdkb comments

I've been following/commenting on New Vector throughout the development process and have a lot to say here, so with apologies in advance for the length, I'm creating a subsection.

@SGrabarczuk (WMF) and @OVasileva (WMF): In some other circumstances, I've encouraged the WMF to plunge forward with seeking consensus for deployment, even though development isn't yet complete. My advice here is the opposite: we're not ready for that conversation yet. Users of any site are inherently biased against redesigns, and with Wikipedia's community consensus model, that gives you an unenviable uphill climb if you wish to succeed where past efforts have failed. Because of this, there will be a certain level of guaranteed opposition, and to overcome it, you'll need the design refined enough to get every winnable editor on your side. New Vector has improved a lot over legacy Vector, but I don't think it's at that point yet.

Some of the changes are fairly simple things. For instance, looking at the ToC to the left right now, it ends a ways before the bottom of the page, resulting in an ugly scrollbar that likely could've been avoided if it just extended the full vertical length of the page. Making refinements like that will help avert a gut "this is ugly" reaction and could making the difference between consensus and no consensus.

Other changes are more fundamental. The reduced screen width is something I'm fairly used to at this point, but it seems to be a sticking point with many others. Given that, I think you need to decide how many of the New Vector changes are segmentable. I.e. if the community says "we're okay with everything in New Vector except the screen width" or "we're okay with everything except the ToC", will you be able to implement that? I know you'd prefer to be able to implement everything, but if it has to be an all-or-nothing decision it'll make your task all the harder, because opposition to any one element could foil the entire proposal. So I'd put some thought into what can be segmented out vs. what has to be bundled.

On the ToC, getting it to display so that it doesn't require scrolling in normal cases, even when the main menu is uncollapsed, is something that I predict will be crucial for getting community buy-in. We've been discussing it on MediaWiki, so let's continue the conversation centralized there.

Lastly, I'll reiterate that I think that the upper right corner is going to be a sticking point. We've previously discussed (with Izno and others) how the decision to commandeer that spot for the language switcher appears to have been made based on user research that began with the baseline assumption that making it more prominent was an inherent good, ignoring the other elements that currently occupy that space and that are also important. In your most recent newsletter, you write that the page tabs/title switch moved the language button into an even more prominent position at the top of the page, once again making this assumption, and once again ignoring that you're pushing the other elements down yet another row. When we've brought up those elements, namely coordinates and good/featured article icons, you've declared them out of scope for your project. I don't understand that — you consider it in scope to push them out but not to care about where they're pushed to? Helping readers understand through the site design which articles have undergone a peer review is absolutely crucial for information literacy, and I really wish you'd convene one of your focus groups to understand whether they have any clue about GA/FA currently (my guess is no) and, if not, what can be done through design to fix that (my suggestion is moving them left next to the article name).

If you manage to address these sorts of things, I think it'd be possible to start a productive conversation on making New Vector a default few months from now. That conversation could incorporate multiple steps as you suggest, and it'd probably best take the form of a CENT-listed and watchlist-advertised RfC. If you start it prematurely, though, I think the combination of reasonable and knee-jerk concerns will result in failure to reach consensus, which would set you back. (And I hope it goes without saying that attempting to push through the changes without community consensus would result in a Framgate-level firestorm.) Cheers, {{u|Sdkb}} ^talk 00:34, 14 July 2022 (UTC)

@Sdkb Thank you for your thoughtful reply and thoughts here, and for being super helpful and giving us feedback throughout the process! Apologies for the long response time - we’ve been monitoring this conversation and replying to quick questions, but wanted to sit with your comment for a little bit to make sure we can address all the points you raised. Here are some of our thoughts and answers - curious what you think as well:

1. Thank you for flagging that you think the conversation feels a bit premature. We're very excited to begin bringing the changes to readers as well as to flag where the issues are early on, but agree that the next step would be to continue at a longer timeline than the three weeks we had originally suggested. We would like to continue the conversation by identifying which blockers we have for deployment, making sure that our understanding of “finalized” matches that of the community here. In future iterations of this conversation, we’ll also make sure to highlight this point so as to avoid confusion.
2. ToC issues. Just adding note here, but also agree we can continue discussing in the other thread - sorry for the repetition! We’re currently working on some improvements to the ToC for narrow screens, tracked in phab:T306660 which we hope to have live next week. In these, we have improved the styling of the ToC so that the scrollbar does not appear unless actively scrolling - I agree it’s pretty unsightly. Does that alleviate your concerns somewhat? In the future, after the deployment, we plan on separating more tools out from the main menu, such as the page specific tools. These changes will also allow all menus to be individually collapsible and can also serve as the first step to a more highly customizable system. They will also shorten the main menu significantly. That said, as these changes are pretty technically significant, we would like to confirm the plans for the new default before beginning this next part of our desktop development.
3. On the reduced width - I agree this is tricky. We do have some capability to offer customization, but this becomes more difficult to maintain and test with every option we add. To us, the best case scenario would be to continue to promote the use of individual gadgets and scripts among editors, but if this is deemed insufficient, we can begin scoping out a potential setting for logged-in users. That said, it’s probably not something we’d be able to offer for every feature - it would depend on the request, how difficult it would be to maintain, and how independent it is of the other changes we’ve introduced.
4. Coordinates and upper-right corner issues. This is a priority for us right now as well. In terms of the prominence of language switching - getting higher priority for languages is an important aspect of the project’s goals which are to focus on growing our readership and communities globally. This includes an enormous audience for whom language switching is crucial, and who tend to use a global language, such as English or French, in addition to their local language, for learning on a daily basis. We want to make sure we’re taking their needs into account as much as those who are native speakers. That said, we need to make sure the other elements like indicators and coordinates work well with the new location. This has been tricky as the location of these has traditionally been in the hands of the community. Our view on this is that the order should be as follows (vertically): language button, tabs, indicators and coordinates. Indicators and coordinates should appear on the same line and preferably, coordinates would be treated as indicators. We'll be adding some more thoughts and hopefully some ideas for next steps on the current conversation in VPT.

Hope this is helpful! We’ll continue getting into the details on the individual threads as well, but can also definitely keep talking here too. Also we hope to post a longer response to everyone that’s been involved in the conversation here later today on the next steps in the process. OVasileva (WMF) (talk) 12:27, 27 July 2022 (UTC)

@OVasileva (WMF), thanks for the reply! On the ToC scrollbar, it's not the scrollbar itself that's ugly so much as the fact that you have to scroll to see the full ToC. The entire point of a ToC is to let you see a summary of a page without having to scroll through it all, so if you can't do that, why have a ToC at all? This is certainly an issue for larger articles or talk pages. One possible solution to explore is having the ToC width double when you hover the cursor over it so that less needs to go onto two lines; does that make sense as a concept? {{u|Sdkb}} ^talk 04:12, 29 July 2022 (UTC)

I think that spacing the TOC entries out less would be a good idea as well. The current TOC is just a bit too "fluffy" in my opinion. CactiStaccingCrane (talk) 04:14, 29 July 2022 (UTC)

Hey @Sdkb - thanks for replying to the reply! You bring up a good point. Hovering on the ToC is something that we had initially explored in our first prototypes which we tested with groups of readers and editors in English, Spanish, and Indonesian (more details on the report page). However, we saw that across all groups, people preferred having the ToC shown in full without having to take an action (such as hover or collapse) to view it. So we decided against it and opted for maximizing the space within the sidebar instead to show as much of the ToC as possible. It's possible that later on, we can explore a more specialized solution for cases where line wrapping is particularly prominent (such as talk pages like you mentioned). For now though, I think the tradeoff of having the ToC available persistently is worth the introduction of scrolling in some cases. Our A/B test data came in recently and we're seeing a 50% increase in clicks to the ToC. We'll be monitoring this over time, but are really happy to see that it's helping people navigate back and forth across the page more. Next we'll be looking at the scrolling data - we hope to see a similar decrease in scrolling that we saw with the sticky header. OVasileva (WMF) (talk) 08:51, 2 August 2022 (UTC)

UX research and usability testing

Note, I am an engineer that uses terminals a lot and I still use the MonoBook skin. But, here's a question. If moving to the new Vector skin is controversial, why not commission and publish an extensive user-centered design case study to prove that the Vector 2022 is actually better. Then the community will have to see reason. (Maybe) Andrevan@ 03:23, 15 July 2022 (UTC)

Hey all,

A number of you have asked us about our research and testing (both Qualitative and Quantitative), so we wanted to write a pretty detailed and long comment to address this. We wanted to confirm that not only the Growth team conducts complex testing :) This is more like the standard for big projects now. Each feature change has gone through the process below (which we also described in the Signpost in April). This is what gives us the confidence that everything we have built so far is, in principle, an improvement. At the same time, we acknowledge that there's room for more adjustments.

1. Problem identification research with both readers and editors - during this phase, in 2019, we studied the way people used the site and identified the largest usability issues as well as issues to exploring the site further, becoming more engaged with reading or editing. We did this by interviewing readers and editors across multiple countries and locations. (See the links: Research and design: Phase 1, Research and design: Phase 2.)
2. Prototype development and testing - this is when we build out the ideas of a feature and begin showing solutions to our audiences. Each feature was tested with readers and editors through interviews and wider rounds of prototype testing. Generally, for testing with editors we used central notice across multiple language Wikipedias, including English Wikipedia, so that we can get the widest audience possible. Each prototype was tested by approximately 200 editors on average. (Example)
3. Refining and building - we then take the feedback from the prototype testing and refine or change the prototype based on what needs were identified in the prototype testing. In some cases, we ask for additional feedback during this process so that we’re sure we’re making the right decisions.
4. A/B testing and other quantitative testing on pilot (early adopter) wikis - we perform a quantitative test for whether the feature works as expected based on the criteria of success we have previously defined. For example, the sticky header was designed to decrease scrolling to the top of the page. We gave the sticky header to 50% of users and compared them to the other 50% for two weeks. After two weeks we compared the results and identified that people who had the sticky header were indeed scrolling less to the top of the page in order to select any of the tools available there. If we get negative results from our test, we change the feature and test again. This is the "beta" phase. During this phase, we also monitor usage across all wikis, including English Wikipedia, where many account holders are already using the new skin.
5. Finally, we deploy Vector 2022 on more wikis and continue monitoring the way people are using it so that we can flag any issues. In this phase, Vector 2022 isn't "beta" anymore. It's more like a B-class article. Different wikis have different thresholds for B-class, and we believe that in the case of English Wikipedia, we'll be there when the visual refinements and other deployment blockers are ready.

We are currently working on an easy way to explore all of the above data and research (and are welcome to suggestions on the best format). For now, the best way to learn more about the testing is:

• From Reading/Web/Desktop Improvements/Features, select the feature you are most interested in
• Within that feature page, refer to the Qualitative or Quantitative testing section to see the results and our conclusions

Just so we can have a short version of this as a part of this conversation, we're posting a quick list of our learnings:

Collapsible sidebar

The collapsible sidebar allows people to collapse the main menu in order to focus on reading - helping to find the information needed without distraction

• Qualitative testing with readers and editors on the usefulness of the sidebar and our navigation. Our conclusion here was that the number of different tools provided on the page by default was found to be overwhelming by readers and actively discouraged them from reading, but also from exploring the functionality within the page, an effect opposite of what the exposure of multiple tools aims to do. More details can be found on our feature page for the collapsible sidebar, as well as within the original report
• Quantitative testing on the usage behavior of the sidebar itself, in both its open and collapsed states (see the results). When using the sidebar, logged-out users are much more likely to collapse it and, once collapsed, to keep it collapsed. In addition, the rate of un-collapsing also indicated that users are aware that, were they to need to navigate to an item in the sidebar, that option was available to them.

Maximum line width

We have introduced a maximum line width to articles. Research has shown that limiting the width of long-form text leads to a more comfortable reading experience, and better retention of the content itself.

• Our studies with readers showed that readability was an issue with the current interface, in particular being able to focus on the content
• Pages that are not in a long-text format (such as diffs, special pages, page history) will be presented at full-width as before
• Logged-in users who wish to read articles at full width are welcomed to set up a script or gadget that will allow for this, such as this one
• For more details on research and motivation, see ourresearch section

Search

The new search widget includes important context that makes it easier for users to find the query they are looking for by adding images and descriptions for each search results

• People had difficulties finding the correct result using our previous search
• Our A/B testing showed that adding the new search can lead to a 30% increase in search sessions initiated on the wikis we tested

Language switching

The new language switching tools are more prominently-placed than before. They allow multilingual readers and editors to find their preferred language more easily.

• Readers did not previously know they could switch languages from the page, even if they read multiple language wikis habitually. They would use external search engines to find the correct article instead.
• In our user testing, new readers were able to find the new location much quicker than the previous location
• Our qualitative testing showed that this was more difficult to find for existing users who were used to the previous location, leading us to iterate on the feature. We have since added a note in the previous location of the language switcher and made the button itself a more prominent color
• In the future, we will continue exploration on languages, considering potentially a direct link to a person’s most frequent languages

(note to @Sdkb: we know you have some questions on language links that are still open - we’ll get back to you on these in a separate message)

User menu

The new user menu provides links to all links related to the user in one place. This reduces confusion between general navigation links and specific user links

• New editors were confused between the links at the top of the page and other navigation. They didn’t know these links pertained to their personal tools
• Our user testing with readers and editors showed that people found it intuitive that all user links are in a single menu and that the menu is easy to find
• In our prototype testing, 27 out of 38 (71%) editors and other logged-in users showed strong positive experiences with the user menu
• Based on community requests and current data, we iterated on the feature and moved the watchlist link out of the user menu for easier access

Sticky header

The sticky header gives access to functionality that is used most frequently that was previously only accessible at the top of the page. The goal is for people to scroll less and thus, save time

• Our A/B test showed an average 15% decrease in scrolls to the top per session for logged-in users within the 15 pilot wikis we tested on

OVasileva (WMF), SGrabarczuk (WMF) (talk) 16:14, 15 July 2022 (UTC)

Thank you for posting this; there is a lot to read through so I have only reviewed two features so far, sticky header and persistent table of contents. For the latter, it appears you have yet to conduct A/B testing but when you do I would be interested in seeing data on the percentage of page views that involve at least one click on the table of contents, and the percentage of page views that involve at least two clicks on the table of contents. In addition, I would be interested in seeing separate data for mobile users and desktop users. Struck following clarification that this is only proposed for desktop. BilledMammal (talk) 04:43, 23 July 2022 (UTC)

For the former, I see you have already conducted A/B testing but there is some additional data that I would like to see:

1. Currently, you show the clicks per session and clicks per page only when skinversion=2; I would be interested in comparing this to the clicks per session and clicks per page for skinversion=1. My hypothesis would be that the sticky_header makes it more convenient for readers to access these links, and thus increases the number of readers using them.
2. The rate of accidental clicks. Assessing this would vary by link, but I have a few ideas and am happy to discuss further if required. My hypothesis would be that the sticky_header increases the number of accidental clicks, and we would need to consider whether this increase offsets the benefits of the sticky_header.
3. Time on page, time on page when limited to pageviews that do not involve following a header link, and time on page when limited to pageviews that involve following a header link. Clicks on pages with stickyHeaderDisabled would need to be split between those that involve a scroll back and those that do not. My hypothesis would be that it does not affect time on page for readers who do not click on a header link, and that it has a small but relatively constant absolute decrease in time on page for readers who follow links on the sticky_header compared to those who scroll back to click on a header link. The former would suggest that this does not negatively affect the reading experience, the latter would suggest that that this has a positive effect on the reading experience for readers who are wanting to navigate to one of those pages.

Alternatively, is there raw data that we can look at from the A/B testing for the sticky header? I suspect it won't answer #2, but it may contain information on #1 and #3.

BilledMammal (talk) 03:33, 17 July 2022 (UTC)

@BilledMammal - thanks for your questions! You bring up some really good points that we considered during the design phase of the experiment. The full data analysis is available here: https://jenniferwang-wmf.github.io/Web_sticky_header/. In terms of your questions:

1. Comparing overall clicks. This is something we can look into and report back. The reason it wasn't a main goal for the A/B test is because we wanted to focus on decreasing scrolling (i.e. making the site easier to navigate by requiring less of the user) rather than setting a goal for increased interactions. As in, we would still consider the feature a success if people used the tools as frequently as they did before but had to scroll significantly less in order to do so. That said, I agree with your hypothesis that we most likely would see a significant increase in clicks as well.

2. Accidental clicks are a bit trickier to measure. Generally, with new features, we get a lot of clicks in the first day or so after deployment (which are generally more based on curiosity than accident). This is why we run our tests for an extended period of time - 2 weeks, to make sure it's sufficient time for people to get used to the new functionality and begin using it as they would naturally

3. We discussed looking at time on page at the beginning of the test but decided to look at scrolling specifically instead. While I personally believe that your hypothesis is correct, we've had some issues in the past with looking at the time on page metric and receiving conflicting data. For example - time on page may actually increase over time with the sticky header available because people would be less frustrated with not being able to access specific tasks and thus more open to spending longer on our sites overall. The same is true of scrolling - people might scroll more overall because the site is easier to use. This is why we specifically looked at scrolling to the top of the page as we thought it was the clearest signal that people are going there specifically to find one of the tools available in the sticky header. OVasileva (WMF) (talk) 09:06, 2 August 2022 (UTC)

@OVasileva (WMF):, thank you for your reply, both here and below.

To summarize my position; I see the tests you have done as testing whether the feature is used, but not anything beyond this. With this, it is only possible to come to the conclusion that this proves that each feature is an improvement if the pre-existing assumption is that the feature is an improvement, and thus the user experience is improved so long as the feature is used; I understand how you can see this differently, but I disagree.

I do agree that time on page isn't a perfect metric, but I believe it is a better metric than what is currently being used, and I also believe that those concerns can be partially addressed. For example, looking at the various options on the header bar the only one that I can see plausibly altering behaviour is the search bar, with readers using it more and doing a shallow dive into multiple articles rather than a deep dive into one; to address this we could separate the data into sessions that use the search bar and sessions that don't.

Regarding accidental clicks, that is a good point regarding the curiosity clicks; most methods to identify accidental clicks that I am aware of would likely see those as false positives. Are you able to identify which sessions belong to same logged-in user, as that might offer a way to exclude most curiosity clicks? BilledMammal (talk) 16:46, 7 August 2022 (UTC)

Has anyone actually used the link given at the very top as "see what it looks like" on a smartphone? For me, instead of getting an encyclopedia article, I get a full screen with the sidebar and no encyclopedic content until I scroll down. Can other people please test this? Because this seems like a quite major bug or worse experience than the current mobile version. Fram (talk) 08:46, 17 July 2022 (UTC)

Same bug here but only if I'm using the mobile view in a browser. If I'm using the desktop view on mobile it works fine (and actually looks quite nice). With this said, it may be a non-issue as I've not read anything about mobile transitioning away from MinervaNeue. Anarchyte (talk) 09:01, 17 July 2022 (UTC)

FWIW, I see the same bug as Fram does, on both a Macbook laptop (not mobile) running Safari 14.1.2, and on an Android phone running Opera 69.3.3606.65458 in desktop mode. I just see a banner at the top, a sidebar on the left, and a big blank space on the rest of the page. I have to scroll way down past the sidebar before I see any content, and the content fills the full window width (that is, the sidebar is not to the left of the content, it's above it). There's also no visible TOC on the left side or anywhere, just a hamburger icon that I have to click on to open a TOC. I do not see this bug on Firefox 102.0.1 on a Windows machine. It seems there is still some browser dependency that makes this skin very unpleasant to use in some environments, and not only mobile ones. CodeTalker (talk) 00:51, 18 July 2022 (UTC)

Confirming I see the same thing as Fram in mobile view on Firefox 101.2.0 on Android 11. Desktop view looks intentional. Folly Mox (talk) 18:01, 18 July 2022 (UTC)

It looks great to me (tablet, mobile & desktop) if the sidebar's collapsed. ― Qwerfjkltalk 21:29, 18 July 2022 (UTC)

This is indeed what you see if you force the mobile website to the desktop website/skin (not something anyone but a few realistically is doing) and you open the menu (for me the menu is collapsed by default on that size). While this desktop skin is more compatible with mobile and will eventually probably be fully suitable for mobile, that has not been the primary target of these changes. I believe there is an invite on its talk page asking people for feedback and ideas on what the menu SHOULD look like on mobile. But don't forget that lots of the content is not mobile compatible (minerva on the mobile site has all kinds of hacks to make content not break out of the mobile constraints) and Vector 2022 doesn't have those hacks. So for the immediate future it is still better to use the mobile website on mobile. —TheDJ (talk • contribs) 08:49, 19 July 2022 (UTC)

Apparently you get the same bad results on a Macbook laptop though, see above... Fram (talk) 09:21, 19 July 2022 (UTC)

I've just tested this on a Macbook in Safari and can't reproduce the issue - the link destination looks exactly as intended. Sam Walton (talk) 10:39, 19 July 2022 (UTC)

And of course, nothing in the opening statement of this section said anything about this not being for mobile and only for desktop, it just said that this would become the default, full stop. Fram (talk) 09:23, 19 July 2022 (UTC)

Just to confirm, this conversation concerns changing the skin on desktop only. This will affect the desktop view on mobile as well, but not the current default mobile view. OVasileva (WMF) (talk) 13:27, 20 July 2022 (UTC)

On desktop (not mobile), using Firefox on a MacBook Pro, if I click on the suggested Galaxy link and narrow my window to about half my screen width, I get a view in which only the left toolbar is visible. The rest of the window is blank. The article itself is off-screen below the toolbar. This is a normal width to narrow the window for when I want to see two apps at once, and much wider than its minimum width (which I sometimes use as a quick test of mobile views). On the other hand, when I view it in full screen width, only maybe 60% of the window width is dedicated to content, with maybe 10% sidebar and 30% unused blank space. This extreme sensitivity to window width, unusability on too-narrow windows, prioritization of sidebar over content, and inability to use much of the real estate on too-wide windows, makes this seem like a non-starter to me, but maybe these are things that are still subject to improved design before the push to roll this out to the world? —David Eppstein (talk) 01:29, 8 August 2022 (UTC)

Easy switching skins

After I switched to the 2022 skin, I noticed a new link "Switch to old look" in the left margin, right below the "donate" link. But in the legacy (current) skin there is no corresponding "Switch to new look" link. Why not? wbm1058 (talk) 05:21, 23 July 2022 (UTC)

@Wbm1058 that is a temporary link designed to help anyone that is all of a sudden lost in the change to get back to being able to get around again. — xaosflux ^Talk 11:40, 23 July 2022 (UTC)

I understand that, but the purpose of the "Switch to new look" link is to give readers a heads up that the change is coming so that they can check it out if they opt to. Then hopefully feedback on the changes is given in a manageable trickle so that things can be fixed before a hard change is made that causes an angry mob reaction. Not everyone is as tuned into this as you are; the only way I've become aware of this is from seeing the change in the French and other foreign-language versions. Not everyone is a power-user like me who reads foreign language wikis using Google Translate.

Will the French 2022 skin and the English 2022 skin be the same width, or is the English 2022 skin wider than the French 2022 skin? – wbm1058 (talk) 15:05, 23 July 2022 (UTC)

@Wbm1058 by default all of the vector-2022 skinned sites will have a similar look and feel. We have a opt-in gadget available if you want vector-2022 but in wide mode (mostly for wide screen desktop monitor users); it is still getting some improvements. — xaosflux ^Talk 16:01, 23 July 2022 (UTC)

It looks like this. — xaosflux ^Talk 16:04, 23 July 2022 (UTC)

Wide vector-2022 on a page with a TOC , there is work pending on a collapsible TOC for vector-2022 overall still. — xaosflux ^Talk 16:06, 23 July 2022 (UTC)

And for users like me, will it be easy to use the version suitable for a large monitor on my PC and the other on my iPad. Doug Weller talk 17:20, 23 July 2022 (UTC)

If it became popular, a toggle such as "dark mode" toggle could possibly be built. — xaosflux ^Talk 17:02, 25 July 2022 (UTC)

Tracked in Phabricator
Task T313747

This is a great question, @Wbm1058. When we made the decision to put this link into the sidebar, the project was on an early stage. Now I think we could revisit this and put an equivalent link into the legacy Vector sidebar. SGrabarczuk (WMF) (talk) 16:48, 25 July 2022 (UTC)

+1 this both for easy toggling as expressed in the Phab task, but more importantly as a pre-release promotion per Wbm1058. This should also be available as a cookie-backed pref for non-account/not-logged-in readers, SGrabarczuk. ⁓ Pelagic ( messages ) 14:25, 9 August 2022 (UTC)

Vector 2022 office hours

Join an online meeting with the team working on the Desktop Improvements! It will take place on 26 July 2022 at 12:00 UTC and 19:00 UTC on Zoom. Click here to join. Meeting ID: 5304280674. Dial by your location.

Read more. See you! SGrabarczuk (WMF) (talk) 16:49, 25 July 2022 (UTC)

Hey all, wanted to ping @Sdkb, @Xaosflux, @Bilorv, @TheDJ, @BilledMammal, @IAmChaos, @Jonesey95 and anyone else who is curious - we're hosting office hours later today - if you're interested and have the time, you're welcome to join to talk through questions, comments, and the plan overall. In terms of the conversation here, we plan on answering open questions (we know there's still a few), summarizing the discussion, and identifying some next steps over the next couple of days. OVasileva (WMF) (talk) 08:07, 26 July 2022 (UTC)

Just want to say it's great that you are offering this and I hope people take you up on it! Andrevan@ 21:34, 30 July 2022 (UTC)

An update after two weeks of discussion

1. What should the process look like?

Hey all,

Thank you for your feedback. We recognize that this is a large and important change to our interfaces that will affect the default experience for millions of people. We appreciate your patience in this discussion on how to proceed in the best way possible for our readers, contributors, and communities.

We will try to summarize the feedback we have gotten so far, and continue with identifying next steps. Based on your feedback, we would like to propose the following process:

1. Agree on what changes need to be made to the interface before the final deployment conversation
2. Continue with a conversation focused on building consensus around deployment
3. Deploy and continue with other improvements and requests that were agreed to be non-crucial for deployment

Does this seem in-line with your expectations? Do you have any concerns?

2. Why are these changes improvements?

Many of you were curios about the changes, and especially expressed interest in getting more details on our data and process. Below, we are outlining a bit about our process, as well as the data we have collected that proves that each feature is an improvement. Ping: @BilledMammal, @IAmChaos, Barkeep49, KevinL, Andrevan.

TLDR: Every one of our changes goes through a rigorous process of research, development, qualitative and quantitative testing with readers and editors, prototype testing with editors (across 30+ language communities), iteration, and post-deployment monitoring. When a change does not meet the success criteria or does not perform better than the existing version of a tool, we either stop developing the change or iterate until performance is improved.

We believe that the changes we have made will be crucial to making the site more welcoming and easier to use to new readers and editors.

When compared to the older version of the Vector skin, Vector 2022 is proven to:

• Save time while reading and editing (measured by decreases in scrolling to the top of the page after the introduction of sticky header and table of contents)
• Increase exploration within a given page (measured by increased clicks to the table of contents)
• Improve readability (measured via collapsible sidebar usage)
• Improve the discovery of new content (measured by an increase in searching)

You will find more details in the section #UX research and usability testing. We have tweaked the existing comment a bit.

Thank you for spending the time to write this out. My concern is that you are focused too much on testing for the change you intended to make and in doing so miss the broader impact. Because of this I feel your analysis only proves that you brought about your intended change, rather than proving that each feature is an improvement.

For example, consider the sticky header. Here, the goal is to (1) improve the user experience, by (2) saving reader time, by (3) reducing the amount of scrolling to the top that they need to do.

However, you only test for (3); you then infer (2) from the positive result for (3), and infer (1) from the positive result for (2). Testing directly for user experience is difficult, but to reduce the risk of errors the goal should be to get as close to that level as possible, and in this case it means testing for (2) rather than (3); if you look at #3 in my previous comment you will see that I am requesting data that should give us an answer to (2).

In addition, you assume there are no negative impacts from the change. This isn't a safe assumption, and with #2 and #3 of my previous comment I request data that will allow us to consider this possibility. BilledMammal (talk) 06:56, 28 July 2022 (UTC)

Hey @BilledMammal - sorry for the delay in response! I replied briefly to your initial comment above. TLDR is that we try to design experiments using more precise metrics because more open-ended metrics (such as time spent on page) could be interpreted in multiple ways. More time on page could be an improvement (people have a better experience and thus spend more time on the site overall). Less time on page could also be seen as an improvement (we're saving people time in scrolling so they get to what they need to do quicker). We can keep discussing there or under this thread - whatever is easier! OVasileva (WMF) (talk) 09:11, 2 August 2022 (UTC)

Thank you; no worries about the delay in response, and apologies for my own delay in response. I've replied above. BilledMammal (talk) 16:46, 7 August 2022 (UTC)

3. Why are we having this conversation while development is still happening?

We are eager to bring the improvements mentioned above to our readers. Currently, many new readers do not feel welcome by the interface as it is, and this is something we hope to solve as soon as possible. We recognize that no feature or skin will ever be perfect, and there will always be room for improvement. As we mentioned above, the skin, in its current form, is already a significant improvement over the current state.

The final state of the skin also depends on the conversation we’re having right now. There are many possible improvements or ideas for changes we can build and focus on. We’d like to discuss which of these are most important to the community as we proceed to implement and put the last touches on this version of the skin.

Finally, as we mentioned in a previous post, once deployed, we plan on continuing to work on the desktop experience. This project opens more possibilities for the future and gives us the opportunity to work with communities to provide new and necessary tools both for readers and editors. This is an ongoing process and it will be done with the feedback and collaboration of the community here and across other projects.

4. What changes will be made before deployment?

Our request for you is to review the list below and let us know if it looks correct in your opinion. What should be added? What should be removed? Do you have any questions on what each of these items will and will not include?

As a part of these conversations, we plan on placing requests into three categories. This categorization is based on our research, previous conversations with communities and prototype testing, as well as the feedback we received from all of you last week. These categories are flexible. We need your feedback to move something from one category to another, as well as to add items to each category.

1. Issues we would like to address prior to the deployment
   1. Table of Contents collapsing and narrow screens behavior (@xaosflux, @sdkb). We are working on this and hope to have it ready within the next few weeks (more details in T306660)
   2. Visual refinements (@IAmChaos, @Terasail). We are working on this and we will finish before deployment, with the first part landing next week (week of August 1). To see more details on what visual refinements we are and how we worked with communities to define these, please see this page
   3. Making a decision on ToC handling and magic words (ping @xaosflux, @izno, @IAmChaos, @Anarchyte). We are doing a more in-depth review of magic words and hope to come to you all with a proposal on what (if anything) we think would be best to change. Our sense is that for some of these use cases, the new ToC has solved the initial issues for them existing. We’re interested in finding out which use cases this is not the case for, and providing a solution for those. To confirm, however, the __NOTOC__ magic word will continue to work, as will the templates creating the ToC based on __NOTOC__ such as {{horizontal toc}}
   4. Coordinates display and other indicator issues. We would like to ensure that coordinates do not overlap with any existing indicators and that the area in the top right corner of the article is well-organized (T281974). Special thanks to Xaosflux, Izno, theDJ, Sdkb, AlexisJazz for participating in the discussion and helping us identify next steps. The conversation around coordinates continues in VPT#Coordinates in Vector 2022
   5. Making it easy to opt-in and opt-out ​​(@Shearonink, @wbm1058) - we have a button in the sidebar, which allows for easy recognition of opting out. Opting in is, however, only available through the preferences page. We’d like to explore the possibility of running banners that explain that the change was made and provide opt-out instructions as well. Similarly, prior to the change, we’d like to run more banners that encourage people to opt in and give us feedback
2. Issues we would like to address after the deployment
   1. ToC/sidebar length and the separation of page tools from wiki-wide tools (@sdkb). This is a significant change that we would like to move forward with once we have everyone using the new default. This will be the best way to study and build out customizations for the various use cases (example: the ability to add admin tools or gadgets like Twinkle to the menu)
3. Issues that will not be addressed at this time (issues that are not part of the Desktop Improvements project, belonging to other teams, etc.)
   1. A preference which allows the fixed width of the page to be turned off.

      A local gadget (currently experimental) or personal userscripts may address this at an individual editor level. — xaosflux ^Talk 10:10, 28 July 2022 (UTC)

5. What should the deployment conversation look like?

Some of you said that an RfC would be the best approach for the conversation around deployment. Does that sound like the right course of action? One thing that we have been thinking about is ways to include the voices of readers into the decision making process. We are planning to run surveys asking readers what they think about the new skin compared to the old one. How can we incorporate their thoughts into the conversation?

OVasileva (WMF), SGrabarczuk (WMF) (talk) 01:53, 28 July 2022 (UTC)

Amazing work! CactiStaccingCrane (talk) 05:31, 28 July 2022 (UTC)

You could run a banner that provides an opt-in button for the new skin only visible for unregistered users, but then I'm not sure how they'd be able to leave feedback anonymously. The RfC could then be run in parallel with this campaign, with the ultimate decision relying on the inputs from both. Anarchyte (talk) 06:03, 28 July 2022 (UTC)

with the ultimate decision relying on the inputs from both How would this work? Who gets to decide how much to weight each if they conflict? I don't foresee the community willingly relinquishing control, so as much as I'm concerned that the community isn't going to follow WP:READER and is going to overprivilege editor needs, I think BilledMammal's suggestion is the only practical way to take reader input into account. {{u|Sdkb}} ^talk 04:27, 29 July 2022 (UTC)

I echo Sdkb's concerns. The skin should only be implemented if there is an affirmative consensus to switch to the new skin, especially since the new skin (as it currently stands) will make breaking changes to Wikipedia editor tools and Wikipedia article layouts. — Ⓜ️hawk10 (talk) 23:41, 29 July 2022 (UTC)

To incorporate their thoughts I would suggest running the surveys prior to the RfC, and allowing editors to assess the results of the survey when making their decision. In the end, this needs to be based on the consensus of the community, as assessed by the community. For this assessment I would suggest one thing; asking for a panel close, such as was done for the 2021 review of RfA. BilledMammal (talk) 07:23, 28 July 2022 (UTC)

I think it's premature to decide in advance that multiple closers are needed. Most discussions can be evaluated adequately by a single closer. The 2021 RfA review was by design open-ended in the number of proposals that could be made, and thus unconstrained in the variety of rationales, which were primarily opinion-based, since often there's no way to collect data without actually trying a change to the process. It remains to be seen if an RfC on a new skin will have these or other characteristics such that more than one closer might be desirable. Ideally, if the development process goes as planned, there won't be an RfC unless there is already widespread support for the changes in question, much like the default deployment of the reply tool feature. isaacl (talk) 07:45, 28 July 2022 (UTC)

My suggestion was mainly to reduce the chance of the close being appealed at AN; I don't want us to have a situation where the discussion is closed with a consensus to implement the change, only to have the AN overturn the close. Normally such a situation would not be problematic but in this case I believe it would be due to the scale, prominence, and technical nature of the change. BilledMammal (talk) 08:04, 28 July 2022 (UTC)

I think I agree with BilledMammal that the best way is to present the results of the surveys at the RfC. Olga, you really don't want to end up in the scenario where the enwiki community reaches a consensus against the change while readers say they like the change – I think the community will feel betrayed if you don't respect its decision. If you don't think you can commit to abiding by the outcome of an RfC, you shouldn't hold an RfC; I would be quite upset but less than if you ran an RfC and then overruled its outcome. Best, KevinL (aka L235 · t · c) 17:55, 2 August 2022 (UTC)

Two pretty glaring issues

Ok, so, first, the collapsable toc. if you say readers find it easy, cool, but to me it seems like we're burying our navigational tools. Which to me seems like a really really bad idea. This feels more like something done for phones to save screen real estate, than what would need to be done on a computer monitor, but whatever. If that's a fail, we'll probably find out soon enough by analyzing number of clicks on toc/side menu links.

That aside, not having the user talk page right next to the user's name is also a really bad idea.

We've already had issues with the mobile interface where it was difficult for new editors to know they were receiving warnings, because they didn't see they had a user talk page.

I realize we have our alerts system, but a direct link to the user talk page seems paramount.

if space is an issue, move the watchlist to the drop down, next to contributions (they both should be at the top of the drop down)..

But "talk" should be right next to the user name, before the notice icons. to make it clear that it's the user's talk page. - jc37 11:51, 28 July 2022 (UTC)

If that's a fail, we'll probably find out soon enough by analyzing number of clicks on toc/side menu links. That is a good point, and A/B testing should include data on this. Hopefully the WMF will be willing to engage with this and the other requests for data I made above. BilledMammal (talk) 00:09, 30 July 2022 (UTC)

Can u explain ur thoughts further? Because talk page is a concept completely unique to us, id think. So why would that be more recognizable to ppl than a notice in the notice menu? More recognizable outside of a user’s menu than within the menu ? Isn’t it just that ppl simply need to learn these things no matter where they are ? —TheDJ (talk • contribs) 08:58, 31 July 2022 (UTC)

It's simply a matter of understandability and use-ability. If you look at the various icons that are intended for the user, both displayed and those in the drop-down, I think it's fair to say that the most important ones would be the user page, the user talk page, and alerts/notices. Contributions/watchlist next, then misc "other stuff", and then preferences and logout at the end/bottom.

Wikipedia is a learning curve, to be sure. But as our user model is based upon consensus, and discussing things is often the way of things here, putting the user talk page readily viewable would seem rather obvious.

My return question might be: Why shouldn't it be there? What is the logic here?

And with that in mind, pinging @User:OVasileva (WMF) and @User:SGrabarczuk (WMF). - jc37 08:00, 1 August 2022 (UTC)

• Comment I'm ok with the "two weeks to discuss it" idea. Best way to gather discussion points is to have an unobtrusive banner ad at the top of every page explaining what is going on. Oaktree b (talk) 23:02, 2 August 2022 (UTC)

Another TOC thing "Beginning"

Vector-2022 inserts a section-0 link on the TOC, and it is labeled "Beginning". Anyone else think this is odd? See this page as an example. When I first saw that in the TOC, I didn't think "this is the beginning of the article", but "this is a section about the early days of this subject". Luckily we can localize this via Mediawiki:vector-toc-beginning. Anyone think we should? Perhaps something like "(Top)" or "(Return to top)".? — xaosflux ^Talk 00:38, 3 August 2022 (UTC)

@Xaosflux, we've absolutely raised this already. In the latest mockups, it's bolded, which helps a bit to distinguish it. Still, I think we'd want to consider localizing it, perhaps to "Introduction," which aligns with what we actually call the section (making the entry ramp for newcomers shallower). {{u|Sdkb}} ^talk 01:36, 3 August 2022 (UTC)

@Sdkb that label is on all pages, not just articles (e.g. https://en.wikipedia.org/wiki/Talk:Ireland?useskin=vector-2022 ) so "Introduction" seems even worse to me. — xaosflux ^Talk 09:18, 3 August 2022 (UTC)

Hmm, we could use different labels for different namespaces. Or go with something like "Top" everywhere. As I mentioned at the other conversation, I think the key will be differentiating it somehow through design rather than finding an unambiguous word (which may be impossible). {{u|Sdkb}} ^talk 17:16, 3 August 2022 (UTC)

Some kind of icon, such as a stylized caret ^ , seems to be the best option to me. Daß Wölf 15:40, 7 August 2022 (UTC)

Use italics (not bold) or put (Beginning) in brackets or (Top) in brackets. Definitely not (Return to top) since we are already at the top when the page loads — GhostInTheMachine ^{talk to me} 16:10, 7 August 2022 (UTC)

I've loaded in (Top) as a try; any feedback? — xaosflux ^Talk 16:13, 7 August 2022 (UTC)

Better. Can Contents [hide] be altered as well? In this case, the opposite of "hide" seems to be "move to sidebar" which is just a bit evil — GhostInTheMachine ^{talk to me} 16:25, 7 August 2022 (UTC)

Daß Wölf's comments

• Changing skins is unworkable for non-logged-in users since ?useskin= switches are reset every time you click on a link. They should be made more permanent, through cookies for instance. You can see this for yourself by logging out and visiting a Wikipedia that uses the new interface, e.g. the French Wikipedia. The option to return to the old skin also isn't shown to unregistered and logged-out users, who are the ones who need it the most (since they're much less likely to know about our query string tricks). IMO it would be best to follow Reddit's practice (see [1][2][3]) and let users switch between skins in an easy an obvious way with something like https://en.new.wikipedia.org and https://en.old.wikipedia.org. Daß Wölf 15:56, 7 August 2022 (UTC)

  I wish this idea would garner some interest. We're one of the most viewed sites on the internet and obviously we'd be alienating many readers, just as we'd be accommodating many. This small step for a $150 million organisation would easily avoid moving an (in absolute numbers) large amount of our readers to Wikipedia mirrors. We're really focused on trying to create the perfect skin, when any single design will always drive away somebody. We have to be more flexible here. Daß Wölf 05:06, 12 August 2022 (UTC)

  @Daß Wölf, what is your claim based on? My understanding of the research around site appearance changes (which is mostly not Wikipedia-specific) is that most frequent users dislike noticeable changes, some complain, and a few weeks later, even the people who complained about it usually can't tell you how the old site differs from the new one.

  I also understand that the last time the English Wikipedia's default skin was changed, it had no significant effect on page view traffic to the desktop site. If you have found any good research showing that changing the site appearance alone (and not, e.g., removing tools people needed – an incompatible gadget delayed my own transition from MonoBook to Vector 2010 by months) drives away an appreciable number of readers, then I'd be very interested in reading it.

  P.S. You might be interested in https://nostalgia.wikipedia.org/wiki/HomePage This is the real "en.old.wikipedia". Whatamidoing (WMF) (talk) 04:44, 13 August 2022 (UTC)

  @Whatamidoing (WMF): If that's true, then why is https://old.reddit.com still so popular (~1/6 of desktop views 3 years since the switch)? [4] Daß Wölf 20:29, 13 August 2022 (UTC)

• Regarding the skin itself, I see nothing has been done to make the skin look better on wide screens. How about letting the user set the page width (ideally in a noJS-accessible way) and/or a picture-in-picture sort of preview in the right !ad-banner space for WP:NAVPOPS? Daß Wölf 15:56, 7 August 2022 (UTC)

  @Daß Wölf while it only applies to logged-in users, we have an experimental gadget to widen the view you could try. — xaosflux ^Talk 16:11, 7 August 2022 (UTC)

  There any several (many?) user scripts to fix the width issue. It really would be better if full width was just a standard Skin preference — GhostInTheMachine ^{talk to me} 16:19, 7 August 2022 (UTC)

  I agree completely, but it would be even better to have this setting somewhere on the page, perhaps more prominently than the way the "Desktop view"/"Mobile view" link is buried right now. User scripts and Special:Preferences are well and good, but they do nothing for the vast majority of Wikipedia's users, who do not edit nor have accounts. Daß Wölf 05:00, 12 August 2022 (UTC)

Update on Vector 2022

What changes will be made before deployment

Hey everyone! Thank you for your continued feedback. Wanted to send out an update on the project and next steps, and get your thoughts:

In our last message, we posted a list of tasks that we had placed in three categories based on our research, previous conversations with communities and prototype testing, as well as incoming feedback. Below is an update for the tasks within each category. For this updated version, we would like to ask the same questions - What should be added? What should be removed? Do you have any questions on what each of these items will and will not include?

1. Issues from this conversation that we would like to address prior to the deployment
   1. Table of Contents collapsing and narrow screens behavior - The ToC is now collapsible at narrow screen sizes as well as for all screen sizes. During the next week we will be making changes to the width and centering of content with collapsed ToC's (T314579). We will also be adding the ability to access a collapsed ToC from the sticky header (T311103).
   2. Visual refinements - We're working on this part now. We have made the first changes based on the feedback we have received. The styles for menus and buttons are now back to their default blue state. We have also made some changes to the styles of the ToC. To see more details on the remainder of visual refinements please see the page on MediaWiki.org.
   3. Making a decision on ToC handling and magic words - We will be updating on the state of magic words early next week.
   4. Revisiting the naming of the ToC “beginning” section - @Sdkb, Xaosflux, and GhostInTheMachine: thank you for your continued participation in this conversation and your ideas here. We're monitoring the conversation and are evaluating the idea of the new “(Top)” link as well as other previous suggestions from the conversation on the project talk page. This work will be tracked in this phabricator ticket. We commit to finalizing the name of this section prior to deployment.
   5. Coordinates display and other indicator issues - We are continuing the conversation around coordinates in WP:VPT#Coordinates in Vector 2022 and will post a specific update soon.
2. Issues we would like to address after the deployment
   1. ToC/sidebar length and the separation of page tools from wiki-wide tools - This is a significant change that we would like to move forward with once we have everyone using the new default. This will be the best way to optimize for studying and building out customizations for the various use cases for the page menu (example: the ability to add admin tools or gadgets like Twinkle to the menu).
3. Issues that are not part of the Desktop Improvements project, issues that belong to other teams, and other requests that will not be prioritized at this time
   1. Introducing a setting in preferences which allows the fixed width of the article to be turned off - as some of you mentioned, there are a number of gadgets and scripts that allow for increasing the width or using the space for other tools for people that have larger screens. We have published a list of these on our repository page. Feel free to add any scripts/gadgets that you have created or use the ones available there.

Why are these changes improvements: Update on ToC A/B test results

We have received the results of our ToC A/B test.

• We see that among the sessions with at least 1 click on ToC, the treatment group (the group that is exposed to the new ToC) has more clicks on ToC than the control group (the group exposed to the old ToC). Our data model predicts 53% more clicks on new ToC with logged-in users and 45.5% more clicks on new ToC with anonymous users.
• We saw that this trend is consistent across all edit count buckets: i.e. we saw that logged-in users clicked on the ToC at roughly the same frequency regardless of how many edits they had previously made.

Update on survey results

@Sdkb, KevinL, and BilledMammal: thank you for your suggestion on the survey results! We will proceed as suggested. We plan on running the surveys for readers on a limited set of pages starting this week and publishing the data here for review immediately afterwards for review and discussion (within 2 weeks) prior to the RfC. @kevinL - we will also include the data within the RfC itself for anyone that might be interested but is not following along just yet. Let us know if this doesn't make sense.

Wikimania session info

We will be hosting an introductory session to the project at Wikimania on Saturday, August 13, at 8:05 UTC in tent 2 (join on Pheedloop; see the details). We welcome anyone to join the session. We also welcome anyone with questions or comments to the Q&A afterwards (join on Zoom, dial by your location).

And that's all for now - thank you all again, as usual, for your continued interest, feedback, and help! OVasileva (WMF), SGrabarczuk (WMF) (talk) 15:32, 9 August 2022 (UTC)

Reinstate link to our sister projects on the sidebar

@OVasileva (WMF) and SGrabarczuk (WMF): Please revisit the decision to hide by default the links to sister projects to non-logged users (phab:T287609).

This decision directly contravene our Strategic Direction ("we will become a platform that serves open knowledge to the world across interfaces and communities"), the Improve User Experience recommendation of Movement Strategy ("tools to connect cross-project and cross-language functionalities to provide an enhanced experience of the knowledge contained in the Wikimedia ecosystem for a particular interest, informational need, or inquiry"), and the long-established convention of cross-wiki co-operation among Wikimedia projects of different languages.

As I've pointed out in the MW talkpage, "no one's clicking this so we should remove it" is not a very good argument, and the data presented to back it up is not very convincing. As Theklan pointed out: you're going against a pretty clear Strategy recommendation; if you think that this doesn't go against it, please show how this is helping it. dwadieff ✉ 04:44, 13 August 2022 (UTC)

Thanks dwadieff for bringing this here. Let's see if we have some luck and the problem is solved. Theklan (talk) 09:53, 13 August 2022 (UTC)

As a general principle, we should ask editors to fix their mistakes. Why don't we?

We have, or have had, systems in place that drop a user talk note where an editor adds a disambiguation link to an article, or leaves unbalanced brackets in an article.

Why don't we have something set up so that for every WP:CHECKWIKI issue for which we scan (e.g., an editor putting a footnote in a header), we have a bot find the editor who made that edit and drop them a note informing them of the relevant rule and asking that they fix it? BD2412 T 15:44, 28 July 2022 (UTC)

In theory, I think this would be a great idea, but requires a bit of thought. We could certainly come up with a list of things that can be checked automatically (in the tradition of lint). We could then drop a (friendly and educational) note on the editor's page, alerting them to the issue and suggesting improvements. The problem is, as anybody who has worked with a linting system knows, the burden of sorting out false or trivial alerts can exceed the value of the system if you're not careful. -- RoySmith (talk) 16:07, 28 July 2022 (UTC)

In principle this is a nice idea, but out of interest what do you mean by "putting a footnote in a header"? Do you mean including references in the lead, as in (from today's OTD) Rædwald of East Anglia notes [1] and [2]? While this is in principle not correct, all lead facts should be mentioned and cited in the body, and would be something to bring up at GA or FA, we definitely shouldn't be discouraging this for each and every article of any quality. It is much better for a fact to be referenced only in the lead than not referenced at all... Cheers  — Amakuru (talk) 16:13, 28 July 2022 (UTC)

I think BD2412 meant something like == Awards<ref>{{cite web ... }}</ref> == in articles. DanCherek (talk) 16:16, 28 July 2022 (UTC)

Yes, per DanCherek, last I checked we have over 5,000 instances of a footnote in a section header, with many of these being in the ==References== header, and therefore not properly associated with specific article text. In every one of those cases, some editor first put that ref tag in the header, and a search of the article history should reveal which one, so they can be messaged and asked to fix the error. BD2412 T 19:01, 28 July 2022 (UTC)

To be clear, by the way, I am not just suggesting that we do this going forward, but that we do this retroactively with respect to currently-existing errors. BD2412 T 19:03, 28 July 2022 (UTC)

I've seen == Awards==<ref>{{cite web ... }}</ref> too, and I am fine if we have that notice, but I don't I know how many of these standard type mistake edits there are. Alanscottwalker (talk) 19:20, 28 July 2022 (UTC)

As a general principle experienced users should fix mistakes that are made by new editors. Why don't we? Phil Bridger (talk) 21:39, 28 July 2022 (UTC)

Oh, I do, sometimes, but I have other things to do, and don't want to spend all of my time fixing other editor's mistakers. And fixing one's own mistakes when they are pointed out is how we hopefully learn not to make the same mistakes again. - Donald Albury 22:51, 28 July 2022 (UTC)

@Phil Bridger: let me ask you this. Do you remember all of your old mistakes? Some of the things we are fixing today were originally done years ago by editors who are still active, and now experienced. If, say, fourteen years ago, you did something erroneous in an article and it was still there, wouldn't you want a bot to drop you a note asking you to revisit it? BD2412 T 05:26, 29 July 2022 (UTC)

I just thought I would trial a problem solving approach to proposal evaluation.

Problem

• Quality - Editors creating work for others

Root Cause

• Process - The editing systems are not mistake proof.
• Training - Help is not context-sensitive, but in complex guidelines. Ignorantia juris non excusat (ignorance of the law is no excuse) approach
• User Experience - Overload of information. Action and Error message are complex and long.
• Policy - WP:5P4 "Wikipedia's editors should treat each other with respect and civility" does not specify that editors should not waste other's time.
• Process Management - There is no overview of errors to fix
• People - Lack of editors to fix minor issues "I do, sometimes, but I have other things to do, and don't want to spend all of my time fixing other editor's mistakes. " @Donald Albury

Proposed solution

• Create an automated system to ask problem creator to fix.

Can we trial it at low cost?

• Yes - identify minor errors and manually send errors, and see responses both from a bot type editor name and from a normal editor name,

Risks

• Against Best practise -Blame_in_organizations
• Editor retention : Creator of error may respond negatively especially if many years old (See comment by @BD2412) justice delayed_is_justice_denied or maybe there needs to be a statute of limitations
• Editor Retention - Major reason for "Golden editors" is perceived negative interactions, especially on talk (there is WMF research somewhere that someone can find)
• Editor retention : Bot Human interactions can be problematic
• New Process Risk- Pushing error notifications to editors.
• User Experience - We are allowing a bot to send errors a few minutes later rather than tell the editor at the time
• Editor retention - Notifications are static. If the error is fixed, before the editor looks, then wasted effort.

Cost

• Labour - Increased effort of "ask to fix" vs "fix yourself" (Wikipedia Editor hours)
• Quality - High Failure rate - Using talk as an example (and figures based on a random sample I just did), only 5 to 10 % get a response within 5 years, or before being archived. FA are 50 &, stubs are zero
• Turnover/Retention - (see @BD2412

Benefit to Readers

• Would they notice if this is not fixed?

What do we need to monitor current state and success rate?

• Data - results from similar request processes. (notifications, messages, talk)
• Data - percentage of minor errors after receiving notification
• Data - percentage of active editors who stop being active within say 12 months of receiving notification, compared with editors who don't receive notification
• Definition of success -what percentage is success
• Policy - no process for evaluating proposal success Wakelamp d[@-@]b (talk) 08:30, 29 July 2022 (UTC)

• @Wakelamp: For the record, the "don't want to spend all of my time fixing other editor's mistakes" comment that you quote was Donald Albury, not me. BD2412 T 16:52, 29 July 2022 (UTC)

Doh! CorrectedWakelamp d[@-@]b (talk) 13:34, 30 July 2022 (UTC)

• I like this evaluation approach. But I am not sure I entirely agree with the problem statement. Or rather, I'm not sure I agree that it is a problem at all. Imperfect edits are how the wiki grows. Someone who makes a flawed edit is not "creating work for others"; they are building the project in the way it was meant to be built. But someone who demands that the contributor fix that flawed edit is, in fact, the one who is creating work for others -- and is also contributing to the dangerous perception that imperfect contributions are unacceptable. That this approach would even seem plausible is, I think, a sign of how unsustainably closed (and commensurately stressed and overburdened) the editor community has become, as the heightened barriers to entry leave a few core users to attempt to bear the entire weight of the project alone. -- Visviva (talk) 03:33, 4 August 2022 (UTC)

  @Visviva I agree that imperfect edits are crucial ( and actually quite collaboratiev if people work well). Thank-you for sayimg you like the approach. if it was done as a one page per problem, the evaluation approach seeems to fit WP. There are gaps though in how it would wok

  I agree that the problem coukd have been stated better, and I aslo unhappy with the phrase "making work for others" The work of things such as

  • Drive by tagging,
  • Reverting a whole change when part of it has merit
  • Causing disproportinate conflict for good faith edits,
  • All the various editor "sins".... Wakelamp d[@-@]b (talk) 09:35, 6 August 2022 (UTC)
    • @Alanscottwalker, @Visviva, @Wakelamp, Here is a list of high-priority checkwiki errors. Presumably, at least some of these, the more egregious, would be the ones tracked. These errors tend to be tricky to automatically fix, and also cause visual errors. ― Qwerfjkltalk 17:12, 6 August 2022 (UTC)

• The answer is very simple: This is a volunteer organization, and you cannot coerce anyone to do anything they don't feel like doing. If you tell a Wikipedia editor to do something, they can just not do it, and then what? If you see a mistake, feel free to fix it yourself, or not, no one can make you. --Jayron32 13:16, 3 August 2022 (UTC)
• I recently opened phab:T315072 – which I think is a technically feasible solution to alert users of issues while they are in the editing window. – SD0001 (talk) 04:55, 13 August 2022 (UTC)

RfC: Should we use the longstanding external links icon or the new one?

Tracked in Phabricator
Task T261391

old icon

new icon

How the new icon appears in Chrome on a 1920x1080 display in Windows 10

Recently, a new icon has been rolled out and implemented for external links. Should we use the longstanding icon or keep the new one? — Ⓜ️hawk10 (talk) 04:26, 29 July 2022 (UTC)

Discussion: Should we use the longstanding external links icon or the new one?

• Use the longstanding icon. The old icon was functioning quite fine, no editors on EnWiki seemed to complain about it, though the Wikimedia foundation decided to make changes to the current Vector skin that has used the longstanding external links icon. The new icon, frankly, is too thin to properly render on my monitor and (per comments on phabricator) it appears to be this way on low-density screens more generally. While some may be ok using the new icon before it is fully finished, I personally am frankly disappointed that the way that this icon renders on low-density screens was not given due consideration before its implementation. The longstanding icon should be used until the glaring issues with how the new icon renders on different screens are resolved. — Ⓜ️hawk10 (talk) 04:26, 29 July 2022 (UTC)
• This is clearly premature. --Izno (talk) 04:37, 29 July 2022 (UTC)

  I disagree. If anything was premature, it was pushing the icon onto EnWiki without (a) local communication that this was going to happen and (b) testing to make sure that the icon would appear well on low-density screens. — Ⓜ️hawk10 (talk) 04:39, 29 July 2022 (UTC)

  I disagree, no one is asking you about the 300 changes per week being deployed and you should be glad, you don't have enough waking hours to read them. Be bold and revert is a much better strategy. —TheDJ (talk • contribs) 14:34, 29 July 2022 (UTC)

  Per TheDJ. In addition, the change itself has already been reverted in the source. See phab:T261391#8112692. Izno (talk) 15:24, 29 July 2022 (UTC)

  Hi @Mhawk10 and all,
  Volker E. here, I'm Design Lead at the Wikimedia Foundation Product Design team and this change implemented by myself is part of a multi-year user-interface standardization approach. In short the icon collection design and agreed upon by the Design team follows generalized guidelines

  
  

  First things first, as @Izno already shared, the proposed icon change has already been reverted by us. The rollout featured two problems that we haven't fully anticipated. This will not go into production as is. For completion, visit also the corresponding Phabricator task.

  Second, we have been working and implementing a unified icon set with various quality characteristics for several years now. Among the characteristics are reduction to the essential form and making the icons as universally recognizable as possible. Keep in mind, that given the small icon size, the lesser the details, the better they are recognized by the users. Other high visibility icons, which have changed during that time were 'search', 'user avatar', 'watchlist', 'edit' (pencil) or the 'language' icon. Also Wikipedia's mobile frontend/Minerva Neue skin features the proposed new icon for over a year already. Users switching from mobile to desktop should find the same icons for the same thing.

  Third, the current (old) icon features long-standing technical issues. It's not sizing up when users increase text zoom (a common accessibility feature in use) in their browser preferences and doesn't hold up to other quality characteristics above, like the most simple form.
  

  Therefore we're aiming at amending the icon patch once more and at reintroducing it with better targeting all the special cases undiscovered before. Also with more testing time upfront. It should then work well for lo-dpi and hi-dpi (“retina display”) environments and without technical issues that were caused by having it featured in a bigger font-size in running text and smaller one in References.

  – Regards, Volker E. (WMF) (talk) 13:40, 1 August 2022 (UTC)

• WP:BIKESHED If you prefer the 'old one' once the 'new one' is rolled out, you can always customize it in your on skin. Headbomb {t · c · p · b} 04:44, 29 July 2022 (UTC)

  This isn't about just me, and I'm aware of how to do customizations. The issue is that affects readers who have low-density screens by making the rendering sloppy. — Ⓜ️hawk10 (talk) 05:19, 29 July 2022 (UTC)

  Bikeshedding is when you get caught up discussing the color of the bikeshed instead of the construction of the nuclear power plant. The point isn't that one should never care about the color of a bikeshed. After all, there may be all sorts of aesthetic, logistical, and environmental concerns absolutely worth raising about a bikeshed's color. It just shouldn't become the focus over more important things. So if Mhawk had started this RfC in the middle of a discussion about the external links guideline, then yeah, that'd be bikeshedding. But it's perfectly fine to start a discussion with the specific scope of deciding what the icon should be, just like it's fine for the nuclear power plant to put together a committee with the dedicated purpose of picking a color for the bikeshed. -- Tamzin^{[cetacean needed]} (she|they|xe) 06:41, 29 July 2022 (UTC)

• Use the longstanding icon, per MOS:RESOL and Mhawk's comments. BilledMammal (talk) 05:56, 29 July 2022 (UTC)
• Use the longstanding icon per the visibility concerns Mhawk raises. A new icon that doesn't render right is about as useful as installing chandeliers in a condemned house. —Jéské Couriano v^_^v ^{a little blue Bori} 06:27, 29 July 2022 (UTC)
• Looks like the change was undone last night – I assume we will see the old icon again on Thursday — GhostInTheMachine ^{talk to me} 09:07, 29 July 2022 (UTC)
• Comment: I like the new icon but to me on my mobile screen using desktop site, it appears as four disconnected straight lines which is rather awkward to see. The old one at least worked fine. —CX Zoom[he/him] ^{(let's talk • {C•X})} 09:44, 29 July 2022 (UTC)

  I'm on regular desktop and I see the same: four disconnected lines as the box. Also at high zoom it becomes clear the the diagonal arrow looks terrible and it's got obvious issues. So the "new image" shown for this RfC doesn't match the actual image being used for the external links. Jason Quinn (talk) 16:27, 29 July 2022 (UTC)

• Given that the change has been reverted for now this RfC should be closed. Sam Walton (talk) 11:19, 29 July 2022 (UTC)
• The old icon looks like ass. I mean, I kind of grew attached to it over the years, but let's be honest, it was very much a product of its time. It doesn't make sense. Look at it for a minute. There is this big, open arrow, and a random diagonal line in the middle of the icon, that's a completely different color. Maybe there are some problems with the new one (it looks fine on my desktop computer but it seems like some people were having issues) -- but come on, there's a lot of room for improvement. jp×g 11:53, 29 July 2022 (UTC)
• What do you mean "has been rolled out and implemented"? I still see the "old icon" on EL's. — xaosflux ^Talk 13:31, 29 July 2022 (UTC)
  • I’m still seeing the new icon on desktop while logged out and logged in. What skin are you using? — Ⓜ️hawk10 (talk) 14:10, 29 July 2022 (UTC)

    Looks like this is skin-specific; only seeing the 'new' one in (minerva, vector, vector-2022). FWIW, I don't really care one way or the other there. — xaosflux ^Talk 14:37, 29 July 2022 (UTC)

• WP:BIKESHED, no one should care, start writing articles or become a designer ffs —TheDJ (talk • contribs) 14:02, 29 July 2022 (UTC)
  • Seconded! Another waste of time survey to distract people from meaningful discussions and content creation. Aza24 (talk) 20:51, 29 July 2022 (UTC)

  It is good that people care about the site's design and point out problems with updates. Your dismissive attitude is not helpful. —Kusma (talk) 12:13, 30 July 2022 (UTC)

• While I don't like the old icon much and will not shed a tear when it gets replaced by something better, the new icon sort of breaks when I decrease my font size. (Just tested on zhwiki, which has the new xlink icon but the old PDF icon). I am hoping we'll see a third icon that is better than both soon. —Kusma (talk) 16:00, 29 July 2022 (UTC)
• The old icon should be used until resolution issues are fixed. That said, the new one if it renders correctly is much clearer than the old icon. —Danre98^{(talk^contribs)} 16:44, 29 July 2022 (UTC)
• Reconsider when they want to re-add, if we care I'm not quite on the "let the devs do and only revert if needed" side as suggested as pure default, but I don't think this would have been the drastic change that heralded the (formal) dev takeover without prior notice. It's been rightly reverted. Presumably it'll only be re-added when they're fairly confident that it'll serve all the usecases of the current one - i.e. when it's down to being a stylistic choice. As both are perfectly understandable I pray we can skip the pdf slog as I really couldn't care less at that point. Please consider this !vote as a akin to a procedural close !vote, if it matters. Nosebagbear (talk) 21:08, 29 July 2022 (UTC)
• Comment. What articulatable problem does this icon change solve? Not super clear from the phab thread. In my opinion, the icon's reduction in density is a bit jarring. –Novem Linguae (talk) 03:10, 30 July 2022 (UTC)
• Make the new icon thicker, per others. The new icon is inherently better as it is more modern, easier to see, etc. People who are wanting the old icon back can copy a CSS code from somewhere. A rocky implementation should not kill a good idea. CactiStaccingCrane (talk) 13:16, 30 July 2022 (UTC)
• WP:BIKESHED, WP:BRD Andrevan@ 21:32, 30 July 2022 (UTC)
• New logo no issues with the new logo, I think there's some response bias in terms of people actually liking the new logo but not commenting here. This isn't a big deal IMO. Use the new one. Therapyisgood (talk) 01:53, 31 July 2022 (UTC)

  The problem is not that proposal logo is bad. Infact, I like the modern feel of it. The problem is that what has been proposed, isn't the one being seen by many, if not all, of us. User experience should be the driving force behind change, not making changes for the sake of making changes when there's lots of rather urgent technical issues needing resolve. —CX Zoom[he/him] ^{(let's talk • {C•X})} 06:41, 31 July 2022 (UTC)

  This is a terrible, terrible argument. It would be akin to "We should solve all the problems on Earth before exploring space", i.e. we should never explore space because there will always be urgent problems needing to solve. CactiStaccingCrane (talk) 13:27, 13 August 2022 (UTC)

  For what it's worth, I prefer the new icon. ― Qwerfjkltalk 18:02, 31 July 2022 (UTC)

• Oppose any local solution. Just use whatever MediaWiki and Vector developers decide to use. If you want to push a certain option, do it on Phabricator or Meta, not here. Nardog (talk) 02:01, 31 July 2022 (UTC)
• Use the longstanding icon. In Chrome a 1920x1080 monitor in Windows 10, the new icon looks disjoined and lopsided. --Ahecht (TALK
  PAGE) 18:10, 31 July 2022 (UTC)

link text ← At least for me, this example is missing the line on the right side, which is even worse. --Ahecht (TALK
PAGE) 13:35, 1 August 2022 (UTC)

Patch author here. The (second) implementation has featured a technical issue with the icon canvas, hence the lost side lines. We've reverted the patch, but will provide an updated one which aims to work in your case. Please see also my message to the original thread. – Volker E. (WMF) (talk) 15:01, 1 August 2022 (UTC)

• Old one - 2560x1440 resolution and the border lines are incredibly thin, almost looking missrendered. Anarchyte (talk) 08:15, 1 August 2022 (UTC)
• New one I'd never considered we could change it, but now that I know we can, I agree that the old one looks not great. CaptainEek ^{Edits Ho Cap'n!}⚓ 03:28, 2 August 2022 (UTC)
• Old one or neutral if it ain't broke, don't fix it. But I'm not terribly fussed if we change it. New icon is not terrible, to be honest. Oaktree b (talk) 22:57, 2 August 2022 (UTC)
  • @Oaktree b, note the comment above, the current (old) icon features long-standing technical issues. It's not sizing up when users increase text zoom (a common accessibility feature in use) in their browser preferences and doesn't hold up to other quality characteristics above, like the most simple form.  ― Qwerfjkltalk 17:24, 3 August 2022 (UTC)

    OH, I'm ok with the migration to the new icon in that case. Oaktree b (talk) 18:10, 3 August 2022 (UTC)

• I was using a low-DPI screen the other day and the new icon looked like crap. I also saw the four disconnected lines, and the arrow looked quite ugly. If there’s an updated version of the new icon that fixes these problems, I’d love to see it, but until then, keep the status quo. Also, please fix the viewport for desktop view on mobile. —pythoncoder (talk | contribs) 00:13, 3 August 2022 (UTC)
• Longstanding one The new one's lines are too thin and pixelated for Vector legacy (2010) on Brave browser running on a 1920x1080 monitor. The old one's big and outlined arrow, which makes it easily recognize, definitely makes up for the smaller box in my opinion. ~~ lol1VNIO (I made a mistake? talk to me • contribs) 10:08, 5 August 2022 (UTC)
• Longstanding one, or at least make it optional; I personally stand against the simplification of logos, IMO they usually look like crap. Iazyges Consermonor Opus meum 15:10, 5 August 2022 (UTC)
• Make the new icon thicker The old icon is unnecessarily complex and does not scale, and the new icon matches the commonly seen "external link" or "opens in new window" icons found in applications or on other websites. The only issue I see is that the stroke weight needs to be thicker to be visible at small sizes. {{u|Bowler the Carmine}} (he/him | talk) 21:27, 9 August 2022 (UTC)
• I was not going to comment when I first saw this, but reading the comments above, perhaps that would mean I'm in silent agreement with the change, so here I am, butting in to say I don't ;) I use a low DPI setting on my screen and very much prefer the old icon. The new icon still looks blurry and hard on the eyes at 12px, and I don't see how getting rid of colours is an improvement either. Why not simply make the old icon scalable? Daß Wölf 18:58, 12 August 2022 (UTC)

Communication issue

@Volker E. (WMF), AHollender (WMF), and Jon (WMF): Completely separate from the issue of whether or not the new design is an improvement (which I still need to investigate more before forming an opinion), I think we need to take a bit of space here to diagnose what went wrong with communication between the WMF and the community. This is a major design change (far more impactful than the PDF icon change for which there was a CENT-listed RfC) that should have been presented to the community rather than rolled out unilaterally. Why didn't that happen? {{u|Sdkb}} ^talk 14:37, 29 July 2022 (UTC)

Because the PDF change took 3 months ? —TheDJ (talk • contribs) 14:43, 29 July 2022 (UTC)

The WMF had nothing to do with the pdf change; the icon is a local thing used by MediaWiki:Common.css circa row 92. In addition, per TheDJ above, there are several changes each week and I don't think enwiki needs consulted about every single one. Devs being bold and others reverting if necessary (as someone has) works just fine. —Danre98^{(talk^contribs)} 16:48, 29 July 2022 (UTC)

I really have to question it as a "major design change". No, New Vector is obviously such, but the external link tag is not. The pdf change took forever because so many proposed changes were un-understandable. Nosebagbear (talk) 21:10, 29 July 2022 (UTC)

The external links icon is not a "major design change" but it is extremely visible. Many of the key Wikipedians are some of the most thoughtful, helpful, and capable people on the planet. Maybe it's just me but I think common sense suggests to consult them before making any highly visible global change. Jason Quinn (talk) 02:30, 30 July 2022 (UTC)

It makes no economic sense however. —TheDJ (talk • contribs) 08:59, 30 July 2022 (UTC)

And yet, I didn't notice it until I saw this discussion. - Donald Albury 16:19, 30 July 2022 (UTC)

I would agree with Jason here. I also don't like setting the standard that we make our source code easier to change than MediaWiki:Common.css. There should be some sort of community review before highly visible changes go live.
FWIW, I say this as the person who got the PDF icon change rolling (despite not getting my preferred result). @Nosebagbear: From that perspective, I can say the pdf change took forever simply because the community didn't just want an improved icon (which my suggestion in comparison to the lousy gif) but a better icon (the one they ended up going with without the Adobe logo on it -_-). –MJL ‐Talk‐^☖ 18:41, 30 July 2022 (UTC)

"There should be some sort of community review before highly visible changes go live." There is, you can register on gerrit.wikimedia.org and review to your hearts content. You can read all the many dozens of MediaWiki.org pages that summarise some of the changes and you can participate in any Phabricator ticket that has the "design" tag (currently about 1100 open tickets all mostly about 'visible' things). —TheDJ (talk • contribs) 09:06, 2 August 2022 (UTC)

Please review mw:Bug management/Phabricator etiquette before posting comments on Phab tickets (it's not difficult, but it's not a Wikipedia talk page). Also, voting-type behaviors are banned; this is not the place to discuss who supports/opposes something (although links to external discussions are usually welcome). Whatamidoing (WMF) (talk) 20:08, 2 August 2022 (UTC)

@Whatamidoing (WMF): Thank you for clearing that up for folks. –MJL ‐Talk‐^☖ 21:38, 2 August 2022 (UTC)

Not every change needs an RfC, but every change that alters how we view or interact with the website should be presented to the community; if there are reasonable objections, we can then open a broader discussion and if necessary an RfC. BilledMammal (talk) 00:11, 30 July 2022 (UTC)

“If they have to change something, they should change broccoli” … Harrumph! Blueboar (talk) 22:02, 2 August 2022 (UTC)

Blueboar, We love to diss the WMF, but we should also look at how suck we are. We imposed a double standard. CactiStaccingCrane (talk) 13:15, 13 August 2022 (UTC)

Bots fixing double redirects should tag them with rcat

Original proposal: Suppose a double redirect A → B → C is straightened to A → C. If B is retargeted or expanded to an article later, A should be updated accordingly. We already have a mechanism for that, the template {{R avoided double redirect}}. However, the double-redirect-fixing bots currently fail to tag the straightened redirect (A) with the template. I thus propose to make it mandatory for the bots to apply the tag when straightening a double redirect. It has already been discussed at Wikipedia talk:Double redirects § The bots should operate with a delay. See also the modification of the proposal below. Petr Matas 05:40, 1 August 2022 (UTC). Updated: 23:46, 2 August 2022 (UTC)

It's really a bad task for a bot, and {{R avoided double redirect}} is rather pointless tagging in most cases. Many redirects are created as double redirects with the understand that a both will cleanup after them. What's gained by tagging those with {{R avoided double redirect}}? Headbomb {t · c · p · b} 07:32, 1 August 2022 (UTC)

Support. I completely disagree with Headbomb - {{R avoided double redirect}} is for situations where the avoided double redirect could potentially become an article later or where that redirect is retargetted - when the avoided redirect changes the dependent redirect can be automatically updated to best serve readers. For example if "Foo (song)" is created as a redirect to "Foo (album)" that is itself a redirect to "Foo (band)" then tagging the first redirect as a {{R avoided double redirect}} will allow it to be automatically retargetted to "Foo (album)" when someone writes that article; it can also be retargetted automatically if "Foo (album)" is retargetted to the new article "Foo discography" without the author of the article needing to know the redirect exists - this is even more useful when the redirect is from a less obvious title than in this example. I can see lots of advantages of doing this by a bot and no downsides. Thryduulf (talk) 10:45, 1 August 2022 (UTC)

Thryduulf, I see the downsides. Let's say "Death of Foo" is a redirect to "Shooting of Foo" which is then moved to "Assassination of Foo", causing a double redirect at the first one, we would not want the bot to tag "Death of Foo" with {{R avoided double redirect}}, because the avoided double redirect doesn't really have the potential to become a standalone article without duplicating an existing article, and it would just bloat up the category with unwanted pages. —CX Zoom[he/him] ^{(let's talk • {C•X})} 11:43, 1 August 2022 (UTC)

It's never "mandatory" for a human editor to put that template on a page, so it shouldn't be for their bot-aided edit either. Fixing the double redirect alone is still better for readers, so if it comes down to fixing it or skipping it over this new proposed rule - I'm for the former. — xaosflux ^Talk 12:52, 1 August 2022 (UTC)

Here's a concrete example. There is the journal Proceedings of the National Academy of Sciences of the United States of America. Because that is a mouthful, I create PNAS → Proceedings of the National Academy of Sciences of the United States of America, it's most common abbreviation. Now, because this isn't the only way to refer to PNAS, and because I am lazy, I also create

P.N.A.S. → PNAS

PNAS USA → PNAS

Proc Natl Acad Sci → PNAS

Proc. Natl. Acad. Sci. → PNAS

Proc Natl Acad Sci USA → PNAS

Proc. Natl. Acad. Sci. U.S.A. → PNAS

Proceedings of the National Academy of Sciences → PNAS

And a bunch of others

Should those be tagged with {{R avoided double redirect}} once the bot cleans up after me? The answer here is clearly no. These are not distinct topics, these are the same topics. Headbomb {t · c · p · b} 13:30, 1 August 2022 (UTC)

You can afford the laziness, because you know that currently it leaves no trace in the page structure, only in the history. But imagine that one day PNAS becomes a disambiguation page, even though it is not tagged as a redirect with possibilities at present. Then all redirects that pointed to it before straightening should be retargeted back to PNAS. If their intended target is Proceedings of the National Academy of Sciences of the United States of America, it should have been specified right away instead of relying on straightening by bots. In other words, current toleration of a bad practice is not a good argument for insisting on its toleration forever. A good news is that possible adoption of the proposal will have no effect on such redirects straightened in the past. Petr Matas 23:26, 2 August 2022 (UTC)

Let's say they'd have all been pointed to Proceedings of the National Academy of Sciences of the United States of America before PNAS got turned into a dab? What would be different? Exactly nothing, since no redirect is pointing to PNAS. Headbomb {t · c · p · b} 23:30, 2 August 2022 (UTC)

If they have been straightened and tagged, then after turning PNAS into a dab they will appear in Category:Avoided double redirects to be updated. Petr Matas 23:40, 2 August 2022 (UTC)

Which they shouldn't, since they don't need any updating. Headbomb {t · c · p · b} 00:38, 3 August 2022 (UTC)

That is right, it is just a relict of one's laziness. Petr Matas 04:28, 4 August 2022 (UTC)

Oppose per WP:CONTEXTBOT. The original premise here is not correct, a redirect chain A → B → C does not mean that B is the intended target for A or that the process of retargeting A results in an avoided double redirect. B could be a misspelling, an alternate capitalisation, an alternate disambiguation, a synonym etc. {{R avoided double redirect}} is for the situation "If B was an article A should point to it, but since B is a redirect A points to C instead". Any bot applying these tags would need to be making editorial judgements about what the intention of person who created redirect A was, and whether B has the potential to be a separate subject from C, which is not an appropriate task for a bot. 163.1.15.238 (talk) 13:08, 1 August 2022 (UTC)

No comment on original proposal (Headbomb's comments give me pause). However, if I create Article X and Redirect A to it; then if Article X becomes Redirect x, we should see Redirect A should get tagged by a bot automatically as {{R avoided double redirect}} imo. –MJL ‐Talk‐^☖ 21:49, 2 August 2022 (UTC)

Let's say you create "Canadian Hockey in the 1920s". You then create a "1920s in Canadian Hockey" redirect as a likely alternative title, and "Canadian Hockey in the 1920's" and "1920's in Canadian Hockey" redirects as likely typos.

A move request occurs, and the page is moved to "History of Canadian Hockey (1920s)". What's to be gained by tagging

"1920s in Canadian Hockey"

"Canadian Hockey in the 1920's"

"1920's in Canadian Hockey"

as {{R avoided double redirect}}? Headbomb {t · c · p · b} 00:43, 3 August 2022 (UTC)

That's not exactly the scenario I described (though I get why you are mentioning it). If Redirect x is tagged {{R from move}} then I don't think pages targeting it should be tagged {{R avoided double redirect}}. –MJL ‐Talk‐^☖ 13:18, 3 August 2022 (UTC)

Modification of the proposal: The strongest opposition seems to come from the observation that a bot-straightened redirect is not the same as a redirect tagged manually with {{R avoided double redirect}}. Therefore I propose that the bots add a different tag when straightening a double redirect, for example {{Bot-straightened redirect|original target}}. Thus the original target of the redirect is not lost, changes in the original target can be tracked, and the category of manually-tagged redirects will not become cluttered. Petr Matas 23:26, 2 August 2022 (UTC)

I'm against the original proposal, but this one seems reasonable – it would help in tracking what had happened in cases like this (and potentially allow for bot-straightening of double redirects to be automatically undone if the "middle" redirect got edited into an article). --ais523 11:51, 6 August 2022 (UTC)

This makes sense to me. —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:09, 7 August 2022 (UTC)

Moratorium on recent events

I'm not sure whether this should be proposed here or in policy. I wonder whether it would be helpful if we had a policy similar to one of these: Option 1: No article should be written about an event until the event is at least two weeks old, or perhaps better Option 2: Articles about recent events must remain in draft-space, and will not be reviewed, until the event is at least two weeks old. My reasoning is:

(1) We are an encyclopaedia, not a newspaper. We don't gain anything by being bang-up-to-date, but we lose by being biased, inaccurate, and ephemeral. The long-term meaning of an event is almost never clear in the first few weeks.

(2) We cannot get an overview of what sources think until there has been time for enough good sources to do some thinking.

(3) And we waste valuable AfC-effort, and time at AfD, trying to assess whether something is going to be notable, when if we just waited a week or two, we'd know.

My feeling is that people rush into writing articles about events, motivated either by a desire to get there first, or because they are overwhelmed with the importance of the event in the middle of which they've found themselves. Neither is a great starting point for a balanced, future-proof article. If we had to wait a couple of weeks, then by the time we started typing, we'd have better sources, our initial emotions would have settled, and we'd write an article that looks like someone thought about it. Elemimele (talk) 10:20, 6 August 2022 (UTC)

• On principle, I agree that this would be a useful approach that best serves the encyclopedic purpose of this project. Pragmatically, I expect a lot of opposition and doubt that this has a chance of gaining community consensus. Schazjmd (talk) 15:58, 6 August 2022 (UTC)
• We definitely need to tone down the recent events articles, though I'm uncertain about how it should be handled. There do exist times where recent events should be written about as fast as possible. Events like the Pulse Nightclub Shooting and the Capitol insurrection are impactful events that should not be held in draft-space for two weeks. Conversely, this and this are really just violations of WP:NOTNEWS. I think a better option would just be to raise the notability guideline for recent events to, maybe 20 pieces of coverage in reliable sources? We need some indication that a recent event will amount to more than just breaking news. —VersaceSpace 🌃 16:24, 6 August 2022 (UTC)
• We definitely need to be better on how we rush to create articles on breaking events. There are some that should be created as soon as they have happened such as major earthquakes, commercial air crashes, and the like - we can write these articles based on primarily factual coverage and that we know these generally have long-term enduring coverage. But there's articles that should be held off until we either know they are truly significant events, or more importantly we can write impartially and neutrally about the event. --Masem (t) 16:30, 6 August 2022 (UTC)
  • I disagree with VersaceSpace and Masem that Wikipedia must document certain types of events immediately. That's the job of the news media. But short of the absolute moratorium proposed, the list of exceptions that editors would argue for would be so lengthy as to make the proposal useless. And what about immediate updates to existing articles to document new events? The OP's points #1 and #2 apply to those as well, but I doubt if there would be any community support to delay updates to articles to insure enduring significance or established perspective. Schazjmd (talk) 17:03, 6 August 2022 (UTC)
• This would never likely pass since there's no practical way to enforce it. Let's say we ban coverage of recent events? What happens if I write an article about a major Hurricane anyways? Are you going to AFD it? Okay, well that's an entire week of discussion at minimum. If it gets relisted, it might be two weeks. Then suddenly by the end of that the hurricane happened two weeks ago, so all of the points in favor of deletion just became moot. You would need to propose a new CSD criteria (which many admins would probably be reluctant to support given how many issues there would be with actually utilizing it). Misusing draftspace as suggested by the proposal just seems like a more complicated way to get around that (and would likely just lead to a lot of move wars). (edit conflict) –MJL ‐Talk‐^☖ 17:17, 6 August 2022 (UTC)
• No. Far more reasonable to delete after the fact if it turns out to be non-notable, rather than rules to prevent creation. --Golbez (talk) 18:59, 6 August 2022 (UTC)
• Wikipedia is by default a newspaper of record, with so many responsible newspapers having withdrawn behind paywalls, and what's left being so full of sensationalism and advertisements. I look to a reasonable Wikipedia article as the free online alternative. Dhtwiki (talk) 08:03, 7 August 2022 (UTC)

I'm afraid while I have some sympathy, I disagree with this one fundamentally. Yes, there ought to be a free newspaper project, but this isn't it. The two big differences between a newspaper and us are (1) that newspapers check their facts, while we don't. (2) Newspapers are dated, and obviously valid only on the date of issue; our articles don't carry a date, and present themselves as The Truth. These are both quite subtle features that we as editors understand, but our readers do not. I really do think that if we're going to try to emulate a newspaper then we, like a newspaper, should display prominently the date on which an article was last updated, and probably even draw more attention to who did the updating, or at the very least, the source that was last used to update. Because we don't do this, there is a risk that we will launder a two-day-old opinion from a biased newspaper as though it were up-to-date consensus truth, where a reader who is genuinely looking at a two-day-old copy of the Daily Telegraph knows that they're reading out-of-date material with a right-wing bias. Sorry, I'm being a bit ferocious. But practically, I suppose we could start dating recent events; it's all there in the edit history, it's just that readers don't usually know about histories. Maybe draw more attention to the edit history of recent event articles?? I'm just thinking out loud... Elemimele (talk) 22:48, 8 August 2022 (UTC)

Wikipedia checks the newspapers who are doing the checking, and with a late-breaking story of importance any errors are apt to be quickly contested. I don't think bias enters into getting facts straight on, say, whether a celebrity is dead, near death, broke, arrested, whatever, or how many lives an accident has claimed, which are the sorts of things I had in mind. Dhtwiki (talk) 05:25, 9 August 2022 (UTC)

I'd disagree that we check the newspapers. We summarise them. We don't do any fact-checking at all, which means we are, functionally, no more than gossips: We repeat what we hear. I don't have a problem with that; I have a problem with us misrepresenting what we are. We shouldn't take something that the Guardian presents as current-events news and re-present it as an encyclopaedic statement of history; Wikipedia is a different context to the front page of a newspaper, and context is important to the believability of a story. We are lending undue weight. The arrest of a celebrity is an excellent example: a newspaper reports it because it happened, but doesn't say it's an important part of the person's life. When it goes in a Wikipedia article, we make a tacit statement that it's a notable feature of that person's life story. We're adding weight to the significance of the arrest before we know it's significant, and that goes beyond our sources. I totally agree that my proposition was the wrong way to solve the problem, but the problem still exists: we must stop kidding ourselves about the accuracy of our current events, and we need to find some way to indicate to our readers which articles have the mature view of history, and which are written with the raw emotion of something that happened yesterday. Writing in the style of an encyclopaedia doesn't make the content more reliable. I do think that better use of tags and templates is the right way forwards, not my daft 2-week moratorium. Elemimele (talk) 09:19, 9 August 2022 (UTC)

WP:NOT#NEWS WP is not a newspaper, and those using it as one are using WP mistakenly. We can document current events that have a clear path to notability, or where the news are updates to existing articles, but we should not be rushing to create news article just because it is information being widely reported. We are looking for endurance of information, not a temporary burst of coverage. Masem (t) 13:26, 9 August 2022 (UTC)

• No. This is one of the weirdest suggestions ever put forward. Are you seriously suggesting that Wikipedia should have waited two weeks before having an article about the September 11 attacks or the Robb Elementary School shooting? People have come to expect that there will be Wikipedia articles about major events as soon as possible.--♦IanMacM♦ ^{(talk to me)} 08:14, 7 August 2022 (UTC)
• It is an unfortunate reality that someone will create an article about every breaking news event, WP:RECENT notwithstanding. That horse has bolted. Selfstudier (talk) 08:22, 7 August 2022 (UTC)
• This would be a rule that wouldn't bring a net positive to the project. Most of those we do ultimately delete as ephemeral do little damage in the meantime. The negative ones getting the "press" are far outweighed by the huge number of recent articles that we do cover, and cover well. Nosebagbear (talk) 13:19, 7 August 2022 (UTC)
• A more productive approach might be to place a big “ugly looking” tag on articles about recent events - something that could be removed after review and (probable) rewriting/summarization in a few months. This, of course, requires volunteers who are willing to DO that review and summarization. Blueboar (talk) 14:19, 7 August 2022 (UTC

• Another issue with the proposal is that many events don't involve a separate article. For example, I noticed that Anne Heche was the top read article and wondered what was up. It turned out that she'd just had a spectacular accident and so people are naturally rushing to read her article. If we had a moratorium on such breaking news then people might stop coming to Wikipedia for such information and so would look for another source instead. Why would this be good?

Blueboar should note that the Anne Heche article already has a {{current person}} template and templates like this are commonly used to tag breaking news.

Andrew🐉(talk) 07:56, 8 August 2022 (UTC)

Yes, these tags are a very good thing, and perhaps the entire proposal is unnecessary were they used more often. I only see them on pre-existing articles where the subject has just been plunged into current events because something specific happened. It'd be nice to see them used in a cautionary way on brand-new events. Is there a big ugly tag for brand new articles, basically saying '"This article refers to a very recent event, and may not yet reflect the considered view of history", as per Blueboar? Could its use be encouraged, if it exists? Maybe new page patrollers and AfC reviewers could add it when appropriate? Elemimele (talk) 22:48, 8 August 2022 (UTC)

• Nope, I can't see how a hard rule about this would always benefit our readers. A recent example, on July 25th the President of India changed after their election. How would it be better for readers going to that article to see it say that the president is Ram Nath Kovind until today? — xaosflux ^Talk 17:26, 8 August 2022 (UTC)

Okay, would need limitation. I suppose the cases I'm thinking of are traffic accidents, building fires, natural disasters, etc., but the heart of the matter is the reporting of fact. I don't mind instant reporting of facts that are beyond doubt, and which fall into categories whose notability is beyond doubt; I am dubious about trivia and initial rumours and opinions that spread after a scary event. As a counter-example, I'd offer "had covid". We now have a phenomenal number of articles about famous people stating that they had covid, complete with sourcing. Who cares? Much of the world's population has had covid by now. It was hot news at the time, but in retrospect it's about as significant as saying they had chicken pox. It will probably be decades before all this lot has been weeded out. But I've talked myself into a hole, because a 2-week limit wouldn't have stopped the rash of "had covid" additions... I accept this proposition isn't going anywhere, and was the wrong approach; I'm more keen on clear tags. Elemimele (talk) 22:48, 8 August 2022 (UTC)

• Tentative oppose. I can see the proposer's reasoning, insofar as we are an encyclopaedia and not Wikinews. However, I have always thought that one of Wikipedia's strengths is that it must be the world's most up-to-date encyclopaedia, and this policy would make it fall short of this strength. YTKJ (talk) 19:12, 8 August 2022 (UTC)

I see the strength in this argument. My concern is that by trying to be the most up-to-date, we also run the risk of being the least reliable; on very recent events, there is often a big trade-off between stable accuracy, and rapid response. Perhaps again this could be dealt with by a template; something to remind our readers that Wikipedia's reliability on very recent events is lower than on things that have been kicking around for longer. We, as editors, know that WP is not a reliable source. They, as readers, frequently treat it as such. We owe them honesty about our reliability. But yes, I do see your point... Elemimele (talk) 22:48, 8 August 2022 (UTC)

• Just no. Schierbecker (talk) 05:36, 9 August 2022 (UTC)
• So how about better tagging of breaking-news articles so that it's clear they're merely summaries of yesterday's newspapers and not yet a mature historical view? Is there an appropriate template for a new article that is still on shaky foundations? Elemimele (talk) 09:19, 9 August 2022 (UTC)

  Yes, the breaking news template, which is already in use. --Golbez (talk) 13:11, 9 August 2022 (UTC)

  Pinging @Another Believer, who has a lot of experience with this type of article. Whatamidoing (WMF) (talk) 23:54, 10 August 2022 (UTC)

• Strong no/oppose here. We should absolutely be creating new articles appropriately. (Thanks for the ping immediately above.) ---Another Believer _(Talk) 23:58, 10 August 2022 (UTC)

I see the good intentions behind the proposal, but oppose for three reasons: 1) there are too many exceptions to manage for cases where instant updates make sense; 2) this is a problem that typically resolves itself after a few weeks using existing procedures; 3) Applying Template:Current seems an adequate and proportionate warning during those initial few weeks. Barnards.tar.gz (talk) 13:51, 13 August 2022 (UTC)

Rolling out the edit wizard

For the past couple of months, Firefly, SD0001, and I have been advising a Google Summer of Code project by Ankit18gupta to create a new way for beginners to learn how to edit: the "edit wizard", a step-by-step form for making edits. You can try it on a random page at this link (click the "Edit Wizard" tab at the top). I'd like to see it go live on an arbitrary article to test it out and see how useful it is to people - perhaps one of the mid-ranking articles on WP:Popular pages, like maybe Britney Spears. The project is still at the prototype stage, but the bones are there and the instructions will definitely be greatly expanded before anything gets published - I just figured we could start the conversation now. So, let me know what you think. If we have consensus here, I'll pick an article (based on what gets said here) and also get consensus at its talk page, then implement it (which, if we can't figure out anything else, might have to be through MediaWiki:Common.js). Enterprisey (talk!) 13:32, 7 August 2022 (UTC)

Tried it at the link you gave, clicked it, got "give a source for your fact" with a field to enter a URL. Uh, what? Perhaps I just wanted to correct a typo, rewrite a sentence to get it to flow better, or remove an unsourced claim? The first screen I get is completely out of the blue and isnot how an "editing wizard" should start. Seems to be not ready for implementation. It doesn't get better further on, a very limited tool which ends up posting an edit request to the talk page apparently?[5] "Spot where to add the fact", which fact? All I did was give an url, a quote, and a translation: I didn't present any fact. This tool will create lots of confusion, many edit requests, and little actual benefit. Fram (talk) 09:51, 8 August 2022 (UTC)

The directions will be substantially improved. The intended workflow is (1) think of a statement (fact) to add to the article, (2) get a source, (3) get a quote from the source that supports your statement, (4) rephrase the quote in your own words so that it's suitable to be included in the article, (5) pick a location in the article for your new text to go. As for the other types of edits, some will be added to the wizard later; others, like fixing a typo, are trivial to do with the current editor and are thus not in scope. Enterprisey (talk!) 03:02, 9 August 2022 (UTC)

Fram's right – this thing seems to be worse than useless. Any such functionality should be integrated with the Visual Editor which could use some better signposting. For example, I recently thought to try figuring out how to create a redirect with the Visual Editor as this is the sort of thing that causes me difficulty when training newcomers. I've long known how to do this with the wikitext editor but it's not obvious how to do this in the Visual Editor. I did manage to find out where the function was hidden but I still feel uncertain. As we're still digesting that interface, we don't need another completely new one, thanks. Andrew🐉(talk) 10:11, 8 August 2022 (UTC)

As said below by others, the Visual Editor is not the right place for this because the point is to replace the editing interface with something less bewildering. The WMF Growth team is doing some nice work with putting such signposting and feedback in the editor: see T265163. Enterprisey (talk!) 03:04, 9 August 2022 (UTC)

• Support pilot I tried the tool. It works well. It communicates the point that when people edit Wikipedia they should start by preparing to cite sources. I support implementing this tool on a few articles with support of community members watching them, which could mean giving notice at a WikiProject or other public forum. I see the criticism in this discussion and I am not persuaded. The future of Wikipedia will include technological change and either the community will have input into it, or the community will not. This is a solid research and development project which produced a tool and concept worth testing and discussing. The proposed pilot is unlikely to be disruptive. I appreciate that the pilot is designed for community participation. If anyone wants to criticize research and development in general, then I encourage them to make a proposal for funding to meta:Grants:Start and request sponsorship to organize community review. There are tens of US$millions a year being spent on Wikimedia software development which produces wide changes and yet typically receive less attention or review than student projects like this one. This is a summer student project. Of course this should proceed, this pilot is small, has disclosure, and is a model for collaboration in the way the wiki community wants for all development. I appreciate protection and criticism but be aware of the scale of that big money; if this student pilot seems scary then the big picture is not in view. If there is a problem with this project, then say what would make the development process better, then escalate those ethical requirements up the chain to the paid development. Bluerasberry (talk) 14:35, 8 August 2022 (UTC)
  • Ignoring for now the discussion about the actual tool and whether it communicates well or badly, let me start by adressing the remainder of your post: what? "The future of Wikipedia will include technological change and either the community will have input into it, or the community will not." And? What is the relevance? Some new bit of technology is proposed, and the community gives input. How is that a reason to support (or oppose) this thing? "I appreciate that the pilot is designed for community participation." Yes, that's why I tested it, that's my participation. And then I gave my input on it, which supposedly is the benefit of this community-led project. Good. Still no idea why you ramble on about it as if all of this is important for the implementation or somehow negates the criticism. "Of course this should proceed, this pilot is small, has disclosure, and is a model for collaboration in the way the wiki community wants for all development." Yes, by all means, proceed, by looking at the criticism and coming back with an improved tool, not by brushing aside the criticism because this is a student project with collaboration. "If there is a problem with this project, then say what would make the development process better, then escalate those ethical requirements up the chain to the paid development." Now you've completely lost me; the "problem" with this project is the current end product, which isn't ready to be placed on articles. I have no idea what "ethical requirements" I should escalate to what "paid development", I am giving feedback on the current end result which is being proposed, and which needs serious improvements before putting it into alpha testing. I have no problems with the way this project is otherwise handled, no "ethical" qualms, no comments on any of that. Fram (talk) 14:49, 8 August 2022 (UTC)

@Fram: This is a routine pilot with a functional tool and limited scope. I wish that we had a guideline or rubric for making judgements at scale for allowing or denying such proposals. I disagree that this "needs serious improvements before putting it into alpha testing", but I wish that I could point to a published guide for determining this. Do you have any general ideas for how to determine when a tool is ready for alpha testing? I feel like we should have a standard process for making judgements by the 100s every year. I have the feeling that the main reason why this proposal is getting criticism is that it is being documented for community comment, and if this proposal were not disclosed as is more typical, then there would be no objection to the testing. I do not want the outreach and documentation itself to be the cause for the negative response. Bluerasberry (talk) 15:58, 8 August 2022 (UTC)

Except that it isn't a functional tool. What is the purpose of the pilot? To get actionable feedback. Look above, look below, you have plenty of actionable feedback already. I doubt that such pilots are being started "by the 100s every year", it's not as if we get new tabs at the main interface constantly. "the main reason why this proposal is getting criticism " is that the tool is at the moment not good at all, and will only confuse newbies or IPs, not help them. "if this proposal were not disclosed as is more typical, then there would be no objection to the testing." Duh, if no one knew this was being tested, no one would object. That's not the winning argument you believe it is. If people would find out that some editors are testing a poor tool on IPs or newbies without prior disclosure, then those editors could get into serious trouble. In this case on the other hand, there is no reason at all to get anyone into trouble, people should be thanked for trying something: but that doesn't mean that the result should be supported or even be considered ready for limited testing to unwary users. The testing that is being done here and now, by volunteers willing to test it, is a perfect first step. But accepting that those volunteers then tell you that it isn't yet ready for wider testing as proposed is also necessary (just like having to accept that people may even tell you "never" instead of "not yet"). Fram (talk) 16:07, 8 August 2022 (UTC)

• Perhaps it might be helpful to rename this tool to the "Edit request wizard"? Since it seems to be about making edit requests, not direct edits to the article. Writ Keeper ⚇♔ 15:02, 8 August 2022 (UTC)

  While "edit request wizard" is a good description of the current state of the project, I envision an edit request as only one possible outcome for the workflow: perhaps the edit could be actually applied to the article for advanced editors, or the user's mentor could be pinged or other help sought in real-time. Enterprisey (talk!) 03:06, 9 August 2022 (UTC)

• Seems like this still has issues. Running in to dead-end workflows on this. Went to the page, put in a source, it did say "Source probably OK". No idea what the "Select the sentence" is suppose to do, there was no UI feedback on this. Do you try to insert the cursor somewhere? Do you highlight something? No idea there - but it did let me continue. Put in the "quote from your source", then just got a dead end of "The quote does not match..." and no way to continue from there - dead end stop at this point. Compare this to if I would have just used the wiki editor and the insert source, that works just fine. Sample reference used here was: {{cite journal |last1=Trimble |first1=Virginia |last2=Aschwanden |first2=Markus J. |last3=Hansen |first3=Carl J. |title=Astrophysics in 2005 |journal=Publications of the Astronomical Society of the Pacific |date=2006 |volume=118 |issue=845 |pages=947–1047 |doi=10.1086/506157 |url=https://www.jstor.org/stable/10.1086/506157 |issn=0004-6280}} — xaosflux ^Talk 15:09, 8 August 2022 (UTC)
  • Same happens with Google Books (with preview or with snippets both), you put in a straight quote from the book but it doesn't work. "The quote does not match. Please make sure the quote is copied/pasted exactly from the source". Fram (talk) 15:21, 8 August 2022 (UTC)

    The tool is only relevant for web sources, as that is usually what beginners use mostly. It tries to load the URL (in the backend) to verify the quote. As of now, this only works for simpler websites that put the text in the HTML source, not sites like Google Books or JSTOR where the text may be embedded in images or iframes or other fancy elements, or loaded via JavaScript (although the last limitation is probably solvable). – SD0001 (talk) 16:39, 8 August 2022 (UTC)

    Maybe if the quote fails, it should continue anyway. Tell them it doesnt see it, or cant read it - continue anyway? And just note that with the output? — xaosflux ^Talk 16:44, 8 August 2022 (UTC)

    If we allowed continuing anyway, a user could submit arbitrary text as the quote. We're trying to minimize the amount of arbitrary text users can submit. The reasoning behind requiring exact quotes is if the website is OK and the quote comes from the website, the quote is probably fine to post. Regarding Google Books, I'm hoping for a technical solution, but we may have to just not check Google Books quotes (which hopefully people won't take advantage of). Enterprisey (talk!) 03:23, 9 August 2022 (UTC)

• Blocking issue this should be resolvable. The very last page of the dialog with the "Send edit request" button needs to display MediaWiki:wikimedia-copyrightwarning; and extra verbiage that this is a publish action as referenced in that message. Reason being is that this is introducing a new editor that would allow users to publish new works and they need to agree to the TOU and release their work under the appropriate license to do so. — xaosflux ^Talk 15:22, 8 August 2022 (UTC)

  Also, someone more in the know about toolforge - are there are differences in the privacy policy or access to private info there that unsuspecting editors need be aware of before they get connected to it for this tool? — xaosflux ^Talk 16:01, 8 August 2022 (UTC)

  Additional Easy-to-fix blocking issue: prior to publishing this to production users, especially anon users, the script needs to be moved out of userspace - prob best to gadgetize it as well and load via ?withgadget. — xaosflux ^Talk 16:03, 8 August 2022 (UTC)

  Yes, I had noticed that earlier, but was considering waiting on bringing it up until seeing whether this discussion ended with a consensus to proceed. But definitely seconded; this should not be rolled out while the main code is still in userspace. Writ Keeper ⚇♔ 16:06, 8 August 2022 (UTC)

  Roger that. It'll definitely be a gadget before any rollout. Bug filed for the copyright boilerplate. And I'm not sure on the toolforge privacy policy, but at least I don't think this is the first use of toolforge for a similar purpose. Enterprisey (talk!) 03:28, 9 August 2022 (UTC)

  @Enterprisey

  Github is being a pain, please add this to the ticket:

  *::::It could go right down here: *:::: *::::Compare to how reply tool loads it below the input area: *:::: *::::To get around the verbiage mismatch, perhaps the wizard can change the label from "Send Edit Request" to "Publish Edit Request" - that way you don't have to fork the copyright or add more text that "Send equals Publish" ? *::::

  — xaosflux ^Talk 14:35, 9 August 2022 (UTC)

  Yep, we'll use the reply tool's appearance as a guide. Enterprisey (talk!) 15:54, 9 August 2022 (UTC)

• I think the fundamental question will be how are the problems that arose from the article feedback tool going to be avoided? It produced comments with a very low signal-to-noise ratio, thus requiring a high number of editors to sift through effectively, which did not emerge. isaacl (talk) 16:22, 8 August 2022 (UTC)

  I thought a lot about the article feedback tool and its issues while designing this. Here, we're trying to restrict what users can post with this, using code, to the point where what they post isn't too useless. The URL is verified to be on RSP and the quote is verified to be from the URL. The actual text that goes on the article will be more difficult (i.e. impossible to do perfectly) but I'm hoping that making users get over the first two hurdles will help. Enterprisey (talk!) 03:33, 9 August 2022 (UTC)

• Oppose As it now turns out that this is actually an edit request wizard, note that we have one already – see WP:ERW. I'm not sure whether anyone uses it but the focus should be on improving it rather than re-inventing another way of doing exactly the same thing. See also feature creep. Andrew🐉(talk) 18:01, 8 August 2022 (UTC)

  The edit request wizard is really unintuitive and is implemented by giving instructions as part of the wikitext editing window – the worse possible newbie experience. It is not a serious contender with this JavaScript tool. Best, KevinL (aka L235 · t · c) 18:33, 8 August 2022 (UTC)

  This offering does not seem to be a serious contender either as no groundwork has been done. For example, there's a project WP:WPEDITREQ – "We cover anything related to edit requests on the English Language Wikipedia". But they don't seem to have been consulted about this proposal! And I don't suppose the WMF have been consulted either. My view is that something fundamental like this should be part of the MediaWiki interface so that it is fully integrated with logging, permissions and other architectural features. It would then get ongoing support and development rather than being a one-off summer intern project. Andrew🐉(talk) 06:56, 9 August 2022 (UTC)

• I fully support prototyping this and give my thanks to @Enterprisey for his work on this. I agree with Xaosflux about the outstanding blocking issues prior to implementing this. Best, KevinL (aka L235 · t · c) 18:34, 8 August 2022 (UTC)

  I am facing a lot of problems at the "Quote from your source that supports your fact" stage, though, and anticipate that major bugs should be resolved before deploying even as a prototype. Best, KevinL (aka L235 · t · c) 18:37, 8 August 2022 (UTC)

  Yup, that'll have to be worked out. Thank you for the support. Enterprisey (talk!) 03:35, 9 August 2022 (UTC)

• When I tested this a couple weeks ago I also found it very promising but I'm not sure I'd say it's ready to use with actual new editors outside of testing (likely with developer monitoring). Beyond the blockers that have been noted, I think the edits that are produced are going to be hard - needlessly so - to action. That said I agree with L235 that the opportunity to guide editors through how to write a good edit, step by step, and which does some degree of checking (i.e. it's doing some look to see if the source is a reasonable source), is going to be a huge benefit and will be what distinguishes this (potentially) from the Article Feedback Tool. Best, Barkeep49 (talk) 20:22, 8 August 2022 (UTC)

  Yes, the current area of development work is making requests include wikitext and a full cite template like this. We could even write a gadget that could apply the edit in one click from the talk page (with some improvements to the "pick where your text goes" part of the form). And yeah, better instructions are at the top of my to-do list. Enterprisey (talk!) 03:38, 9 August 2022 (UTC)

I have some questions:

1. Is this for protected pages, or any page?
2. Will this use an edit request template, or just add a talk page message?
3. Who is going to patrol this? There are already plenty of request queues that don't get enough attention.

And some comments:

1. As Fram pointed out, there needs to be a way to make copy edits.
2. There needs to be some notes about consensus, npov and likely a huge number of other content pags.
3. The overwhelming majority of edit requests that aren't horribly malformed or vandalism contain blpvio, npov issues, and fringe issues. This is going to basically create another queue for people to clear trash from. The vast majority of constructive edit requests are copyedits, and this tool doesn't handle those.
4. Is the best we can do to attract new editors (who almost never come from those making edit requests) is ask other editors to make edits for them? The best solution to "it's hard for some people to learn to edit" is "just make the nerds do the actual editing?" Does that mean we've given up on visual editor? ScottishFinnishRadish (talk) 21:00, 8 August 2022 (UTC)

@ScottishFinnishRadish for your question 2, this is what the output currently produces: Special:PermaLink/1103158365#Edit_Request_made_by_Xaosflux_15:16,_8_August_2022_(UTC). I'd think these should probably be enqueued in a category somewhere too, likely under Category:Wikipedia edit requests where all the other ER's go. — xaosflux ^Talk 21:21, 8 August 2022 (UTC)

Regarding backlog, there are over 195 open edit requests requests that most users can handle, with a backlog to May 2022 as of now. — xaosflux ^Talk 21:25, 8 August 2022 (UTC)

The vast majority of users never look at those, however, which is how I have more than 10,000 handled requests. ScottishFinnishRadish (talk) 21:38, 8 August 2022 (UTC)

• Support prototyping - consider this backing for up to 3 articles to be selected for alpha testing, along the basis proposed by Enterprisey. The damage it can do is tiny (most of the issues I came across trying it out will just mean requests don't get made), and as a student summer project, it's not like it'll slip into general use without far more community discussion. There are indeed changes that should be made, and I'd have significant things I wanted to discuss before a broader rollout including it occurring at all. But none of that prevents alpha testing. Nosebagbear (talk) 01:58, 9 August 2022 (UTC)

  For more specific feedback, the "quote your source" bit needs to be WAY less pushy, especially with regard to google book snippets. Nosebagbear (talk) 01:59, 9 August 2022 (UTC)

• As you can see above, I oppose rolling this out to unsuspecting editors in its current state, I don't get why you would do this when there is so much to be improved first. But if it gets rolled out, then please don't start at a controversial BLP like Britney Spears, or better yet don't start at BLPs full stop. Fram (talk) 07:38, 9 August 2022 (UTC)
• I think something more like User:NguoiDungKhongDinhDanh/FormattedEditRequest (maybe with VE?) would be nice. ― Qwerfjkltalk 13:21, 9 August 2022 (UTC)
• I just spent some time testing this tool. There are a number of problems with it and I'm afraid that this will confuse newbies more than it helps them. This needs a lot more work before going live, even as a pilot test. Some issues:
  • The form does not accept URLs in the format of "www.example.com". It has to be prefixed with http:// or https://. The error message simply says "This is not a valid URL" and does not explain why. I don't think it will be obvious to less tech-literate users (presumably the intended audience of this tool) what the issue is.
  • If you enter a Twitter, Facebook, etc. URL, the wizard states that it is an unreliable source and refuses to proceed. While these are indeed unreliable in most situations, there are plenty of valid uses per WP:ABOUTSELF. Outright banning these sources contradicts policy and is unnecessary considering that the wizard creates an edit request, so if the source is inappropriate the request will be declined anyway.
  • Paywalled sources cannot be used as the wizard will not be able to verify the quote. This prevents the use of most RS for medical/scientific articles and even many news sources.
  • Formatting issues can cause the wizard to say that the quote doesn't match. For instance I was unable to input the three lines starting with "Another approach utilized by some laboratories to obtain reliable results..." by copy-pasting from [6].
  • The instructions to copy-paste a quote and "rephrase the quote in your own words" seem to encourage close paraphrasing. Articles are properly written by reading and understanding a variety of sources, not cobbling together lightly rephrased quotes from individual sources.
  • As mentioned above the tool does not support fixing typos, copyediting, removing vandalism, etc. In my experience most new editors start out by making these sorts of minor edits rather than adding substantial content.
• I'd encourage those evaluating this proposal to look at their own newbie edits and see if they would have been able to make them using this tool. This was my first edit - it doesn't involve adding prose, so it wouldn't have been supported. This is my first edit that added referenced content. The wizard would have prevented me from adding this as it cites offline sources and Google Books. Rather than making things easier for new users, this tool seems to restrict their ability to edit for no good reason. The idea that newbies and IP editors should only cite non-paywalled webpages (but don't think of adding, e.g., an announcement about a new album sourced to a band's verified Twitter account) is misguided. Spicy (talk) 15:36, 9 August 2022 (UTC)

Add citation style 2 to the visual editor

CS2 is arguably locally popular, but you can't add it easily in VE. According to this page you can do this, so I don't see why not. Aaron Liu (talk) 03:13, 9 August 2022 (UTC)

Indeed. I like CS2 (the {{citation}} template) as it eliminates the silly distinction between web and newspapers for sources such as The Guardian or NYT which are both. And I like list-defined references too. So, I use the generate function in VE to create the citations and then toggle to the wikitext editor to reformat them into my preferred format. This is a hassle and so it would be good if this were to be a supported preference. Andrew🐉(talk) 16:41, 9 August 2022 (UTC)

Cite → Manual → Basic → Insert any template you want. Whatamidoing (WMF) (talk) 00:01, 11 August 2022 (UTC)

Yes, that's a way to remain in the visual editor, but filling out the template is quite the hassle that simply generating, tweaking, and then switching the template to Template:Citation is much easier Aaron Liu (talk) 02:29, 11 August 2022 (UTC)

As you can see from the documentation you linked above, you could add {{citation}} to the list. However, the auto-filling citoid service probably wouldn't use it much (or at all) in practice. It doesn't have a concept of "style" or article-specific conventions. It only has a concept of "source type". All sources of a given type are put into the same template. If most editors want news sites like The Guardian or New York Times to use {{cite news}}, then it will fill out {{cite news}} for those websites in all articles, even if you wanted it to use {{citation}} for those sources in the article you're editing. Whatamidoing (WMF) (talk) 04:59, 13 August 2022 (UTC)

So that means that this proposal can do two things: 1. Add CS2 to the manual tab, which only saves 2 clicks, and is unable to take advantage of citoid. 2. add some switch to the insert button that will allow us to switch to cs2 or add the switch to preferences, which would require some scripts Aaron Liu (talk) 17:37, 13 August 2022 (UTC)

• More like add everything to VE - Visual editor is legitimately Wikipedia's most useful tool, and it should be fully functional. Not being able to use wiki-markup, edit references in VE when they're in a template or give them ref names is ridiculous. Doesn't Wikimedia make hundreds of millions per year? It should not be much of a task to find people to work on that. —VersaceSpace 🌃 02:43, 11 August 2022 (UTC)

  @VersaceSpace, what other kinds of wiki-markup do you want to use in the visual editor? "Rich editing" of templates is surprisingly difficult (think "a large team for a couple of years" difficult, but no worse than that). Ref names were available in 2013, and then removed. I don't remember why it was removed (only that it was there, and then it wasn't), but since it once existed, I assume that it would be manageable. It was proposed in the Community Wishlist in the past, but didn't get enough votes to win.

  What else do you miss? Whatamidoing (WMF) (talk) 04:53, 13 August 2022 (UTC)

  They may be referring to using wiki markup on tables in VE. Aaron Liu (talk) 17:33, 13 August 2022 (UTC)

Request for comments on research study

As part of a research project at the University of Michigan, we have been developing a new system for fixing broken links on the web. Given a broken link to a web page, our system, FABLE (which stands for Finding Aliases for Broken Links Efficiently), attempts to find the new URL at which that same page now exists on the web; please see the web page for the FABLE project (https://webresearch.eecs.umich.edu/fable/) for more details on how our system works.

To gauge the accuracy of the URL replacements identified by FABLE, we are hoping to conduct the following study. We have run FABLE on a subset of links that have been marked as permanently dead (Category:Articles with permanently dead external links). For each such link where FABLE has found the new URL for the permanently dead link, we plan to make a post on the Talk page of the corresponding article seeking feedback on whether the new URL identified by FABLE looks correct. We have developed a bot (User:FABLEBot) to make such posts, and an example of the posts it would make is on my Talk page (User talk:HarshaMadhyastha).

Before we file for approval for our bot, I am posting here to seek your comments and concerns about this study. Thank you! HarshaMadhyastha (talk) 15:02, 9 August 2022 (UTC)

Hi @HarshaMadhyastha. Thank you for thinking of Wikipedia for this project and for consulting the community before proceeding with this idea. I think the general direction of this project is good, but I am quite worried about the number of talk page messages such a bot will generate. Talk page messages are "expensive" in that they stay around as clutter for a long time (forever on many pages) and generally bots do not leave messages on article talk pages. There are a couple other designs that could work better. One is to have an off-wiki website interface on which authenticated users can approve or disapprove particular URL changes. Another is to create a single page on-wiki that lists all, or many, of the proposed link replacements all in one place, similar to Wikipedia:Database reports (e.g. Wikipedia:Database reports/Potential biographies of living people (1)), that users can work through in bulk. Let me know if we can further discuss these ideas. Best, KevinL (aka L235 · t · c) 15:46, 9 August 2022 (UTC)

Oh, I just remembered the example of "bot posting talk page messages" not going well. It was InternetArchiveBot (talk · contribs), which posted "External links modified" sections on talk pages and really irritated community members (example), and if I remember correctly got blocked for it.
Separately, one other thing that you probably shouldn't do is direct people to an off-wiki site just to provide feedback. (Off-wiki hosted sites that use OAuth to actually perform the change, such as [7], and hosted on Toolforge, are probably OK.) They can provide feedback on-wiki, perhaps in a templated or tabled form that's machine-readable. Hope that's OK with your study methodology. I don't think you'll get community support otherwise. Best, KevinL (aka L235 · t · c) 15:49, 9 August 2022 (UTC)

InternetArchiveBot stopped posting on talk pages after this 2018 discussion, with the main motivation being (if I recall correctly) that the error rate was low, and the action performed wasn't significant enough to be worth posting about. Uanfala (talk) 16:48, 9 August 2022 (UTC)

Thank you for the feedback User:L235! I certainly appreciate the concern regarding clutter on Talk pages. For now, our plan was to post on the Talk pages of at most 200 articles, as our goal at the moment is just to gauge the accuracy of our system's output. Do you think the community would support such a limited one-time study? One of our motivations for posting on Talk pages was that users who are watching the Talk page of an article are more likely to have the necessary context for the external links included in the article.

Alternatively, I really like your idea of creating a single page which lists all proposed link replacements. We are working on creating such a page on our project site, but we could instead create it on-wiki, if that would make it more palatable. Do you have any suggestions/thoughts on what such a page should look like? Would it suffice to have a table with columns for "Wiki article", "Dead link in article", and "Potential replacement URL for dead link"? What would be the best way to seek user feedback on which of the rows in the table are correct? HarshaMadhyastha (talk) 16:42, 9 August 2022 (UTC)

Hi @HarshaMadhyastha, one other concern about the talk page messages is that you aren't going to get many responses. If you do 200 pages, I'd be surprised if you got 20 people reviewing the link.

Re the page, two more columns you can add are: (1) the full citation (not just the link), for context, and (2) a column for users to mark whether the correction is good or not. Best, KevinL (aka L235 · t · c) 16:52, 9 August 2022 (UTC)

Hi @User:L235, A quick follow up question: if we were to create a page which shows a table of the URL replacements that we have discovered, any thoughts/recommendations on how we would draw the community's attention to this page? Thank you. HarshaMadhyastha (talk) 13:54, 10 August 2022 (UTC)

Some ideas that are probably better than talk page messages: Use a tool similar to https://oabot.toolforge.org, or just make edits to the article directly and trust page watchers to correct any incorrect matchings. * Pppery * _{it has begun...} 16:01, 9 August 2022 (UTC)

Thank you. We were concerned that having our bot directly edit articles would receive pushback, since some of the URL replacements we find are likely to be incorrect. So far, by our estimation, we get only 5% wrong, but that's still more than 0 :)

What safeguards would you recommend we put in place in order to get approval to directly edit articles? HarshaMadhyastha (talk) 16:46, 9 August 2022 (UTC)

That's really up to the bot approvals group, who will likely approve the bot for a trial of some small number of edits, then evaluate the fixes for themselves and/or see if anyone complains, not me, but remember that even an incorrect repair does not cause much harm since the original dead URL is not very useful. * Pppery * _{it has begun...} 17:11, 9 August 2022 (UTC)

This sounds really useful! I don't see any major problems with talk page posts, and it may even be the preferable option during the pilot run. However, I agree that it may be better to eventually skip it. Maybe the bot can just update the url, add a custom tag (some variant of ), and allow editors to either approve the edit by removing the tag or to reject it by reverting the bot's edit. There should be a way to catch those accepts and rejects automatically, right? A link for editor feedback can also be available within the tag (or its corresponding help page) and in the bot's edit summary. Uanfala (talk) 16:48, 9 August 2022 (UTC)

• support pilot The effect on Wikipedia is 200 talk page messages, which is acceptable. If this proceeds then I expect registration at meta:Research:Projects, publishing a plan to publish research findings in a way that the Wikimedia community can accept, and a commitment to responding to questions and comments after posting the messages. I was one of the people who complained about the similar Internet Archive project, but in that case, there were several hundred thousand talk page messages posted, and that high number was the project. 200 seems reasonable; if someone complains then a lower number could be negotiated but to me this seems fine. If you are able to give more to this project, then commit to more documentation or publishing a peer reviewed paper, as the Wikimedia community appreciates that. Thanks. Bluerasberry (talk) 16:53, 9 August 2022 (UTC)

Thank you all for the comments, suggestions, and feedback. Greatly appreciated! My students and I will discuss how best to proceed and circle back here soon.

We have been working for a couple of years now on improving FABLE's coverage, accuracy, and efficiency. Looking forward to apply our work to help tackle link rot on Wikipedia. HarshaMadhyastha (talk) 20:23, 9 August 2022 (UTC)

A few scenarios

1. If the goal is to simply evaluate the potential, instead of 200 messages, you could simply consolidate the suggested urls on a centralized page for review. This could be in the bot's own userspace and wouldn't need any big community input so long as it stays in userspace. See WP:BOTUSERSPACE for the relevant guidance.
2. If the goal is an actual bot, and the bad match rate is unknown, the OABot model would be a good one, where the bot is making a suggestion and a human approves. This would be a semi-automated tool and wouldn't need a WP:BRFA.
3. If the goal is an actual bot, and the bad match rate is low/acceptable, the bot could make its own edits. But there would still a need for an extensive trial and a WP:BRFA.

In all cases WP:BOTPOL should be reviewed. Headbomb {t · c · p · b} 11:53, 11 August 2022 (UTC)

Thank you for the input.

Currently, we are definitely leaning towards option 1. Our main concern is: how will those who are interested in providing feedback on the URL replacements we find learn about our page's existence? This is why we are thinking that, once we create our page that lists all the URL replacements that we have found so far, we would also post on the Talk pages of 200 of these articles (after getting bot approval, of course). These Talk page messages would point users back to our consolidated page, thereby helping raise awareness of its existence.

Any thoughts/suggestions? HarshaMadhyastha (talk) 18:03, 11 August 2022 (UTC)

@HarshaMadhyastha: once you have results, you can simply post a notice here (or maybe WP:VPM would be better), and at WP:BOTN and that should give you plenty of feedback. If you target specific types of articles like "mostly medical articles", you can also post notice on related Wikiprojects, like WikiProject Medicine. Headbomb {t · c · p · b} 02:13, 12 August 2022 (UTC)

Sounds good. Thank you very much for the pointers!

We are currently simply churning through all articles listed in Category:Articles with permanently dead external links in alphabetical order. HarshaMadhyastha (talk) 02:29, 12 August 2022 (UTC)

20 years club?

In about one month, I will pass the 20 year milestone-that is, it will be 20 years since I began contributing at Wikipedia. Now, with the "pedia" being around since c. 2000, I reckon there are very few Wikipedians who have reached that milestone, so I was wondering, is there any way that we can form a club or a group or a list or whatever, of Wikipedians who have been here 20+years and are still active?-Or, a club-list, etc of Wikipedians who have collaborated for 20 or more years? Thanks and God bless! Antonio Pediaphile Martin (si??) , 10:53, 10 August, 2022 (UTC)

User:AntonioMartin, yes there is at Wikipedia:Twenty Year Society. Welcome to the club! CactiStaccingCrane (talk) 12:44, 10 August 2022 (UTC)

Review of English Wikimedia fundraising emails

The Wikimedia Foundation has posted samples of its upcoming English fundraising emails on Meta, for community review. These are the Jimbo emails that will be used in the upcoming English email campaign, scheduled to run from September 6 to November 20. Each features a photo of Jimmy Wales, followed by texts asking past donors to donate again to "keep Wikipedia online", "ad-free", keep Wikipedia "free" (the absence of a subscription fee is mentioned), "protect Wikipedia", etc.

I've copied the texts below, for reference. I propose that we establish a rough consensus as to the appropriateness or otherwise of these emails and communicate that to the WMF. --Andreas JN466 15:31, 11 August 2022 (UTC)

Email content

Email 1 From: jimmy@wikipedia.org donate@wikimedia.org Subject: You are one of those rare exceptions Date: August 3, 2022 at 7:58 PM To: nisrael@wikimedia.org My name is Jimmy Wales, and I'm the founder of Wikipedia. In the past, you donated to keep Wikipedia online for yourself and millions of people around the world. Each year, fewer than 2% of Wikipedia readers choose to support our work. You have been one of those rare donors, and for this I want to thank you warmly. I'm grateful you agree that we can use the power of the internet for good. We will achieve this not as individuals, but as a collaborative movement of knowledge seekers. Together, we can rebuild trust in the internet, and by extension, in each other. Will you renew your solidarity with a donation? This is awkward to admit, but I have to be honest: 98% of our readers don't give; they simply look the other way when we ask for an annual donation. We choose not to charge a subscription fee, but that doesn't mean we don't need support from our readers. We don't send a fundraising email every month. We respectfully ask for just one donation this year so that Wikipedia may continue to move forward and offer knowledge to the world. If all our past donors gave a small amount today, our fundraiser would be over. Unfortunately, most people will ignore this message. We have no choice but to turn to you: please renew your gift to ensure that Wikipedia remains independent, ad-free, and thriving for years to come. We're a non-profit. That means we aren't selling the articles that millions of people read on Wikipedia each day. We don't profit from the knowledge you seek. In fact, we firmly believe that knowledge should exist outside of the realm of supply and demand. That's hardly a given nowadays; so much of the world's digital knowledge is driven by profit. Wikipedia is different in that it doesn't belong to the highest bidder, the advertisers, or corporations. It belongs to you, the readers, editors, and donors. You're our community, our family. You're the reason we exist. The fate of Wikipedia rests in your hands and we wouldn't have it any other way. It's readers like you who safeguard our non-profit mission. You help us maintain our integrity, quality, and accessibility. Today, please consider giving again, or even increasing your gift, to keep Wikipedia free and independent. Now is the time we ask: can we count on you to renew your solidarity with a small donation? It will keep Wikipedia online, ad-free, and growing for years to come. https://donate.wikimedia.org Thanks, Jimmy Wales Founder of Wikipedia Renew your donation Where will your donation go? 42% of your gift will be used to sustain and improve Wikipedia and our other online free knowledge projects. 31% of your gift will be used to support the volunteers who share their knowledge with you for free every day. 27% of your gift will give the Wikimedia Foundation the resources it needs to fulfill its mission and advance the cause of free knowledge in the world. Email 2 From: jimmy@wikipedia.org donate@wikimedia.org Subject: It's non-negotiable Date: August 3, 2022 at 8:01 PM To: nisrael@wikimedia.org You have been a Wikipedia donor in the past and have donated once. You've unlocked: Bronze Badge / Silver Badge / Gold Badge / Platinum Badge When you gave in the past, you were one of those rare donors who kept Wikipedia thriving for yourself and millions of other readers. Ready to earn your next badge? Please match your last gift today. I took the liberty of emailing you a second time on behalf of the Wikimedia Foundation (the organization responsible for the protection of Wikipedia), because I wasn’t sure you got a chance to read the first email we sent to nisrael@wikimedia.org, the address we have on file for you since your last gift. I hope this badge will act as a reminder of how crucial your commitment to supporting free knowledge has been and still is to us. At every turn, we have been pressured to compromise our values, but I'll be honest: This isn’t negotiable for us. People always ask us, why not just run ads to make revenue? Or capture and sell reader data? Or make everyone pay to read? While these things seem like the norm online nowadays, we'd like to remind you that there is another way--a way that doesn’t jeopardize the neutrality of our content and threaten your personal data. We just ... ask! Not often, but it works. After 21 years of saying no, I can still say we are proud to have left that money on the table. We’re a non-profit. Only 2% of our readers give, but we manage to serve hundreds of millions of people per month. Imagine if everyone gave? We could transform the way knowledge is shared online. I've been happily stunned by the response from our donors, but we haven't reached our fundraising goal and we don't have a lot of time left. We’re not salespeople. We’re librarians, archivists, and information junkies. We rely on our readers to become our donors, and it’s worked for over 20 years. This year, please consider making another donation to protect and sustain Wikipedia. We know people’s circumstances have changed a lot in the last year. Some find themselves with less to spare, but a lucky few happen to have a bit more. If you’re one of the lucky ones, will you give a little extra to keep Wikipedia growing? Renew your donation Give 5 Give 20 Give 35 Give another amount Any gift will unlock your next badge. Thank you, Jimmy Wales Wikipedia Founder DONATE NOW Email 3 From: jimmy@wikipedia.org donate@wikimedia.org Subject: Our final email Date: August 3, 2022 at 8:01 PM To: nisrael@wikimedia.org I know you've heard from me twice already, so I'll get straight to the point. In the past, you were among the extremely rare readers who made a donation to invest in the future of free knowledge. If you've made it far enough to open this email, could you take a minute to help us out? Many of our readers see our emails and think they'll get round to it later, but life happens and of course they forget. Our annual email fundraiser is coming to an end, so if you've been holding off until “later”, this is your moment. I'm asking you respectfully: Please, renew your donation; it matters. Around the time our fundraising campaign starts, I hear from friends, family, and long-lost classmates who see our fundraising messages while they're looking something up on Wikipedia. It's a reminder of how many folks, from all walks of life, rely on Wikipedia. This incredible public support is crucial for our organization and our movement to thrive. It allows us to serve the world, and to do so with independence and integrity. We don't belong to anyone, because we belong to everyone. You donated in the past and we sincerely thank you. If you still see value in Wikipedia, please sustain your support in 2022 and keep Wikipedia thriving. This is our biggest fundraising moment of the year. It's when we launch the online campaign that brings in donors who will propel us throughout 2022 and beyond. I'm one of them. I'm a regular donor. We are the non-profit that supports one of the world's most visited websites. We don't generate revenue by selling off our users' data to the highest bidder. We don't run ads that could jeopardize the integrity and neutrality of our content. Though our size requires us to maintain the server space and programming power of a top site, we are sustained by the support of our donors who give an average of about $16. This year, will you take one minute to keep our work going? 5 / 20 25 / Other Renew your donation Give less this year Thank you, Jimmy Wales Wikipedia Founder

Discussion

These emails are almost identical to the ones that were used in the recent Indian fundraising campaign (see June Signpost report, "Wikipedia's independence" or "Wikimedia's pile of dosh"?). As can be seen, the second email once gain invites people to unlock "badges" (Bronze, Silver, Gold, Platium) by making sure they never miss a year of donating.

Financial development of the Wikimedia Foundation (in US$), 2003–2021
Black: Net assets (excluding the Wikimedia Endowment, which passed $100m in June 2021)
Green: Revenue (excluding third-party donations to Wikimedia Endowment)
Red: Expenses (including WMF payments to Wikimedia Endowment)

People are told very little in these emails about what it is that drives the Wikimedia Foundation's money needs, what additional work is being carried out that has caused the vast increases in budget and salary costs over the past decade, and what the benefit of this added spending is to volunteers and the public. Nor is there any mention of the Strategic Direction.

Instead, everything is focused on communicating a need for money to keep Wikipedia online/ad-free/free/independent, as though the Foundation were really struggling to keep Wikipedia online without ads – as though it were not richer than ever, with about $400 million (including the Endowment) in assets and reserves.

I think we, as a movement, should do better than these emails, and aspire to more transparency. Moreover, right now, the Internet Archive is arguably much more deserving of donations; unlike the WMF, they have a stable budget, low salary costs, no history of vast budget surpluses, and are currently fighting a lawsuit against publishers – all while supplying an absolutely critical and free service to Wikipedia. --Andreas JN466 15:31, 11 August 2022 (UTC)

• Objection to the Wikimedia Foundation speaking for the community without consultation The Wikimedia Foundation and the community of editors are not the same. The foundation is paid staff recently hired now that donations come in at a rate of US$200 million / year. The community are the volunteers and activists who produce content for the platform. When donors give money, it is because they love Wikipedia as a community of volunteers even while they have little awareness about the staff of the Wikimedia Foundation at all. More discussion is useful, but as a starting point, the Wikimedia Foundation should 1) be transparent about how it calculates its budgets and 2) only talk about budgets for the Wikimedia community the consent and approval of the Wikimedia community. For this point especially -

• 31% of your gift will be used to support the volunteers who share their knowledge with you for free every day.

Since 31% of the donations are to support the volunteers, then 31% of the money should be in the control, governance, and oversight of the volunteers. The volunteers do not have good access to the accounting for money, nor is there any public process for including volunteers in the spending decisions for this US$90,000,000 a year. The Wikimedia Foundation makes many budget decisions without the support and consent of the volunteers. There are many possible talking points for how the Wikimedia Foundation has different priorities as compared to the contributor community, but to name one, the volunteer community has much more compassion for underrepresented demographics such as people in lower and middle income countries. If the Wikimedia community made governance decisions about that 31%, then programs to increase diversity would include showing monetary equity in the allocation of global funding. I have anxiety because the values and ethics of the centralized and control-seeking Wikimedia Foundation are diverging from those of the decentralized and power-sharing Wikimedia community. The power belongs to the user community, not to paid staff who operate without community support. Bluerasberry (talk) 16:15, 11 August 2022 (UTC)

• Completely agree with your concern, Jayen466. I don't think emails as they stand arein keeping with our values. (I also complained over at Meta a few months ago, but I unfortunately failed to follow up due to other commitments.) I share your unhappiness with the obsequious, obfuscating tone and I'd like communications to be more transparent about where donors' money will go. I'm not sure the WMF will listen to these concerns, though. However, what I do find strongly objectionable are manipulative or clearly misleading phrases, of which there are several:

Specific objections (manipulative and/or misleading): "Subject: It's non-negotiable"; "Ready to earn your next badge? Please match your last gift today" vs. "Any gift will unlock your next badge"; "we have no choice but to turn to you... to ensure Wikipedia remains ... ad-free ... for years to come" & "[your donation] will keep Wikipedia ... ad-free" (not true); "this is our biggest fundraising moment of the year" (there'll be another fundraising campaign in a different region); "donors who will propel us throughout 2022" (we already comfortably meet our running costs); "X% of your gift will be used" (not it won't, these are expenditure breakdowns and don't account for money put into the endowment etc., it should say "X% of our spending"); "we haven't reached our fundraising goal" (what if we have reached it, will this still be sent?); Jr8825 • Talk 19:04, 13 August 2022 (UTC)

• Bronze Badge / Silver Badge / Gold Badge / Platinum Badge This language sounds like what some multi-level marketer might use to get you to buy their product. The WMF are not salespeople, and should not be using "badges" or any other promotional language to get people to make a donation. I suspect User:Jimbo Wales would not approve of this either. 2601:647:5800:1A1F:AC39:F771:78B1:4C47 (talk) 21:29, 13 August 2022 (UTC)

Proposal: Remove WP:Contents from the sidebar

I don't think that this page serves much of a purpose. People will most likely search for the term rather go to the contents. Interstellarity (talk) 01:38, 12 August 2022 (UTC)

It's hurting no one, and those that stumble upon it have a great way to explore the Encyclopedia. Keep it. Headbomb {t · c · p · b} 02:14, 12 August 2022 (UTC)

Agreed. Lean is the best. If we choose not to delete it, we should integrate the page more at the main page. This seems to the a relic from the Wikipedia's olden days in 2001. CactiStaccingCrane (talk) 12:57, 13 August 2022 (UTC)

Notice: Emergency election-related discussion on Pump(WMF)

See discusion at Wikipedia:Village pump (WMF)#EMERGENCY DISCUSSION: WMF prohibits community from voting for candidates of our choice in Board seats election. Alsee (talk) 09:49, 12 August 2022 (UTC)