Wikipedia:Requests for comment/2020 left sidebar update

This RfC consists of a series of independent proposals to modify the sidebar located on the left side of every page in the desktop default skin view of Wikipedia (encoded at MediaWiki:Sidebar), aimed at improving usability and ease of navigation.

It is being launched and listed on the centralized discussion template (among other places) following a half-month incubation period at the Village Pump Idea Lab.

You may participate by !voting in the polls or contributing to the discussion section under each proposal, or by adding new proposals. Refactoring may be done as needed to keep this RfC organized. – &#123;{u&#124; Sdkb  }&#125;  talk 21:46, 10 April 2020 (UTC)

Background
The content of the left sidebar has changed remarkably little since the mid-2000s, despite the many advances in web usability best practices since then. In fall 2013, (ret.) launched an RfC proposing a major overhaul. The close (by ) noted that All participants seemed to agree that the sidebar's content, design and appearance could be improved but that there was a wide variety of suggested changes none of which appeared to have universal support, so no changes were implemented. Since then, only minor changes have been enacted, such as the removal of the "create a book" link last December.

The 2013 RfC articulated the following principles, most of which are copied here given their continued applicability: Monthly pageviews of the links in the sidebar |Wikipedia:Contents|Portal:Current_events|Help:Contents|Wikipedia:Community_portal|Special:RecentChanges|Wikipedia:About|Wikipedia:Contact_us|Wikipedia:File_Upload_Wizard|Special:SpecialPages typically range in the hundreds of thousands. The ongoing Desktop Improvements Project being undertaken by the WMF may result in future changes to the user interface on all Wikipedias that could affect the sidebar, but it is not focused on the contents of the sidebar, so should not conflict with the proposals here. – &#123;{u&#124; Sdkb  }&#125;  talk 21:46, 10 April 2020 (UTC)

Reorder the links in the left sidebar to create a new "contribute" section
This proposal changes the ordering of the sidebar links in the manner shown at right. Only a section is renamed, and no links are added or removed. The "In other projects" and "languages" sections are ignored in the previews.

The main rationales here are to improve prioritization (by placing important links high up) and categorization (by placing links in more intuitive places, grouped with other similar links). For prioritization, important links like WP:About are moved up. For categorization, the vaguely-named "interaction" section is renamed to the clearer "contribute", and universal editor-focused links are consolidated there, while page-specific editor-focused links are consolidated in the "tools" section. Reader-focused links are consolidated in the top ("navigation") and "print/export" sections.

Survey (Contribute section)

 * Support all changes as proposer. &#123;{u&#124; Sdkb  }&#125;  talk 21:46, 10 April 2020 (UTC)
 * Support no big change here. The 40 percent of our readers that do see this will not have more or less trouble finding links with this order.-- Moxy 🍁 21:53, 10 April 2020 (UTC)
 * Support seems reasonable enough. SemiHypercube 22:32, 10 April 2020 (UTC)
 * Support, except that I think "Special pages" should stay within Tools. —&#8288; 烏&#8288;Γ (kaw) │ 22:50, 10 April 2020 (UTC)
 * Support; I maintain sidebars globally as an interface editor and the drawbacks outlined above are a growing problem for wikis. It is time to improve and simplify our sidebars. ~ riley  ( talk  ) 22:56, 10 April 2020 (UTC)
 * Support – This is a better layout. I also agree, though, that Special Pages should stay within Tools, but this is an improvement either way. Levivich&thinsp;[dubious – discuss] 23:16, 10 April 2020 (UTC)
 * Special pages is the same, no matter which page you go to it from, thus the move from "tools" to "contribute". This is in line with the original intention of the two sections for one to be page-specific and the other not to be. Cheers, &#123;{u&#124; Sdkb  }&#125;  talk 23:31, 10 April 2020 (UTC)
 * Support except that "Special pages" should stay in tools since new editors will not find that page comprehensible (who looks at Special:LintErrors besides gnomes?). — Wug·a·po·des​ 00:04, 11 April 2020 (UTC)
 * Support a great idea.--Tom (LT) (talk) 00:12, 11 April 2020 (UTC)
 * Oppose Any changes (other than simple renamings) to what appears below "Tools" link on the Vector skin do not appear to be technically feasible. (Any changes above that section can be implemented by editing MediaWiki:Sidebar) * Pppery * it has begun... 01:19, 11 April 2020 (UTC)
 * Weak support – subject to technical feasibility, including not negatively impacting other skins - Evad37 &#91;talk] 01:53, 11 April 2020 (UTC)
 * Support - I don't think we should worry about technical feasibility. The WMF is already working on the UI, so a consensus here will help demonstrate that they should fix this restriction. MER-C 10:02, 11 April 2020 (UTC)
 * Support: Current technical feasibility is irrelevant; this will be implemented somehow if consensus exists. The label "Contribute" is much more inviting than "Interaction"; adding "Upload file" to it is a logical choice. ~ ToBeFree (talk) 03:38, 12 April 2020 (UTC)
 * Support  reasonable proposal per above. -- Puddleglum 2.0 (How's my driving?) 19:19, 12 April 2020 (UTC)
 * Support. Should improve navigability. --Yair rand (talk) 20:36, 12 April 2020 (UTC)
 * Support if technical difficulties can be overcome. Kirbanzo (userpage - talk - contribs) 21:40, 12 April 2020 (UTC)
 * Support more logical + easier to find stuff. buidhe 23:32, 12 April 2020 (UTC)
 * Support with "special pages" in tools. Contribute is a much more logical header than Interaction. — python coder (talk &#124; contribs) 00:20, 13 April 2020 (UTC)
 * Although as I look at it more, "Help" also has information for readers too.... — python coder (talk &#124; contribs) 00:42, 13 April 2020 (UTC)
 * Support it's a small improvement, but an improvement nonetheless. Thanks for proposing this! Ajpolino (talk) 16:52, 13 April 2020 (UTC)
 * Suppport, a clear improvement. Also suggest adding another heading to split up the first section between browse main content links (Main page, Contents, Featured content, Current events, Random article) and other interaction pages (About Wikipedia, Contact page, Donate to Wikipedia, Wikipedia store). Maybe call this section "Interaction"? Renata (talk) 03:57, 14 April 2020 (UTC)
 * Support, looks good. Utopes (talk / cont) 22:54, 14 April 2020 (UTC)
 * Support We need all the ways we can get to attract more contributors and make it clear that anyone can edit. CaptainEek  Edits Ho Cap'n!⚓ 21:58, 17 April 2020 (UTC)
 * Support, clear improvement assuming technical feasibility. – Teratix ₵ 12:57, 18 April 2020 (UTC)
 * Strong support: clearer structure and more readable. Would be better if we could add a subsection "Donate" containing "Donate to Wikipedia" and "Wikipedia store" (if we're not going to just remove the links outright, which we should). — Bilorv ( talk ) 17:51, 18 April 2020 (UTC)
 * Support. "Interaction" has always been an odd and inaccurate header. Changing to "Contribute" together with the moves suggested here makes the sidebar much better structured. the wub "?!"  20:45, 18 April 2020 (UTC)
 * Support. I was initially inclined to agree with KarasuGamma and Levivich about Special Pages, but found sdkb's rationale convincing. Renata's and Bilorv's proposals have merit, perhaps a separate discussion is required about splitting the top section. (I haven't read through the rest of this page yet, so may need to return here if anything changes my mind.) Pelagic (talk) 20:19, 20 April 2020 (UTC) I feel that Contribute is an improvement over Interaction; toolbox changes subject to technical feasibility per Discussion below. Pelagic (talk) 20:24, 20 April 2020 (UTC)
 * Support. these changes all sound very helpful. I totally support this. I appreciate the proposer of this, for proposing and formulating these changes. I hope they will continue to look for and to suggest ways to improve features and items in various places. well done!!!! cheers!! --Sm8900 (talk) 13:57, 22 April 2020 (UTC)
 * Support. These changes should help J cool bro   (talk) 16:48, 23 April 2020 (UTC)
 * Support I literally just commented that it's odd how the two non-specific links are in the middle of the Tools section surrounded by article-specific links. Reywas92Talk 19:41, 24 April 2020 (UTC)
 * Support Definite improvement, though would prefer Special pages in 'Tools'. Nick Moyes (talk) 07:29, 26 April 2020 (UTC)
 * Support a clear improvement. Always found the sidebar a bit of a mash of links. Having better defined structure will only help. Dreamy Jazz 🎷 talk to me &#124; my contributions 21:31, 26 April 2020 (UTC)
 * Support, this seems to simplify it well. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Support. <b style="font-family:Papyrus"> Anarchyte </b> ( talk &#8226;  work ) 10:08, 27 April 2020 (UTC)
 * Support. I agree with Nick's comment above about keeping Special pages in Tools, but it is not a big deal. --MarioGom (talk) 18:39, 27 April 2020 (UTC)
 * Support - As others have stated, it would delineate things much more clearly for new users. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)
 * Support - All looks good and sensible to me. -- The Anome (talk) 15:17, 29 April 2020 (UTC)
 * Comment I'm not happy with changing the section header from "Interaction" to "Contribute". I like the old title better. But if it is changed, I feel the links "Donate to Wikipedia" & "Wikipedia Store" are more intuitively placed under "Contribute". As with many others, I would keep "Upload page" & "Special pages" under "Tools", since they are tools. -- llywrch (talk) 17:06, 7 May 2020 (UTC)
 * Support. "Contribute" is a much stronger call to action than "Interaction". —  Newslinger  talk   09:27, 11 May 2020 (UTC)
 * Support. Except "Special pages" under Tools. As per Wugapodes above. comrade waddie96 (talk) 08:50, 14 May 2020 (UTC)

Discussion (Contribute section)
I note that the "Tools" section and everything below it is defined directly in the software, rather than being defined by MediaWiki:sidebar -- how do you plan to implement this? * Pppery * <sub style="color:#800000">it has begun... 23:38, 10 April 2020 (UTC)
 * I'm not a technical expert, so I won't be the one doing the implementation. If it's defined in the software, some assistance from WMF might be needed (the folks at the WMF Desktop Improvement Project are aware of this RfC). I think the best course of action is to establish what the community consensus is here first, and then figure out implementation subsequently. &#123;{u&#124; Sdkb  }&#125;  talk 23:51, 10 April 2020 (UTC)
 * If we're going to establish community consensus first and figure out implementation later, then I propose adding a link to the sidebar that, when clicked, will send the user a million dollars. :-) Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 00:11, 11 April 2020 (UTC)
 * This is a terrible idea and obviously a joke, but it's still a better use of funds than the Fram ban or the upcoming rebrand. — python coder (talk &#124; contribs) 00:37, 13 April 2020 (UTC)
 * , if there is consensus here, would you or someone else at WMF be able to assist with implementation? &#123;{u&#124; Sdkb  }&#125;  talk 05:05, 11 April 2020 (UTC)
 * This would be a great use case for T249673 I think DannyS712 (talk) 06:31, 11 April 2020 (UTC)

How is this meant to work in other skins like Timeless? - Evad37 &#91;talk] 01:00, 11 April 2020 (UTC)
 * This is a proposal for the default Vector skin (which I'd assume is used by 99%+ of desktop visitors). Whether/how to update Timeless is a separate discussion, and one that wouldn't need such widespread input. There are some things I like about Timeless, but my understanding is that a proposal to make it the default was rejected a while back. &#123;{u&#124; Sdkb  }&#125;  talk 01:12, 11 April 2020 (UTC)
 * Apologies, I missed that the top section said it was for the default skin only. Still, if there is consensus, then other skins do have to be considered in the implementation details, lest we end up with duplicated links or missing links in the non-default skins. - Evad37 &#91;talk] 01:27, 11 April 2020 (UTC)
 * I have removed the inaccurate notice in the top section that states this only impacts the default skin only. Any changes to Mediawiki:Sidebar are sitewide and impact all skins that include a sidebar; the only skin that would not be impacted would be Minerva (mobile). I am not sure what the notice was intended to indicate, and have no opposition for a corrected notice to be re-added. It felt inappropriate to leave the notice and await further discussion when it gave inaccurate information during active voting. ~ riley  ( talk  ) 05:18, 11 April 2020 (UTC)
 * I was going off what wrote just above here. Sdkb, can you clarify? If this proposal is to affect other skins, that should be mentioned in the top section instead of just saying Vector, and my query about what is proposed for other skins like Timeless is relevant. If not, can the removed notice or something similar be restored to the top section? - Evad37 &#91;talk] 14:25, 11 April 2020 (UTC)
 * I'm not a technical expert when it comes to skins, so someone else can probably provide better clarification. My intention is for Timeless to be unaffected as I stated above, and I wasn't the one who added the notice to the top. Given that Timeless already moves some links around (e.g. "upload file" is in a separate tools section than "page information", unlike Vector), I assume that its creators have at least some flexibility and could choose to either mirror the relevant changes to Vector proposed here or stay the same. - &#123;{u&#124; Sdkb  }&#125;  talk 17:43, 11 April 2020 (UTC)
 * To be clear: Anything on this RfC that involves changing the top sidebar (Main page, contents, featured content, etc) and the interaction sidebar (Help, About W, community portal, etc), as listed on Mediawiki:Sidebar, impacts all skins. Based on that, 95% of what I am seeing in this discussion impacts all skins. Any references that say "proposal for default Vector skin" or for "default desktop skin" are incorrect and misinforming voters. Those disclaimers can go into individual sections (i.e. if voting on changing the "Tools" sidebar in Vector) if needed. Please make these corrections sooner than later as this is an open RfC. ~ riley  ( talk  ) 19:02, 11 April 2020 (UTC)
 * I too am concerned about any impact on Timeless. Pinging Isarra who is the main magician behind that excellent skin. Oh, Evad37 has notified them on their talk page, please consider the ping as a mention not a summon. Pelagic (talk) 20:54, 20 April 2020 (UTC)
 * Note split into collapsed menus at the bottom of that table. I see now that medium-width Timeless (tablet in landscape mode) has four drop-downs for Navigation, Wiki tools, Page tools, and Other projects; in narrow layout (portrait mode) they are icons and the latter two are below the red line.  Only Navigation draws from Mediawiki:Sidebar, I guess the others are coded in the skin somewhere and shouldn't be affected by this RFC (see ).  It does give us a good precedent for separating Page tools from Wiki tools (and using those names) as discussed elsewhere on this page.  Aside: This digression on Timeless deserves its own section, but I don't want to relegate it to the bottom of the page where it will be seen less. Pelagic (talk) 21:38, 24 April 2020 (UTC)
 * How this would actually affect Timeless would very much depend on how you intend to make the changes. Timeless takes the core sidebar as part of the assembled array of all the navigation, and them sorts the contents into its own arrays in order to do the multiple sidebar blocks and cactions and whatnot, so if the changes are intended to be to that array, Timeless is likely to not even be affected, beyond the MediaWiki:Sidebar stuff. Other than that, I don't even know. There's a lot going on here. -— Isarra ༆ 21:40, 28 April 2020 (UTC)

Apologies if this is the wrong section for this comment. I think the proposal looks great. The one thing that stood out to me was putting "Cite this page" under "Print/Export" (whereas it seems to fit quite naturally as a page tool). Curious what your thinking there is? Also, it might make sense to rename "Tools" > "Page tools" so it is more explicit, especially to let people know that those tools are specific to that page. AHollender (WMF) (talk) 14:09, 14 April 2020 (UTC)
 * I tend to use BibTex so when I think of citations I do think of exporting the citation rather than looking for a citation tool, though I appreciate that I am likely a minority. In that sense, I prefer "Cite this page" as an export method rather than a "Page tool". — Wug·a·po·des​ 21:25, 14 April 2020 (UTC)
 * My thinking with that is that citing a page is something a reader might want to do, so it should go in a reader-focused section, whereas tools is an editor-focused section. Print/export is the section for reader-focused page-specific tools, and it's our good fortune that this can be added there without needing to change the section name. Regarding the name of the section, I think both your suggestion and 's suggestion of "editor tools" would be an improvement over the status quo. I'll start a new renaming section for a fuller discussion on that. &#123;{u&#124; Sdkb  }&#125;  talk 07:36, 15 April 2020 (UTC)


 * Seems like "cite this page" was sort of just slipped in to the mockup in this section, but there was no mention of it above. Citing isn't about "printing and exporting". — xaosflux  Talk 02:45, 20 April 2020 (UTC)

Move Wikidata to "In other projects"
Move Wikidata link from "Tools" to "In other projects" section. "Tools" are more links to help with a page on Wikipedia. Wikidata links to entirely different project. Never quite understood why it's in "tools" section to begin with.

Survey (move Wikidata)

 * Support as proposer. Renata (talk) 04:37, 14 April 2020 (UTC)
 * Support. Wikidata is a project. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 07:44, 14 April 2020 (UTC)
 * Weak oppose per AHollender's rationale. &#123;{u&#124; Sdkb  }&#125;  talk 04:40, 15 April 2020 (UTC)
 * Oppose. The "In other projects" already has a Wikidata link if a page has an equivalent in Wikidata. For example, Administrators' noticeboard links to Wikidata item "Special:EntityPage/Q4580256" from the tools section, and to Wikidata page "Wikidata:Administrators' noticeboard" in the other projects section. Peter James (talk) 10:41, 15 April 2020 (UTC)
 * How does that work? I've never noticed it in article space. Pelagic (talk) 21:22, 20 April 2020 (UTC)
 * That's because there are no articles that have equivalent pages on Wikidata. Each Wikidata item can be linked to a page on each wiki, including Wikidata itself. (In these cases, the linked Wikidata page will itself have a "Wikidata item" link in the Tools section.) Most items with pages on both Wikipedia and Wikidata are for project pages, help pages, templates, modules, or user categories. --Yair rand (talk) 18:41, 21 April 2020 (UTC)
 * Oh, I get it. As in: Wikidata has a main page which is functionally equivalent to the main Commons page or our Main Page. And it also has an item about the concept of "Wikimedia main pages" that binds those all together.  Thanks for explaining, .  It creates a tricky edge case.  Pelagic (talk) 20:52, 21 April 2020 (UTC)
 * Oppose per AHollender and Peter James. – Teratix ₵ 12:58, 18 April 2020 (UTC)
 *  Neutral Oppose : Meta-WIki is an multi-language wiki, and it's a project, but does not contain content. Same for MediaWiki. However, Wikidata is a multi-language wiki, and it's a project, and contains content provided for projects, making it a secondary project. So it's a project by contributors, for contributors. What's the difference between an article about amazon on the English Wikipedia compared to the Simple English Wikipedia? It's a different language with the same content (apart from complexity). Now what about comparing them to wikidata? Not the same content. Hmm. Maybe make this as a preference or a gadget, or in the tools section. &#123;&#123;replyto&#125;&#125; Can I Log In's (talk) page 03:29, 20 April 2020 (UTC); edited 06:04, 20 April 2020 (UTC)
 * Support, as you're looking at the topic from another project's view.  12:29, 20 April 2020 (UTC)
 * (ec) Support because I personally conceive of Wikidata as a sister project and keep looking for it under that heading, then doing a double-take and scanning the rest of the sidebar to find it. Yes, a part of Wikidata is inter-language linking for the Wikipedias, but it does have content which goes beyond that. Pelagic (talk) 21:26, 20 April 2020 (UTC)
 * Changed to neutral. Though counter-intuitive, the current placement is a case of "form follows function" as discussed with Peter James and Yair rand above.
 * Oppose. As previously mentioned, Wikidata may be another project but it doesn't function as one. The average non-editing reader would gain nothing of use from it. It is a tool used to provide cross-project structure, and it should be treated as such. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * I would like to but...: I would like to see this change, in principle. But after reading ' concerns, I think this is something that would require more thought about the right UX. --MarioGom (talk) 18:45, 27 April 2020 (UTC)
 * Oppose. Although Wikidata is another project, it has special status as the linchpin of the Wikipedia universe. -- The Anome (talk) 15:18, 29 April 2020 (UTC)
 * Weak oppose. This change would be helpful for longtime editors but, per Peter James above, this seems like a bad idea. comrade waddie96 (talk) 08:54, 14 May 2020 (UTC)

Discussion (move Wikidata)
So I agree that Wikidata could make sense in the "In other projects" section, as it is quite literally another project. If I were to try to make an argument for why it also makes sense in the "Tools" section, I would think less about the technical categorization, and more about the intent of the user. What is someone expecting to get if they click on a link within the "In other projects" section? I'm totally guessing here but I imagine people see those links as sort of a "Read/learn more about this topic in one of our other projects". So going to Wikiquote or Wikivoyage makes a lot of sense. However Wikidata is a bit different from other projects in that it is more of a "tool" rather than a content/learning experience. AHollender (WMF) (talk) 14:17, 14 April 2020 (UTC)
 * Note: Many (most?) articles currently don't have an "In other projects" section at all. This move would frequently cause there to be an extra section that otherwise wouldn't be there. --Yair rand (talk) 16:52, 23 April 2020 (UTC)

Move "In other projects" under "Print/export"
That way "In other projects" and "Languages" are shown together and not separated by a random tool section.

Survey (move In other projects)

 * Support as proposer. Renata (talk) 04:44, 14 April 2020 (UTC)
 * Support, makes sense. Utopes (talk / cont) 23:23, 14 April 2020 (UTC)
 * Support sounds fine to me. &#123;{u&#124; Sdkb  }&#125;  talk 04:42, 15 April 2020 (UTC)
 * Support logical. – Teratix ₵ 14:09, 18 April 2020 (UTC)
 * Support. This makes more sense and should probably be done by default on all sites, not just English Wikipedia. the wub "?!"  20:50, 18 April 2020 (UTC)
 * Support, great suggestion. Nouill (talk) 11:48, 26 April 2020 (UTC)
 * Support keeps similar links together. Makes sense. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 21:34, 26 April 2020 (UTC)
 * Support for consistency and readability. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Support, yes, please. This is pretty obvious. --MarioGom (talk) 18:48, 27 April 2020 (UTC)
 * Support - Provided it is technically feasible. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)

Separate "Page tools" and "User tools"
"User tools" would show up only in user space and "Page tools" would be same as on other pages.

Survey (user tools)

 * Support as proposer. Renata (talk) 05:09, 14 April 2020 (UTC)
 * Oppose. Each namespace has a different set of tools, and the Userspace is no exception. Still, I don't believe there is enough of a need to warrant parsing the "Tools" section in two for user pages only. In the example, many of the tools that have been moved to the "User Tools" are exclusive to administrators, which would leave a majority of the editors with an unnecessarily small "User Tools" section when the few that are added could be merged with the rest of the "Tools". This begs the question of whether the "Tools" section is worth being parsed in the first place, but this is a different topic all together. Utopes (talk / cont) 23:20, 14 April 2020 (UTC)
 * Oppose per Utopes. &#123;{u&#124; Sdkb  }&#125;  talk 04:32, 15 April 2020 (UTC)
 * So, for those not logged in, the User tools section would contain "User contributions", "View user groups", and "Logs". Non-admin users would have "Mute preferences" and "Email this user" added. Blocking is the only admin-specific addition, as user group management has a non-admin equivalent item in the list. Even just three items would be larger than Print/Export, which only has two. Seems to me like it would be a helpful division. (Support.) --Yair rand (talk) 17:53, 19 April 2020 (UTC)
 * Don't see a need to divide just for userspace. ~ Amory <small style="color:#555"> (u • t • c) 09:57, 20 April 2020 (UTC)
 * Support the term Page Tools as suggested by in other section above. Do this consistently everywhere, and add User Tools in userspace. Pelagic (talk) 22:20, 20 April 2020 (UTC) fixed typo Pelagic (talk) 22:22, 20 April 2020 (UTC)
 * Support - The Tools section can get unwieldy in userspace, and I am not even an administrator. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)

Discussion (user tools)

 * One issue: The links for "Special pages" and "Upload file" really aren't specific to the page. Labeling them "page tools" would be problematic. However, the reordering proposal above moves both of these into the new "contribute" section. --Yair rand (talk) 21:15, 21 April 2020 (UTC)
 * If not technically feasible to put "Special pages" and "Upload file" in Contribute (could impact non-Vector skins), then they'd need a new section with a name like "Wiki tools". Pelagic (talk) 22:19, 24 April 2020 (UTC)

Move "Print/export" above "Tools"
The made it clear that casual readers had no use or understanding of "tools" section, but they understood and could use "print/export" functions. Therefore, proposing to move the section up above "Tools" [which could get very bloated in some namespaces] to make it easier to find. Editors will find their tools regardless.

To clarify: if both this and the are agreed on, then the order would be: Print/Export, Tools, In other projetcs, Languages. Renata (talk) 06:27, 21 April 2020 (UTC)

Survey (move up print/export)

 * Support as proposer. Renata (talk) 20:05, 18 April 2020 (UTC)
 * Support strongly. A clear application of WP:READER. &#123;{u&#124; Sdkb  }&#125;  talk 21:11, 18 April 2020 (UTC)
 * Support as it's a short section.  12:35, 20 April 2020 (UTC)
 * Support both moves, the resulting section order has a nice progression. Pelagic (talk) 12:32, 21 April 2020 (UTC)
 * Support pretty much as above. Print/exporting options are more useful to the reader than the tools section. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 21:44, 26 April 2020 (UTC)
 * Support for usability. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Support. And I would support moving Tools to the last section anyway. It's just way too advanced for most people. --MarioGom (talk) 18:50, 27 April 2020 (UTC)

Discussion (move up print/export)

 * If both this proposal and the one above,, pass, then we'd have print/export, then tools, then "in other projects, then languages. That seems alright to me. &#123;{u&#124; Sdkb  }&#125;  talk 22:14, 18 April 2020 (UTC)
 * It depends on which order you apply the proposals in. It would be truer to the intent of the first proposal (to avoid splitting "print/export" and "in other projects" with the "tools" section) to apply this second proposal first (move "print/export" above "tools"), then the first proposal (move "in other projects" under "print/export"). This results in a new order of "print/export", "in other projects", "tools", then "languages". – Teratix ₵ 01:37, 21 April 2020 (UTC)
 * I proposed both moves, so I clarified above what the final order would look line. Essentially, what Sdkb said. Renata (talk) 06:27, 21 April 2020 (UTC)

Renamings
This set of proposals suggests renamings of the labels used for some of the sidebar links.

Donate to Wikipedia → Donate

 * Support as proposer. It's obvious where the donations will go. &#123;{u&#124; Sdkb  }&#125;  talk 21:46, 10 April 2020 (UTC)
 * Support per above. <b style="color:#090">Semi</b><i style="color:#099">Hyper</i><u style="color:#009">cube 21:57, 10 April 2020 (UTC)
 * Support don't see why not.-- Moxy 🍁 22:01, 10 April 2020 (UTC)
 * Support - This change is in line with the KISS principle. Interstellarity (talk) 22:17, 10 April 2020 (UTC)
 * Support, same reasons. I would suggest changing the tooltip to "Support us by donating to Wikipedia". <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 22:52, 10 April 2020 (UTC)
 * Support ~ riley  ( talk  ) 23:03, 10 April 2020 (UTC)
 * Support Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 23:17, 10 April 2020 (UTC)
 * Good but please make another mock-up that includes the proposed renamings because details matter. Johnuniq (talk) 23:44, 10 April 2020 (UTC)
 * Support --Tom (LT) (talk) 00:12, 11 April 2020 (UTC)
 * Support per proposer. –dlthewave ☎ 02:05, 11 April 2020 (UTC)
 * Support. MER-C 09:18, 11 April 2020 (UTC)
 * Support with caveat. A change like this might seem very simple, but could have positive or negative effects on the volume of donations received through the link. I'd propose that if this is supported we work with the WMF Fundraising team to ensure that we can track data about how many times this donation link is used, and if this change has an adverse effect, to revert the change. Sam Walton (talk) 12:27, 11 April 2020 (UTC)
 * Good thought! If we know anyone on that team, perhaps it'd be good to ping them to see if they have any thoughts on this or the Wikipedia store → Merchandise change. &#123;{u&#124; Sdkb  }&#125;  talk 17:46, 11 April 2020 (UTC)
 * Pinging Sam Walton (talk) 19:29, 11 April 2020 (UTC)
 * This could be A/B tested. Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 05:01, 12 April 2020 (UTC)
 * "Donate" is the default text, so presumably there's no issue. Still, we've had it this way for over a decade, so there could be ramifications.  Worth testing, perhaps. ~  Amory <small style="color:#555"> (u • t • c) 10:01, 20 April 2020 (UTC)
 * Support I actually went 'Huh, that should be renamed to just Donate' right before scrolling down and seeing it was included in the proposal GoodCrossing (talk) 12:42, 11 April 2020 (UTC)
 * Support for simplicity and accuracy (donations go to the Wikimedia Foundation, via country chapters like Wikimedia Germany for some users, and are not only used for running Wikipedia). ~ ToBeFree (talk) 03:07, 12 April 2020 (UTC)
 * Support. --Yair rand (talk) 20:36, 12 April 2020 (UTC)
 * Support - Donations go to the Wikimedia Foundation for use on all projects, not only Wikipedia. Kirbanzo (userpage - talk - contribs) 21:39, 12 April 2020 (UTC)
 * Support with caveat from Sam Walton above. "Donate" seems common and simple enough, but it's also best to have a backup in case it has adverse effects. - Whisperjanes (talk) 22:06, 12 April 2020 (UTC)
 * Support A/B testing to see which version is more effective. <b style="color: White">b</b><b style="color: White">uidh</b><b style="color: White">e</b> 23:44, 12 April 2020 (UTC)
 * Support - Equally clear with two fewer words. Ajpolino (talk) 16:52, 13 April 2020 (UTC)
 * Support, seems clear to me. Utopes (talk / cont) 22:58, 14 April 2020 (UTC)
 * Support The Department of Redundnacy Department strikes again. CaptainEek  Edits Ho Cap'n!⚓ 21:59, 17 April 2020 (UTC)
 * Support per ToBeFree, with Sam Walton's caveat. – Teratix ₵ 13:00, 18 April 2020 (UTC)
 * Strong support regardless of whether it increases or decreases revenue, because as Kirbanzo points out donations don't really go to Wikipedia at all, but to the WMF for use on all projects. Suggest renaming the tooltip to "Donate to the Wikimedia Foundation". — Bilorv ( talk ) 18:17, 18 April 2020 (UTC)
 * Support: It's not being donated to Wikipedia. It's being donated to the Wikipedia Foundation. &#123;&#123;replyto&#125;&#125; Can I Log In's (talk) page 01:04, 20 April 2020 (UTC)
 * Change to "Donate to WMF" to make it clear to readers that they are donating to the Wikimedia Foundation (which has no financial problems), rather than directly supporting editors. feminist #WearAMask😷 07:30, 20 April 2020 (UTC)
 * Support, as conciseness is one of the goals of this RfC.  12:47, 20 April 2020 (UTC)
 * Strong support because the donation's aren't only spent on the 'pedias. Pelagic (talk) 12:26, 21 April 2020 (UTC)
 * Comment, no objections from WMF. We’ve done very occasional a/b testing of the desktop sidebar "Donate to Wikipedia" link, and it’s something we would potentially like to revisit in the future, so we may come back to this later. Quiddity (WMF) (talk) 23:06, 21 April 2020 (UTC)
 * Thanks for letting us know, Quiddity. This conversation seems ready to close to me if anyone uninvolved wants to go ahead and do so. &#123;{u&#124; Sdkb  }&#125;  talk 09:59, 22 April 2020 (UTC)
 * SupportIt is obvious where the donations are going to. J cool bro   (talk) 16:52, 23 April 2020 (UTC)
 * Support (I would like some A/B testing first) seems logical that the donate button is the donate button for the website in question. However, some A/B testing would be a good idea. Donations run the servers / WMF after all... Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 21:41, 26 April 2020 (UTC)
 * Support. The donations aren't used exclusively for Wikipedia anyway. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Remove link entirely per WP:CANCER. Chris Troutman  ( talk ) 13:55, 27 April 2020 (UTC)
 * Support. If, after the fact, the WMF shows this leads to a reduction in donations, I wouldn't mind them reverting the change. Per Sam Walton's comment. I doubt it would be significant anyway. --MarioGom (talk) 18:53, 27 April 2020 (UTC)
 * Support - This is the standard practice in many other websites for a good reason. Although it probably would reduce donations slightly, the WMF has enough as it is. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C
 * Support ... make it cleaner. Jason Quinn (talk) 11:53, 2 May 2020 (UTC)
 * Support --- should always have been one word. Actually, all menu entries should be as short as possible, on the "Cut", "Copy", "Paste", "Undo" model. Chiswick Chap (talk) 13:25, 3 May 2020 (UTC)

Wikipedia store → Merchandise

 * Support as proposer. Reduces from two words to one. &#123;{u&#124; Sdkb  }&#125;  talk 21:46, 10 April 2020 (UTC)
 * Support seems to clarify it. <b style="color:#090">Semi</b><i style="color:#099">Hyper</i><u style="color:#009">cube 21:57, 10 April 2020 (UTC)
 * Support don't see why not.-- Moxy 🍁 22:01, 10 April 2020 (UTC)
 * Support - This change is in line with the KISS principle. Interstellarity (talk) 22:17, 10 April 2020 (UTC)
 * Support, same reasons. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 22:52, 10 April 2020 (UTC)
 * Support ~ riley  ( talk  ) 23:03, 10 April 2020 (UTC)
 * Support – I'd also be OK with deleting this link. Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 23:17, 10 April 2020 (UTC)
 * Support "Merchandise" clearly refers to physical goods, while "store" is increasingly used for app stores, digital downloads, etc. –dlthewave ☎ 02:05, 11 April 2020 (UTC)
 * Support. MER-C 09:18, 11 April 2020 (UTC)
 * Support Seems reasonable and I like it better GoodCrossing (talk) 12:43, 11 April 2020 (UTC)
 * Comment To my ear (eye?), somewhat US English centric; perhaps shop instead? (which to most US English speakers would be read as a verb, but UK/South African/Australian/NZ/Indian English speakers would read as a noun...Can't comment for Canadian English). --Goldsztajn (talk) 12:47, 11 April 2020 (UTC)
 * Support: Not an application store; this is for physical merchandise. ~ ToBeFree (talk) 03:10, 12 April 2020 (UTC)
 * Support - Should clear up any confusion on what is being sold there. Kirbanzo (userpage - talk - contribs) 21:38, 12 April 2020 (UTC)
 * Support - though my first choice would be deleting the link. Ajpolino (talk) 16:52, 13 April 2020 (UTC)
 * Support, seems clear about what this refers to. Utopes (talk / cont) 22:59, 14 April 2020 (UTC)
 * Support per dlthewave. – Teratix ₵ 13:01, 18 April 2020 (UTC)
 * Support, as a second preference to removal. — Bilorv ( talk ) 18:11, 18 April 2020 (UTC)
 * Support per dlthewave. the wub "?!"  20:52, 18 April 2020 (UTC)
 * Support as a second choice per Ajpolino and Bilorv. feminist #WearAMask😷 07:33, 20 April 2020 (UTC)
 * Oppose Yech. I'll agree that "Wikipedia store" isn't awesome, but "merchandise" is aggressively commercial.  Couldn't disagree more that "store" implies something digital.  "Wikipedia shop" seems better to me, but only minorly so. ~  Amory <small style="color:#555"> (u • t • c) 10:04, 20 April 2020 (UTC)
 * Support, as conciseness is one of the goals of this RfC. Alos, it makes it clear that WP is free, ant there are no 'extras' or hidden costs.  12:48, 20 April 2020 (UTC)
 * Unsure. Prefer shop or merchandise over store (what am I storing?), but not sure which of the two is better.  Shop can be a verb or noun, and would work well under a Wikipedia heading with other verbs Contact, Donate.  Slang 'merch' to me has connotations of branded tee-shirts and coffee mugs, often as freebies, but does merchandise feel too formal?  As I write this I'm leaning more toward shop.  Pelagic (talk) 13:15, 21 April 2020 (UTC)
 * Comment, We call it the Store, and it lives at the subdomain store.wikimedia.org. WMF would prefer that we just keep this as “Store”, but are open to renaming it. Quiddity (WMF) (talk) 23:08, 21 April 2020 (UTC)
 * Oppose, it sounds a bit commercial and "Wikipedia Store" leaves less place for confusion. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Support "Store" as that's the name of the page it leads to.--YTRK (talk) 13:28, 27 April 2020 (UTC)
 * Support renaming to 'Merchandise'. I think people viewing a website increasingly expect a 'store' to offer digital goods. Blythwood (talk) 14:49, 27 April 2020 (UTC)
 * Support a shorter name but unsure about Merchandise. Are we sure this is as universal as store/shop? --MarioGom (talk) 18:57, 27 April 2020 (UTC)
 * Support - "Merchandise" isn't ideal, but is better than the current solution, being both more clear and consise. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)
 * Well, "Merchandise" is better than the utterly illegible "Wikipedia store" but "Shop" (or "Store") would be better still. "Shop" is best as it can be read as a suggestion to get shopping... Chiswick Chap (talk) 13:27, 3 May 2020 (UTC)

Discussion (Wikipedia store → Merchandise)

 * Thanks for the input Quiddity (WMF), I appreciate you engaging with the discussion here. One can go shopping at a store so I don't think it would astonish people to click "Shop" and end up at a page headed "Wikipedia Store".  There is value in consistent terminology and branding, so what terms the Foundation use should be considered. (I won't suggest re-titling it to "Wikimedia Store" to be consistent with the DNS domain!) In terms of the store vs. the shop as nouns, is that a US/UK English thing?  You probably have more important things on your plate right now, but would you consider a straw poll of your non-US WMF colleagues to gauge how they feel about the various words?  Pelagic (talk) 01:17, 23 April 2020 (UTC)


 * It seems to me that there are two aspects to this proposal: (a) something shorter than Wikipedia store as the Wikipedia context is evident; (b) which term to use – Store, Shop, Merchandise, other. My question is how much of the support above, which precedes suggestion of alternatives for Merchandise, is just for (a) and how much also for (b)="Merchandise"?  Pelagic (talk) 01:17, 23 April 2020 (UTC)


 * UK vs US aside, I'm concerned about Merchandise being less universal and less recognizable. --MarioGom (talk) 18:59, 27 April 2020 (UTC)
 * Just remove the link. There was never consensus for it and the store only serves a minuscule portion of the world's population, while Wikipedia is supposed to be an international project. Nemo 17:21, 28 April 2020 (UTC)
 * That's a separate proposal at . --Yair rand (talk) 17:24, 28 April 2020 (UTC)

About Wikipedia → About

 * Support as proposer. Readers know which site they're on. &#123;{u&#124; Sdkb  }&#125;  talk 21:46, 10 April 2020 (UTC)
 * Support per above. <b style="color:#090">Semi</b><i style="color:#099">Hyper</i><u style="color:#009">cube 21:57, 10 April 2020 (UTC)
 * Support don't see why not.-- Moxy 🍁 22:01, 10 April 2020 (UTC)
 * Support - This change is in line with the KISS principle. Interstellarity (talk) 22:17, 10 April 2020 (UTC)
 * Support, same reasons. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 22:52, 10 April 2020 (UTC)
 * Oppose; Tony and Wugapodes convinced me otherwise. There is no harm in leaving this, and there potentially is harm in removing it. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 04:18, 11 April 2020 (UTC)
 * Support or "About us" ~ riley  ( talk  ) 23:03, 10 April 2020 (UTC)
 * I agree. Many websites use those exact words when describing what their website is about. Interstellarity (talk) 11:21, 11 April 2020 (UTC)
 * Oppose About - Support About us. ~ riley  ( talk  ) 08:00, 12 April 2020 (UTC)
 * Support Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 23:17, 10 April 2020 (UTC)
 * Oppose this isn’t a journalism piece where concision in design is key. This causes no harm, and I actually think helps with branding by reinforcing the name. It also feels less cold than just “about”. So far this is the only one I plan on commenting on, because I don’t care about the others, but this seems like it’s unneeded and driven by a desire for concision that doesn’t really help anything in this case. TonyBallioni (talk) 23:28, 10 April 2020 (UTC)
 * Oppose it will not be clear to readers what "About" refers to. Firstly, readers may think that "About" refers to the page they are currently on, especially if they're noticing it for the first time. Secondly, few readers understand the distinction between the various Wikimedia projects, and removing "Wikipedia" from "About Wikipedia" removes one of the few obvious indications of that branding difference. — Wug·a·po·des​ 00:09, 11 April 2020 (UTC)
 * Support taking into account some opposes above, I find the meaning of 'about' to be quite clear.--Tom (LT) (talk) 00:13, 11 April 2020 (UTC)
 * Oppose Not quite clear what it's "about". However, it could work as part of a "Wikipedia" section including "store", "about", "contact" and "donations" which relate more to the organization than the encyclopedia itself. –dlthewave ☎ 02:05, 11 April 2020 (UTC)
 * Oppose About is too vague. It could be about the article, MediaWiki... I think it should be kept as About Wikipedia as that's more clear. GoodCrossing (talk) 12:44, 11 April 2020 (UTC)
 * Question to the opposers - What is your opinion on renaming the About Wikipedia link to About us? Which one do you prefer? Interstellarity (talk) 12:58, 11 April 2020 (UTC)
 * While 'About us' is better in my opinion than 'About', I'd still weakly oppose it as I don't really consider it an improvement from 'About Wikipedia'. What I mean is that 'About us' is fine, but there's no reason to use 'About us' over 'About Wikipedia', so I don't think it's necessary to change it in that case. GoodCrossing (talk) 13:03, 11 April 2020 (UTC)
 * About Wikipedia just sounds better. TonyBallioni (talk) 15:30, 11 April 2020 (UTC)
 * I have a weak preference for "Wikipedia" over "us", but either is better than nothing. My concern about "us" is that in English it is ambiguous whether "us" includes or excludes the addressee and so readers may see the phrase as excluding them when we really mean to include readers as part of our community. I'd support it as a compromise position though. — Wug·a·po·des​ 20:59, 11 April 2020 (UTC)
 * I think most readers would almost certainly not interpret "us" to include themselves. It makes me a little uneasy for that reason, but I don't have any big objection to it. &#123;{u&#124; Sdkb  }&#125;  talk 23:55, 11 April 2020 (UTC)
 * I would actually think that "About us" under a section titled "Interaction" would be more confusing to users on a page like One Direction or something. Why wouldn't that imply "information about the group" to someone not looking too deeply? ~  Amory <small style="color:#555"> (u • t • c) 10:09, 20 April 2020 (UTC)
 * I prefer "About Wikipedia". <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 06:25, 12 April 2020 (UTC)
 * Oppose. This change would take away a bit of meaning. — python coder (talk &#124; contribs) 00:38, 13 April 2020 (UTC)
 * Oppose - it's pretty obvious, but could still in theory refer to a couple of things (Wikipedia, the WMF, even the page currently being viewed etc) Nosebagbear (talk) 10:00, 13 April 2020 (UTC)
 * Oppose It's obvious to us, but a newcomer rmight think it referred to the foundation.  DGG ( talk ) 00:23, 14 April 2020 (UTC)
 * Oppose plain "About" as too ambiguous. Would support "About us" as that is pretty standard across the web. Renata (talk) 04:53, 14 April 2020 (UTC)
 * Oppose, as "About" still might not be entirely clear what is being described at this page, and also oppose "about us" due to creating a shroud of exclusivity per Wugapodes. Utopes (talk / cont) 22:04, 14 April 2020 (UTC)
 * Neutral leaning weak oppose on "About" (per Wugapodes's point about ambiguity between article and Web site), but strongly oppose "About Us": the link target is about the encyclopedia, not any people or group of people. Also, it reads very "corporate" to me, with attendant instinctive revulsion. Not an improvement, in my opinion. —&#123;&#123;u&#124;Goldenshimmer&#125;&#125; (they/them)｜Talk｜Contributions 03:58, 15 April 2020 (UTC)
 * Oppose I think that this could be a bit confusing, people might think that the "About" is about the page you're on, not about Wikipedia in general. CaptainEek  Edits Ho Cap'n!⚓ 22:00, 17 April 2020 (UTC)
 * Oppose, ambiguous. – Teratix ₵ 14:00, 18 April 2020 (UTC)
 * Oppose "About" as more ambiguous. "About us" could work, but I don't really see it as an improvement over the current version. the wub "?!"  20:56, 18 April 2020 (UTC)
 * As above, "About" is much more confusing. If you're on a company page, it's clear what it means, but this is an encyclopedia, with actual content on pages.  "About us" isn't any better for those reasons. ~  Amory <small style="color:#555"> (u • t • c) 10:06, 20 April 2020 (UTC)
 * Oppose because About Wikipedia is unambiguous; but would support a Wikipedia heading as suggested by, with single-word entries About, Contact, etc. Pelagic (talk) 12:59, 21 April 2020 (UTC)
 * Oppose as above just "about" could mean about this page to a reader. Adding Wikipedia stop confusion in this case. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 21:47, 26 April 2020 (UTC)
 * Hesitant support, the phrasing of "About Wikipedia" seems more appealing to me, but this reduces the wordcount a bit. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Weak oppose, even if I like the proposed short versions, this one might be slightly contextually confusing. --MarioGom (talk) 19:01, 27 April 2020 (UTC)
 * Support but oppose "About us" - "Wikipedia" is of course redundant, but since the page is about the encyclopedia, not the community, the "us" is inappropriate. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)
 * Support --- "About..." is the classic menu entry, and everybody knows what it means. Or we could go the other way and call it "About the incredibly fascinating and complex Wikimedia foundation which isn't the same as Wikip" (oops used up all the allowed characters). Chiswick Chap (talk) 13:29, 3 May 2020 (UTC)

Contact page → Contact

 * Support as proposer. There's no need to label this as "page". &#123;{u&#124; Sdkb  }&#125;  talk 21:46, 10 April 2020 (UTC)
 * Support "page" is redundant. <b style="color:#090">Semi</b><i style="color:#099">Hyper</i><u style="color:#009">cube 21:57, 10 April 2020 (UTC)
 * Support don't see why not.-- Moxy 🍁 22:01, 10 April 2020 (UTC)
 * Support - This change is in line with the KISS principle. Interstellarity (talk) 22:17, 10 April 2020 (UTC)
 * Support, same reasons. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 22:52, 10 April 2020 (UTC)
 * I prefer "Contact us" as well. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 06:28, 12 April 2020 (UTC)
 * Support ~ riley  ( talk  ) 23:02, 10 April 2020 (UTC)
 * Prefer "Contact us" ~ riley  ( talk  ) 07:59, 12 April 2020 (UTC)
 * Support Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 23:17, 10 April 2020 (UTC)
 * Support –dlthewave ☎ 02:05, 11 April 2020 (UTC)
 * Support. MER-C 09:47, 11 April 2020 (UTC)
 * Prefer "Contact us". MER-C 13:01, 11 April 2020 (UTC)
 * Support, but "Contact us" would sound better.  Sandstein   10:47, 11 April 2020 (UTC)
 * I agree. Many websites include a place to contact the site owners. I see those same exact words on a lot of websites. Interstellarity (talk) 11:18, 11 April 2020 (UTC)
 * Support as 'Contact page' sounds like some sort of carbon copy. Strongly support 'Contact us' as per Sandstein GoodCrossing (talk) 12:46, 11 April 2020 (UTC)
 * Support with preference for "Contact us" per .--Goldsztajn (talk) 12:54, 11 April 2020 (UTC)
 * Support "Contact us": That's even the name of the linked page. ~ ToBeFree (talk) 03:13, 12 April 2020 (UTC)
 * Support, either "Contact" or "Contact us". --Yair rand (talk) 20:36, 12 April 2020 (UTC)
 * Support. No need for the "page". — python coder (talk &#124; contribs) 00:39, 13 April 2020 (UTC)
 * I'm okay with either "contact" or "contact us". — python coder (talk &#124; contribs) 13:20, 22 April 2020 (UTC)
 * Support - Agree "Contact" is clearer. Ajpolino (talk) 16:52, 13 April 2020 (UTC)
 * Support Contact us as it's pretty much standard across the web. Renata (talk) 04:54, 14 April 2020 (UTC)
 * Support Contact us As the universal standard CaptainEek  Edits Ho Cap'n!⚓ 22:01, 17 April 2020 (UTC)
 * Support Contact us per ToBeFree, with "contact" as a second choice. – Teratix ₵ 14:01, 18 April 2020 (UTC)
 * Support "Contact us" as first choice, and "Contact" as second choice. And can we get this implemented 15 years ago? — Bilorv ( talk ) 18:20, 18 April 2020 (UTC)
 * Support "Contact us" as first preference, "Contact" as second preference. the wub "?!"  20:57, 18 April 2020 (UTC)
 * Support Contact us, and we probably should include more prominent links on that page to WP:TH/WP:RD instead of telling readers to leave comments on never-visited talk pages. Or create a tool that allows them to make edit requests easily. feminist #WearAMask😷 07:35, 20 April 2020 (UTC)
 * I think the "page" is confusing; it's not clear that you are going to a page about contact rather than contacting the page in question. I'd favor Contact but given that we're going to Contact us, that's probably the better option. ~  Amory <small style="color:#555"> (u • t • c) 10:11, 20 April 2020 (UTC)
 * Support, otherwise we might as well rename it to "View the page on infomation to do with contacting us"  13:05, 20 April 2020 (UTC)
 * Support either, but prefer Contact over Contact us. The latter sounds more corporate to me. P.S. good one, Beans! P.P.S. who is Paige and why are we contacting her? Pelagic (talk) 12:43, 21 April 2020 (UTC)
 * Support either Contact or Contact us. It is clearer and more concise. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 21:49, 26 April 2020 (UTC)
 * Support, there's no advantage to having page tacked on the end. "Contact" is much clearer and in-line with the rest of the internet.
 * Support - slight preference for Contact over Contact us. --MarioGom (talk) 19:03, 27 April 2020 (UTC)
 * Support - Not only is the additional wording needless cruft, but it is also antiquated. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)
 * Support ... this is a no-brainer. Jason Quinn (talk) 11:54, 2 May 2020 (UTC)
 * Support, can we not take even these "why wasn't it like that already" actions without the full nine yards of timewasting discussion. Chiswick Chap (talk) 13:31, 3 May 2020 (UTC)

Main page → Main Page

 * Support - In this RM, the proposal to rename the Main Page has been rejected by the community. It makes sense to rename this link in line with the name of the Main Page. Interstellarity (talk) 21:46, 10 April 2020 (UTC)
 * Support makes sense. <b style="color:#090">Semi</b><i style="color:#099">Hyper</i><u style="color:#009">cube 21:57, 10 April 2020 (UTC)
 * Support don't see why not.-- Moxy 🍁 22:01, 10 April 2020 (UTC)
 * Support, same reasons. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 22:52, 10 April 2020 (UTC)
 * Strong Oppose It is Mediawiki standard that the Main page description be sentence-case and it is standard globally across majority of Wikipedias. This is standard across hundreds of languages on Translatewiki. Don't fix what is not broken. Unlike the other proposals, there is literally no benefit to this change. ~ riley  ( talk  ) 23:02, 10 April 2020 (UTC)
 * Comment: I am confused. It's already called Main Page. So why are we renaming a redirect to Main Page? &#123;&#123;replyto&#125;&#125; Can I Log In's (talk) page 23:06, 10 April 2020 (UTC) Support: It's one of those things in life where you don't or never notice it, but when you notice it, it hurts your OCD. It's a Title Page, and titles are Capitalized. &#123;&#123;replyto&#125;&#125; Can I Log In's  (talk) page 23:11, 10 April 2020 (UTC)
 * Support Any attempt to oppose this proposal is fundamentally relitigating Talk:Main Page. * Pppery * <sub style="color:#800000">it has begun... 23:11, 10 April 2020 (UTC)
 * Oppose – sentence case is better, and I don't give any weight at all to the WP:LOCALCONSENSUS of a not-widely-advertised RM that started on April Fool's Day and was closed after three days. Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 23:15, 10 April 2020 (UTC)
 * Oppose No one cares what Main Page is called (apart from people with too much time), but it would be very counter productive to promote the idea that Every Title Should Use Capitals. Johnuniq (talk) 23:42, 10 April 2020 (UTC)
 * Oppose per Riley and Johnuniq. — Wug·a·po·des​ 00:11, 11 April 2020 (UTC)
 * Oppose not consistent with our internal rules for titling headings, so this does not make sense to me.--Tom (LT) (talk) 00:13, 11 April 2020 (UTC)
 * Oppose. Wikipedia uses sentence case.  Sandstein   10:46, 11 April 2020 (UTC)
 * Oppose Main Page is fine as a title, but I think in the link it should be kept in sentence case. GoodCrossing (talk) 12:48, 11 April 2020 (UTC)
 * Oppose sentence case is preferable. L EPRICAVARK ( talk ) 16:36, 12 April 2020 (UTC)
 * Weak support - title case is vastly better, and I'd rather we shifted all our titles to a standard title case variant, but so long as the sentence case advocates are in the majority, it would be a bit odd for this to contradict. Nosebagbear (talk) 10:02, 13 April 2020 (UTC)
 * Oppose Goes against our general capitalization style of title pages, and I think it looks unprofessional compared to our other links. Our users will question why "Page" is the only capitalized second word in the side bar aside from Wikipedia. Page is not a proper noun. CaptainEek  Edits Ho Cap'n!⚓ 22:02, 17 April 2020 (UTC)
 * Support: not a big deal, but the Main Page is called "Main Page" and a local consensus here will not overturn the longstanding consensus for that. The Main Page is a unique occurrence on Wikipedia in many ways—name another article/mainspace page which is not an article—and Title Case is one of those exceptions. — Bilorv ( talk ) 18:30, 18 April 2020 (UTC)
 * Oppose. Everything else in the interface uses sentence case: the rest of the sidebar, "Edit source", "View history", "Log out" etc. Content too generally uses sentence case e.g. for page titles and headings. I don't see a reason to change that here, and would probably have supported moving the Main Page itself if I had seen that discussion. the wub "?!"  21:02, 18 April 2020 (UTC)
 * Remove altogether. Anyone who wants to visit the main page can simply click on the Wikipedia globe. (Modify the Modern skin to retain a link to the main page.) feminist #WearAMask😷 07:39, 20 April 2020 (UTC)
 * Hah! I'm on Modern and intentionally remove the link! ~  Amory <small style="color:#555"> (u • t • c) 10:14, 20 April 2020 (UTC)
 * It's a link; as above, it should be sentence case for the user. ~ Amory <small style="color:#555"> (u • t • c) 10:14, 20 April 2020 (UTC)
 * Question to the opposers: I recently proposed a move to move the Main Page to sentence case that did not succeed. If I were to do that again, would you support the move? If not, why? Interstellarity (talk) 11:54, 22 April 2020 (UTC)
 * I'm not sure as I haven't looked too much into the issue, and in my opinion they are two different matters, so my !vote here wouldn't influence my !vote there. GoodCrossing (talk) 12:44, 22 April 2020 (UTC)
 * I would support the move, as I think that our titles ought be sentence case, and that "page" is not being used as a proper noun, rather "main" is describing page as a regular noun. However I would caution that re-opening such a discussion might be seen as re-litigation. However the opening of it on April Fools may have also led to its speedy demise, as many came across it first as a joke, which might reduce people's angst about a new discussion. CaptainEek  Edits Ho Cap'n!⚓ 16:07, 22 April 2020 (UTC)
 * I have reopened the discussion here because when I originally opened the discussion on April Fools, not many people took it seriously. I am reopening it again with the hope that people will take it seriously this time. Interstellarity (talk) 18:26, 22 April 2020 (UTC)


 * Oppose - my head explodes if I see an item in a list standing out with an inconsistent capitalization convention. --MarioGom (talk) 19:07, 27 April 2020 (UTC)
 * Oppose - Goes against the consistent (and superior) use of sentence case. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)
 * Oppose - Inconsistent with other links in that section. -- Netoholic @ 10:19, 6 May 2020 (UTC)

Logs → Logged actions

 * Support as proposer. I have proposed a new link called "Logs" below, and this title is less ambiguous anyway. Note that this one appears only in user/user-talk space and on Special:Contribs. –<b style="color:#77b">Laundry</b><b style="color:#fb0">Pizza</b><b style="color:#b00">03</b> ( d c̄ ) 00:39, 11 April 2020 (UTC)
 * This is for the logs that are only on a user page right (i.e. MediaWiki:Log) correct? Perhaps "User's logs" would be more descriptive here. — xaosflux  Talk 02:02, 11 April 2020 (UTC)
 * Support though I prefer "User's logs" as more obvious. Maybe even "User's logged actions" though that's pretty long. — Wug·a·po·des​ 02:58, 11 April 2020 (UTC)
 * Oppose: Point 4 of the proposal is "The names for some links are overly verbose or unclear. Brevity is the soul of wit, and of good Web usability. We should not use two or three words where one will do." ~ ToBeFree (talk) 03:16, 12 April 2020 (UTC)
 * Oppose – "We should not use two or three words where one will do." Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 20:15, 12 April 2020 (UTC)
 * Support "Logged actions" or "User logs" as more clear, "logs" can refer to a lot of different things. <b style="color: White">b</b><b style="color: White">uidh</b><b style="color: White">e</b> 23:46, 12 April 2020 (UTC)
 * Support "User logs" as the clearest label. So that is follows the same format as "User contributions". Adding 4 letters won't kill anyone only will potentially alleviate some confusion. Renata (talk) 05:11, 14 April 2020 (UTC)
 * Support as "User('s) logs". <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 07:46, 14 April 2020 (UTC)
 * Support: in this case one word won't do, because a reader couldn't work out what clicking on "Logs" will do without either clicking on it or using superhuman powers of abduction. — Bilorv ( talk ) 18:32, 18 April 2020 (UTC)
 * Support "User logs" for increased clarity and the parallel with "User contributions". the wub "?!"  21:21, 18 April 2020 (UTC)
 * Agree with Wub, "User log" is better; I'm either way on the s. I do this myself, actually. ~  Amory <small style="color:#555"> (u • t • c) 10:15, 20 April 2020 (UTC)
 * Support User logs a clearer label that is consistent with "User contributions". – Teratix ₵ 01:58, 21 April 2020 (UTC)
 * Support "User logs"" for consistency with "User contributions" per Teratix. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Oppose per Levivich. Chris Troutman  ( talk ) 13:57, 27 April 2020 (UTC)
 * Support "User logs", conditional to related proposal. Logs is highly ambiguous in this context. However, if passes, then it should be just "Logs". --MarioGom (talk) 19:14, 27 April 2020 (UTC)
 * Oppose we know the logs have actions, and there doesn't need to be two words when we can have one.  Crazy Boy  826  16:10, 3 June 2020 (UTC)

Languages → In other languages
To mirror "In other projects" section.
 * Support as proposer. Renata (talk) 04:46, 14 April 2020 (UTC)
 * Support. This is a much clearer title. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 07:46, 14 April 2020 (UTC)
 * Support. This makes it clearer that the other languages links go to the same page in other languages, not just the home page for those languages. &#123;{u&#124; Sdkb  }&#125;  talk 04:46, 15 April 2020 (UTC)
 * Oppose, labels should be as concise as possible; I'm not sure this is actually confusing to many readers. – Teratix ₵ 14:07, 18 April 2020 (UTC)
 * Support for consistency. --Yair rand (talk) 17:28, 19 April 2020 (UTC)
 * Oppose (strongly). I agree entirely with Teratrix. And there's nothing confusing about the language switcher. Daveout (talk) 12:44, 22 April 2020 (UTC)
 * Weak oppose as I don't see the problem with plain "Languages" but I understand the desire for consistency. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Support--YTRK (talk) 13:28, 27 April 2020 (UTC)
 * Weak oppose - I like the consistency between "In other languages" and "In other projects", but I think "Languages" is clear already and concise. --MarioGom (talk) 19:18, 27 April 2020 (UTC)
 * Support - Yes, I know anecdotal evidence is flawed, but I know of people who didn't know exactly what these links do. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)
 * Oppose, we want SHORT LABELS not verbose ones. This is going in the wrong direction. Chiswick Chap (talk) 13:31, 3 May 2020 (UTC)

User rights management → Manage user rights
Shorter and starts with an action verb like every other user-related link (e.g. "email user" or "block user"). Renata (talk) 05:20, 14 April 2020 (UTC)
 * Support as proposer. Renata (talk) 05:20, 14 April 2020 (UTC)
 * Support If I had a dollar for every time I clicked "User contributions" instead of "User rights management" I could run the servers for an hour. — Wug·a·po·des​ 21:15, 14 April 2020 (UTC)
 * Support - clarity improved, no observable negatives Nosebagbear (talk) 12:37, 15 April 2020 (UTC)
 * Note: This wording is only shown to administrators. Others see "View user groups" in the same place. Thus, "Manage user groups" would be more consistent than "Manage user rights". Technically, we're not assigning rights (Special:ListGroupRights); we're assigning groups. ~ ToBeFree (talk) 13:49, 15 April 2020 (UTC)
 * And the local title of the page we land on for clicking it is.... User groups management. So let's use "groups" in there. —  xaosflux  Talk 14:37, 15 April 2020 (UTC)
 * Don’t really see a reason to change this. No real positives. No real negatives either. People might be confused though. I’m not typically a fan of changing things people use without a good reason. Neutral but don’t see the point. TonyBallioni (talk) 02:30, 17 April 2020 (UTC)
 * Support per proposer and Wugapodes. – Teratix ₵ 14:26, 18 April 2020 (UTC)
 * Support "Change user groups" which is actually the MediaWiki default now, and would make us consistent with other sites. "Groups" is technically more correct than "rights" as has been pointed out. Second preference support for "Manage user groups". the wub "?!"  21:32, 18 April 2020 (UTC)
 * Support "Change user groups" first, "Manage user groups" second and "Manage user rights" third (and oppose the current "User rights management"). — Bilorv ( talk ) 22:13, 18 April 2020 (UTC)
 * Kind of agree with Tony here — not broken, etc. I'd actually prefer changing both this and the header on the page to just User rights (default for the page itself): the page is useful beyond just changing user rights, it shows the rights themselves and the log. ~  Amory <small style="color:#555"> (u • t • c) 10:19, 20 April 2020 (UTC)
 * actually it doesn't the show the rights at all, it shows the groups :) The "rights" are listed at Special:ListGroupRights. —  xaosflux  Talk 14:03, 20 April 2020 (UTC)
 * I think it's clear we're being colloquial, at least until everyone comes around to my "say sysop instead of admin" position. ~ Amory <small style="color:#555"> (u • t • c) 16:07, 20 April 2020 (UTC)
 * Support for consistency.  13:14, 20 April 2020 (UTC)
 * I think I'd like this to just say "User groups" - for most users (non-admins) it just SHOWS the user groups, for other it shows them and allows you to change them. — xaosflux  Talk 14:05, 20 April 2020 (UTC)
 * Support I was the one who changed this in core MediaWiki several years ago (see The wub's comment) and I cannot see any good reason why the old name should be preserved on this site. This, that and the other (talk) 01:26, 25 April 2020 (UTC)
 * Support "Change user groups" for admins and "User groups" for non-admins, or as a second option just "User groups". As this page allows you to add or remove a user from user groups if you are an admin, or allows you to see the groups a user is in it is better to use "groups" instead of "rights" to clarify the purpose of the page. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 21:53, 26 April 2020 (UTC)
 * Support for consistency. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Support - More consistent and unique, as others have said. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)
 * Support, it's a small improvement. Chiswick Chap (talk) 13:32, 3 May 2020 (UTC)

Tools section → ???
We have a few options for renaming the tools section to help makes its purpose clearer and reduce confusion. "Editor tools" (from and ) would make it clearer to casual readers that they can ignore this section. "Editing tools" would be similar, and perhaps a little better at breaking down the editor/reader barrier. "Page tools" (from ) would help make it clear that the section is for page-specific tools. What do you all prefer? &#123;{u&#124; Sdkb  }&#125;  talk 07:56, 15 April 2020 (UTC)Refactored 23:05, 15 April 2020 (UTC)
 * Support any over status quo, with a weak preference for "editing tools". &#123;{u&#124; Sdkb  }&#125;  talk 07:56, 15 April 2020 (UTC)
 * Support. "Editor tools" was my suggestion initially. I would prefer "Editing tools", though I'm fine with either. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 08:25, 15 April 2020 (UTC)
 * Oops, sorry, I overlooked the discussion section where you made that proposal. I've refactored above. &#123;{u&#124; Sdkb  }&#125;  talk 23:05, 15 April 2020 (UTC)
 * Support, "editing tools" first choice, "editor tools" second. Renata (talk) 19:47, 18 April 2020 (UTC)
 * Oppose. There's nothing that makes these tools exclusive to editing or editors. I think renaming the section would actually reinforce the "reader/editor barrier". the wub "?!"  21:39, 18 April 2020 (UTC)
 * Support page tools, and maintaining a separation between page-specific and site-wide tools. Though this would mean putting Upload file and Special Pages into a small section of their own ("Wiki Tools"?), and "heading overload" could be a valid objection.  I note that Timeless has separate drop-downs for the two.  Oppose editing tools because some items such as What links here and Permanent link are useful for other tasks, not just editing.  Oppose editor tools because of the previous reason, and because we shouldn't be sending a message that there is a divide between editors and readers.  (After writing this, I realised that my oppose reasons are pretty much identical to those put forward by the wub. The ideas weren't that well-formed in my head until I actually wrote them out.)  I think people will ignore the "Tools" section if it's not relevant to their purpose, regardless of what it's called.  Pelagic (talk) 21:16, 22 April 2020 (UTC)
 * Sorry to keep mentioning Timeless, but as a some-times user of that skin and an often user of mobile, those experiences do influence my perspective on different design approaches. Pelagic (talk) 21:16, 22 April 2020 (UTC)
 * Oppose. There is nothing cofusing about the Tools header and I can't imagine much confusion arises from it. Given the other motions to reorder the menu the negative impact of a more concise heading would be pretty limited. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Support either "editing tools" or "page tools", prefer former on condition that tools not specific to editing is reordered. (Also, shouldn't the title of this section be "Tools → ???"?)--YTRK (talk) 13:28, 27 April 2020 (UTC)

Print/export → Export
Renaming makes the section header more concise and removes the ugly slash, while retaining the key information (these tools can be used to generate an external copy of the page). There is still a clear link to a "printable version", avoiding any reader confusion.
 * Support as proposer. – Teratix ₵ 14:24, 18 April 2020 (UTC)
 * Looks like people are misunderstanding your proposal. they seem to think that you're trying to remove the "print" option instead of renaming the section header 🤷. Daveout (talk) 22:53, 22 April 2020 (UTC)
 * Neutral, agree on "ugliness" of the slash, but also find "print" a lot clearer and informative than just "export". Renata (talk) 19:22, 18 April 2020 (UTC)
 * Neutral per Renata. Something to keep in mind is that many of the readers who want to print articles may not be the most technologically savvy, so they may need more cues. &#123;{u&#124; Sdkb  }&#125;  talk 21:52, 18 April 2020 (UTC)
 * Oppose: Welcome to 2020 where we are in the middle of a pandemic. Meanwhile in technology, users on the English Wikipedia are arguing over if printing and exporting are the same. Really they are. You can "digitally print" with PDF, or save to Google Drive. It's the same thing! But just leave it alone! &#123;&#123;replyto&#125;&#125; Can I Log In's (talk) page
 * I understand the sentiment, but here's another way to frame it: we're making a change that'll be reflected on every page of a website that gets about 10 billion pageviews a month. Even very minor changes become consequential and worth discussing when you multiply them by 10 billion. &#123;{u&#124; Sdkb  }&#125;  talk 02:02, 20 April 2020 (UTC)
 * This doesn't really say much other than showing me some pretty cool stats. That cool I love stats! Where's the stats for printing and exporting? Show me that it's disproportionate in favor of exporting and I'll change my !vote to support. &#123;&#123;replyto&#125;&#125; Can I Log In's (talk) page 03:14, 20 April 2020 (UTC)
 * I'm a bit confused by your comments; you've acknowledged printing and exporting are very similar functions, suggesting the dual header is unnecessary, yet you are opposing. – Teratix ₵ 03:32, 20 April 2020 (UTC)
 * Oppose for possible usability/readability issues. "Export" reads to me as a digital/computer term. I don't have any usability research on this, but I assume people with less digital or computer literacy understand the word "Print" better than "Export". (Less importantly, print and export also mean two different things, and the section includes both: directly printing the page, or exporting it as a PDF.) - Whisperjanes (talk) 15:08, 20 April 2020 (UTC)
 * Although I would support it being changed to "Print or export" as suggested by KarasuGamma below, if others think that looks better. - Whisperjanes (talk) 06:24, 19 May 2020 (UTC)
 * Oppose. "Export" will be meaningless to less tech-savvy users. Support "Print or export". CJK09 (talk) 04:58, 22 April 2020 (UTC) I misunderstood the proposal. Striking my vote. CJK09 (talk) 01:51, 23 April 2020 (UTC)
 * Support (strongly). per Proposer's rationale. You don't have to be a technology expert to know what "export" means. It will make the sidebar visually cleaner indeed. Daveout (talk) 12:12, 22 April 2020 (UTC)
 * It's not about being an expert. The set of people who know what a "print" button will do is larger than the set of people who know what an "export" button will do. Therefore, it should contain "print" in its text. CJK09 (talk) 21:56, 22 April 2020 (UTC)  CJK09 (talk) 01:51, 23 April 2020 (UTC)
 * There will be no button called "export". It's just a section header, right under it the user will see two self-explanatory options: "print" and "download pdf". it can't get any clearer than that. "Export" is a broader term that comprises both print and download. Daveout (talk) 22:19, 22 April 2020 (UTC)
 * Support "Print or export". <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 21:07, 22 April 2020 (UTC)
 * Just a general reply to opposers; even if this proposal went through, there would still be a clear and obvious link to a "printable version", so it seems highly unlikely even technologically challenged readers are going to be confused about where to find the print function. – Teratix ₵ 01:07, 23 April 2020 (UTC)
 * Support to increase usability. Wouldn't have a major impact but removing the slash and unnecessary words would streamline the menu. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Oppose There are still a lot of people who may not really know what "export" means. From a user perspective "print" > "export". --Enos733 (talk) 03:48, 27 April 2020 (UTC)
 * Weak oppose: "Print/Export" is a really poor heading for a section with two items: "Download" and "Print". A lot of people has no clue about what "export" is. Still, "print" is online one line away, so it probably does not matter much. --MarioGom (talk) 19:36, 27 April 2020 (UTC)

Mute preferences → Mute this user
Huh? I keep thinking this has something to do with my or that user's preferences that they set in Special:Preferences. This is really trying to mute a user, not preferences.


 * Support as proposer. Renata (talk) 08:25, 21 April 2020 (UTC)
 * Support: Per the proposal reasoning. &#123;&#123;replyto&#125;&#125; Can I Log In 's  (talk) page 00:50, 23 April 2020 (UTC)
 * Issue: The text would stay the same even if the target was already muted. "Mute/unmute this user" would be more accurate, but unwieldy. I'm unsure whether "mute this user" would be a positive change. --Yair rand (talk) 16:57, 23 April 2020 (UTC)
 * The premise of this proposal is flawed. The text means this is a link to preferences about Mute feature, not a way of "muting preferences" themselves as the proposer incorrectly assumed. The link can also be used to unmute user, therefore the proposed name is not quite accurate. "Mute preferences" is more appropriate as it shows you're clearly going to a certain preference page to activate some settings which include, muting and unmuting of mention and email. These are four different settings and so using the proposed "Mute user" to represent them is inadequate.  "Mute/unmute this user" is what can serve as a possible name, but in comparison to current "Mute preferences", it can be easily dismissed as a cosmetic change that's no benefit. – Ammarpad (talk) 13:58, 24 April 2020 (UTC)
 * I am undecided about this proposal but recommend that "user" be changed to "editor" as that is the terminology used throughout most of the project. (I also acknowledge that this is inconsistent in some areas with "user" appearing to be used more often in more technical areas e.g., user rights.)ElKevbo (talk) 19:25, 26 April 2020 (UTC)
 * Support for clarity, I have also experienced this confusion. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Support for clarification. <b style="color:#090">Semi</b><i style="color:#099">Hyper</i><u style="color:#009">cube 13:54, 27 April 2020 (UTC)
 * Support but prefer "Mute user" as more consise. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)

Printable version → Print
When you click this link, it simply leads you to the operating system's or the browser's print page dialog. Also for simplicity and popularity (many web pages, including encyclopedia britannica, have a simple "print" option, and often just a printer icon).


 * Support as proposer. Daveout (talk) 12:36, 22 April 2020 (UTC)
 * Conditional support See comment just below on the assumption that this is the functionality in all browsers/operating systems. Thanks for following up and making this a proposal. &#123;{u&#124; Sdkb  }&#125;  talk 18:07, 22 April 2020 (UTC)
 * Clicking on that link has the same effect as pressing Ctrl+P on: Opera, Firefox, Chrome and Edge. Daveout (talk) 18:56, 22 April 2020 (UTC)


 * Comment On second thought, I'm not sure between "Print" and "Print this page". The latter would be more consistent with "Cite this page" (which imo is probably appropriately named), but the former would be more consistent with "Download as PDF", which is not (and shouldn't be) titled "Download this page as PDF". I lean a little toward "Print this page", since the demographic doing most of the printing needs a little extra help, and "this page" adds a bit of clarity. &#123;{u&#124; Sdkb  }&#125;  talk 19:51, 22 April 2020 (UTC)
 *  Oppose Split : It's literally what it says. It's a printable version of the page. It's not going to give you a print preview and a printing dialogue. It does two things. If you open it in a new tab, it will literally show the printable version. But, if you primarily click on it, it does print. &#123;&#123;replyto&#125;&#125; Can I Log In 's  (talk) page 01:24, 23 April 2020 (UTC); edited 02:38, 23 April 2020 (UTC)
 * Which browser are you using? Everyone here so far reported the opening of a print dialog. Daveout (talk) 02:23, 23 April 2020 (UTC)
 * Derp. I did middle click, not primary click. Now we have something new to consider. Do we want to see the printable version or just print? &#123;&#123;replyto&#125;&#125; Can I Log In 's  (talk) page 02:38, 23 April 2020 (UTC)
 * Why would anyone like to se a "printable version" of a page if not to... you know... print it? Daveout (talk) 02:44, 23 April 2020 (UTC)
 * Support. Menu should be concise and "Print" is exactly the function of the link. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Remove altogether? most websites do fine with printing handled by the browser menu. And use of printing is declining, even if your computer won't be handy to read a Wikipedia page your smartphone probably will be. Blythwood (talk) 14:45, 27 April 2020 (UTC)
 * You're absolutely correct. People should be encouraged to use (or learn how to use) the browser's print functionality. This feature is very easily accessible and intuitive in every browser. And it can be useful for any site, not only wikipedia. However, most ppl here object the removal of the in-site link. We could at least make it less bizzare, calling it just "print" instead of "printable version" Daveout (talk) 17:21, 27 April 2020 (UTC)
 * Support. More concise and equally descriptive. Most people won't care about the small technical difference. --MarioGom (talk) 19:34, 27 April 2020 (UTC)

Download as PDF → Save as PDF
It simply sounds and looks nicer.
 * Also, some have raised concerns about the use of technological jargon (which may be intimidating for the elderly, for example). In that case, the word "download" may be triggering for those who are less familiar with the whole computer\internet scene.


 * Support as proposer. Daveout (talk) 12:36, 22 April 2020 (UTC)
 * Weak oppose. It's a little difficult trying to place ourselves in the shoes of non-tech savvy users, but I think "download" is pretty widely understood. My concern with "save" is that, especially for someone who doesn't know what a PDF is, it might sound like it just adds it to some on-wiki collection (like how the save button on YouTube adds a video to your "watch later" playlist) rather than generating a file for your computer. &#123;{u&#124; Sdkb  }&#125;  talk 18:12, 22 April 2020 (UTC)
 * Oppose: I think this is more for downloading a page's HTML rather than a PDF. &#123;&#123;replyto&#125;&#125; Can I Log In 's  (talk) page 00:46, 23 April 2020 (UTC)
 * You thought wrong. It's for downloading an actual PDF file (as the link clearly says). Daveout (talk) 02:31, 23 April 2020 (UTC)
 * When I talked about downloading HTML, I meant that if you right click while not selecting anything, click on save as, you save an HTML, not a PDF. &#123;&#123;replyto&#125;&#125; Can I Log In 's  (talk) page 02:36, 23 April 2020 (UTC)
 * Lol. do you even know how to properly use a link? Daveout (talk) 02:48, 23 April 2020 (UTC)
 * That's because you're not actually clicking the link. "Save as" is a browser function that downloads the HTML, if you actually left-click the link you'll get a PDF copy. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Support. The link should reflect its function. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Oppose, download is clear and widely understood. Chiswick Chap (talk) 13:35, 3 May 2020 (UTC)
 * Oppose. "Download" unambiguously refers to saving a file on the computer/device, while "Save" does not specify where the file will be located. —  Newslinger  talk   09:33, 11 May 2020 (UTC)

Additions
This area is for proposals to add new links to the sidebar not present in the current version. When adding a new one, please specify the label you would like for the link to have, the location you would like it to have, and the tooltip you would like to display when a reader hovers their cursor over it.

An introduction to contributing page
Attracting new contributors is of the utmost importance to the project. I therefore propose the addition of a link going to an introductory page. Personally, I believe this should be Help:Introduction, the gateway to our recently revamped tutorial set that has been made the primary button in our new standard welcome message, but other possibilities could be Help:Introduction to Wikipedia (the first module of the tutorial set), WP:Contributing to Wikipedia (a single-page intro), or Help:Getting started (which links to tons of different intros). I would prefer the location directly beneath "Help", with the label "Tutorial" "Editing tutorial"Changed 14:47, 29 April 2020 (UTC) per below and the tooltip "Learn how to edit Wikipedia".

Survey (Introduction)

 * Support Help:Introduction as proposer, with Help:Introduction to Wikipedia as second choice. &#123;{u&#124; Sdkb  }&#125;  talk 21:46, 10 April 2020 (UTC)
 * Support WP:Contributing to Wikipedia..should not link pages that don't work for those with no mouse or screen readers or TV boxes or mobile view concerns and will take an hour to go over. This would be the opposite of our kiss principle.. that seems to be applied everywhere else on this page.-- Moxy 🍁 22:04, 10 April 2020 (UTC)
 * Support absolutely and 100%. A great idea and a clear way for new editors to start editing --Tom (LT) (talk) 00:13, 11 April 2020 (UTC)
 * Support an introduction page. No opinion on which one to use. Interstellarity (talk) 00:25, 11 April 2020 (UTC)
 * Support WP:Contributing to Wikipedia; oppose anything that is not accessible by screen readers or those without mouses per Moxy. — Wug·a·po·des​ 00:26, 11 April 2020 (UTC)
 * Moxy recently brought Help:Introduction to WikiProject Accessibility for review. No one else there seems to be having any issues with it that would make it less accessible than a normal page. Further discussion about this should probably be centralized there, not here. &#123;{u&#124; Sdkb  }&#125;  talk 00:36, 11 April 2020 (UTC)
 * Perhaps it's better phrased as: I support any that are accessible. Whatever set that is, I'm in support of that one. — Wug·a·po·des​ 03:18, 11 April 2020 (UTC)
 * Help:Introduction.... 60 plus pages to click through is definitely not user friendly - even worst then collapsed content because you needs to load.every page. click -load..-click -load.click -load.etc...60 more times.-- Moxy 🍁 06:01, 11 April 2020 (UTC)


 * Support addition of one of the proposed pages. SD0001 (talk) 04:22, 11 April 2020 (UTC)
 * Support. MER-C 09:52, 11 April 2020 (UTC)
 * Support, very good idea to have an accessible link to an editing tutorial. --Yair rand (talk) 20:36, 12 April 2020 (UTC)
 * Support no brainer. <b style="color: White">b</b><b style="color: White">uidh</b><b style="color: White">e</b> 23:41, 12 April 2020 (UTC)
 * Support Absolutely, we need all the help we can get to include more new editors. CaptainEek  Edits Ho Cap'n!⚓ 22:05, 17 April 2020 (UTC)
 * Support The Wikipedia Adventure as first choice and Help:Introduction as second choice, and oppose the other suggestions. I'm afraid I don't think the accessibility concerns in this case outweigh the concerns I have that Contributing to Wikipedia is useless, and readers would leave within 0.5 seconds of opening the page. Help:Introduction isn't great, but it is at least immediately obvious to sighted readers what the page is about and what they can do next. The Wikipedia Adventure is an excellent resource, a large part of the reason I'm an editor today and one of the few links that would actually get interested readers feeling like they're contributing or learning something immediately, rather than sending them on an endless path of writings about our policies. I don't know how accessible it is, but even if it isn't then it's still useful to some group of people at least. — Bilorv ( talk ) 18:41, 18 April 2020 (UTC)
 * Really wish choice of help pages was based on editor retention and accessibility. The idea of the |Wikipedia:TWA/1/Start|Wikipedia:TWA/2/Start|Wikipedia:TWA/3/Start Wikipedia:Adventure that has a 50 percent drop in views by the second page....with a loss of 90 percent by page 3 simply a bad idea.  I can see why the adventure  is visually appealing but  according to data on  how users navigate it's a bad choice. -- Moxy 🍁 22:30, 18 April 2020 (UTC)


 * Support Help:Introduction per Sdkb and the recent decision to make it the main introduction linked in the welcome template. Contributing to Wikipedia is a huge wall of text which is far too daunting for newbies. The Wikipedia Adventure is nice, but per its talk page is "only semi-actively maintained" and doesn't cover or work with the VisualEditor at all. the wub  "?!"  21:53, 18 April 2020 (UTC)
 * 66 pages vs one with a TOC is less daunting? O well...perhaps best the new generation learn for themselves what works and doesn't work.-- Moxy 🍁 22:30, 18 April 2020 (UTC)


 * Support a link to some kind of introduction. Neutral on which one, however, it should be accessible and clear. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 22:01, 26 April 2020 (UTC)
 * Support per nominator. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Oppose We have too many new users already, many of whom are blocked within days of starting. Chris Troutman  ( talk ) 13:59, 27 April 2020 (UTC)
 * The majority of new editors want to help Wikipedia become the best encyclopedia it can possibly be. Although many new editors get blocked, you are forgetting about the new editors that want to contribute here positively and want to know where to start. Interstellarity (talk) 14:43, 1 May 2020 (UTC)
 * The majority of new editors are partisans, cranks, and crazies who want Wikipedia to represent their own views. The new editors that make useful contributions figure it out for themselves without our endless efforts to explain how. You imagine influencing editors that don't exist. If you can't figure Wikipedia out for yourself, you probably don't have a future here, anyway. Chris Troutman  ( talk ) 15:17, 1 May 2020 (UTC)
 * Support WP:Introduction sounds good. --MarioGom (talk) 21:01, 27 April 2020 (UTC)
 * Sure you want to link a giant tuorial that is losing us thousands of editors? Should have a separate talk for this link with those familiar with how to retain and gain editors

|Help:Introduction_to_referencing_with_Wiki_Markup/2|Help:Introduction_to_referencing_with_Wiki_Markup/3|Help:Introduction_to_referencing_with_Wiki_Markup/4|Help:Introduction_to_referencing_with_Wiki_Markup/5 page view stats showing the loss of interest editor's  by thousands. -- Moxy 🍁 18:05, 8 May 2020 (UTC)
 * Support - If most people wanted to become a "Wikipedia editor", (as opposed to editing a stray mistake), they wouldn't know where to start. The name of the link should make its primary goal (editing) clear though - perhaps "Editing introduction"? - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)
 * good point about the name; we don't want it to seem like it's a tutorial on how to read Wikipedia. I'm going to change my proposal to "Editing tutorial". &#123;{u&#124; Sdkb  }&#125;  talk 14:47, 29 April 2020 (UTC)
 * Support, with Help:Introduction as first choice. I'm not concerned about the drop-offs in the pageview statistics; based on what I see on social media, readers often only look at the lead section of articles, and I expect very few people to complete the tutorial in Help:Introduction or read most of Contributing to Wikipedia. The 1% rule of Internet culture applies to Wikipedia as it does to any other site, but we should still make sure that the 1% of readers who become editors have easy access to information that helps them make contributions. Help:Introduction presents the information in the most approachable form for most readers, and other guides are linked at the bottom under "For more training information, see also:". —  Newslinger  talk   09:48, 11 May 2020 (UTC)
 * On accessibility, I think it would be helpful to have a note in Help:Introduction explaining which of the resources under "For more training information, see also:" are compatible with screen readers. —  Newslinger  talk   04:59, 13 May 2020 (UTC)
 * Support with something like Village_pump_(proposals)/Archive_160 in mind. &#32; Headbomb {t · c · p · b} 17:31, 12 May 2020 (UTC)

Discussion (Introduction)

 * Is the idea that this would go away for "experienced" users? Not sure how feasible that is, and without that I'd certainly oppose adding a new, useless link for experienced folks. ~  Amory <small style="color:#555"> (u • t • c) 10:22, 20 April 2020 (UTC)
 * We need a helpful, accessible, readable, community-backed tutorial before this proposal is implemented. – Teratix ₵ 02:02, 21 April 2020 (UTC)
 * I am working on a new page that actually follows Help Project/Guidelines. Disheartening to see us going down a path that doesn't follow our basics. Wonderful to see new editors involved in the help page system..but some choices as of late have been detrimental.-- Moxy 🍁 03:10, 21 April 2020 (UTC)
 * I think the general view is that Help:Introduction is all of those things, Moxy's lone dissension notwithstanding. If you haven't explored it before/recently, I'd encourage you to check it out. I'm interested to see what you create. Is there a reason you're working on a new page rather than making/suggesting edits to an existing one? &#123;{u&#124;  Sdkb  }&#125;  talk 04:47, 21 April 2020 (UTC)
 * Your view of what is good for accessibility is based on what you like....not the raw data or the experience of longtime editors or are guidelines. As for making a new page....best to start from scratch..-- Moxy 🍁 05:13, 21 April 2020 (UTC)
 * My view is based on the feedback we received when you brought the page to WikiProject Accessibility. &#123;{u&#124; Sdkb  }&#125;  talk 06:03, 21 April 2020 (UTC)
 * Perhaps best review gudlines project page you just joined Help Project/Guidelines....telling someone to collapse every section and removal of a TOC leads me to believe you have not see the projects recommendations. It would save us |Help:Introduction_to_referencing_with_Wiki_Markup/2|Help:Introduction_to_referencing_with_Wiki_Markup/3|Help:Introduction_to_referencing_with_Wiki_Markup/4|Help:Introduction_to_referencing_with_Wiki_Markup/5 loss the interest of thousands of potential editors - Moxy 🍁 06:16, 21 April 2020 (UTC)

An FAQ page
Many websites have an FAQ page. I think this website should have one as well.

Survey (FAQ)

 * Support as proposer. Interstellarity (talk) 00:30, 11 April 2020 (UTC)
 * Oppose. There's only room for one help page and one about page, and those are Help:Contents and Wikipedia:About, respectively. (I'm also not convinced that FAQs are a useful format for those with questions, and the FAQ system needs a massive revamp anyways.) &#123;{u&#124; Sdkb  }&#125;  talk 00:44, 11 April 2020 (UTC)
 * Oppose. One "help" link is perfect, and it does link to the "Readers' FAQ" pretty prominently. Users should not have to choose the type of help page in advance. ~ ToBeFree (talk) 03:27, 12 April 2020 (UTC)
 * Oppose Don't see the need; feels redudant to the help and about pages. ~ riley  ( talk  ) 08:01, 12 April 2020 (UTC)
 * Oppose: not clear what the FAQ would contain and how it would aid readers. — Bilorv ( talk ) 18:34, 18 April 2020 (UTC)
 * Oppose. We already have several FAQs but I don't think they need a link in the sidebar since this is better covered under "Help" and "About Wikipedia". the wub "?!"  21:55, 18 April 2020 (UTC)
 * Oppose Help and About Wikipedia links are sufficient. – Teratix ₵ 02:03, 21 April 2020 (UTC)
 * OpposeAlready many places to get answers to questions. J cool bro   (talk) 20:48, 23 April 2020 (UTC)
 * Oppose, there's enough introductions as it is. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Oppose to decide including it first, if this would be useful, I would create a FAQ first. If the community thinks it useful, then we could discuss adding it to the sidebar. --MarioGom (talk) 21:02, 27 April 2020 (UTC)
 * Oppose - Just because others do it doesn't mean we should. Everyone already knows about Wikipedia, and the introduction link proposed above can fill them in on specifics. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)

A dashboard
I think this link would be helpful to people so people can see what's going on behind the scenes with Wikipedia.

Survey (Dashboard)

 * Support as proposer. Interstellarity (talk) 00:32, 11 April 2020 (UTC)
 * Oppose. This already exists on the sidebar as the Community portal. &#123;{u&#124; Sdkb  }&#125;  talk 00:45, 11 April 2020 (UTC)
 * What's the difference between the community portal and the dashboard? Why is the community portal a better choice for the sidebar? Interstellarity (talk) 00:52, 11 April 2020 (UTC)
 * as with many pages in the WP space, there's an uncomfortable degree of overlap. But here's the difference as I see it: the Community portal is explicitly designed as the landing page for regular editors. It includes a listing of discussions/requests, but also provides articles needing help, news, community announcements, etc. The Dashboard, by contrast, is focused solely on listing discussions/requests. &#123;{u&#124; Sdkb  }&#125;  talk 01:01, 11 April 2020 (UTC)
 * Oppose: Redundant to the community portal. ~ ToBeFree (talk) 03:30, 12 April 2020 (UTC)
 * Oppose: Redundant per TBF. ~ riley  ( talk  ) 08:02, 12 April 2020 (UTC)
 * Oppose. Unnecessary. --Yair rand (talk) 20:36, 12 April 2020 (UTC)
 * Oppose as redundant to the Community portal link. Honestly I wouldn't be opposed to a revamp and/or rename of the Community portal, I'm not sure that name is at all clear to newbies, but that's a different discussion. the wub "?!"  21:58, 18 April 2020 (UTC)
 * Oppose too much overlap with Community portal. – Teratix ₵ 02:04, 21 April 2020 (UTC)
 * Oppose as I cannot see what function this would perform or any community value added. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Oppose - If the community portal does not fulfill that purpose, it can be changed. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)

Logs
The logged actions of any page are important for any page, so linking Special:Log with parameter  in the sidebar would save time, especially for users with slow internet connection. The existing "Logs" tab for users should be renamed to "logged actions", or else this one can be called something like "Page logs". It should be located under the "Tools" header after either "Related changes" or "Page information", with the tooltip "A list of logged actions at this page, excluding edits".

Survey (Logs)

 * Support as proposer. –<b style="color:#77b">Laundry</b><b style="color:#fb0">Pizza</b><b style="color:#b00">03</b> ( d c̄ ) 00:37, 11 April 2020 (UTC)
 * Support a convenient link to page log. Very useful for experienced editors. --- C &amp; C (Coffeeandcrumbs) 01:07, 11 April 2020 (UTC)
 * Oppose There's already a link to the logs for a given page in that page's history. The logged actions for a page are part of that page's history, so this is unnecessary. * Pppery * <sub style="color:#800000">it has begun... 01:26, 11 April 2020 (UTC)
 * Support this should probably go in the Tools section. SD0001 (talk) 04:23, 11 April 2020 (UTC)
 * Support. MER-C 10:00, 11 April 2020 (UTC)
 * Oppose per Pppery. Also, the proposal is meant to remove clutter from the sidebar, and only a few experienced users use these logs directly. On protected pages, a link to the protection log is provided to editors in the error message already. A link to the unspecific action log is completely meaningless to most readers; the log is pretty empty for most pages. ~ ToBeFree (talk) 03:20, 12 April 2020 (UTC)
 * Oppose per Pppery and ToBeFree, especially echoing the fact that not many pages have substantive log histories, with an average of maybe 2-3 entries per page. While trying to keep things simple for the average reader, I believe that this would be an addition that would not be of much benefit to most people, and its few uses are not the most important to have on the side bar. Utopes (talk / cont) 22:15, 14 April 2020 (UTC)
 * Oppose: more clutter for something only commonly used by experienced editors who already know how to navigate to the logs. I sympathise with the slow internet connection concerns but that's just not enough reason. Someone must be able to write a user script that can add the link (I know my "Tools" sidebar has a load of user script stuff in it). — Bilorv ( talk ) 22:08, 18 April 2020 (UTC)
 * Oppose we need fewer, not more, of these links for experienced editors in the sidebar, which should ultimately be focused on readers' needs. – Teratix ₵ 02:07, 21 April 2020 (UTC)
 * Oppose as the logs are easily accessible and relatively unused by the vast majority of readers and editors. I imagine there's a user script for this anyway. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)

Discussion (Logs)

 * Simply linking to Special:Log isn't going to be very useful for people here, this would need to at the least incorporate the &page= parameter and reference the current page to be useful, and if so we should probably title it something like "Page logs". — xaosflux  Talk 02:09, 11 April 2020 (UTC)
 * Agreed with . since this is getting some support, can you flesh out your proposal a bit per the instructions at the top of the additions section? &#123;{u&#124;  Sdkb  }&#125;  talk 17:54, 11 April 2020 (UTC)
 * ✅. –<b style="color:#77b">Laundry</b><b style="color:#fb0">Pizza</b><b style="color:#b00">03</b> ( d c̄ ) 03:28, 13 April 2020 (UTC)
 * Unless I'm missing something, you clarified only the link. Please read the instructions at the top of the additions section. &#123;{u&#124; Sdkb  }&#125;  talk 19:12, 13 April 2020 (UTC)
 * ✅ –<b style="color:#77b">Laundry</b><b style="color:#fb0">Pizza</b><b style="color:#b00">03</b> ( d c̄ ) 02:33, 17 April 2020 (UTC)

Deleted contributions
For admins only and in the user namespace, add a link to the user's deleted contributions under tools. I find the omission of this to be somewhat annoying.

Survey (Deleted contributions)

 * Support as proposer. MER-C 09:06, 11 April 2020 (UTC)
 * the very top line of Special:Contributions/MER-C as the links for suppressed and deleted contributions already - do you use those? — xaosflux  Talk 11:08, 11 April 2020 (UTC)
 * Yes, but I'd like to save a click. MER-C 11:17, 11 April 2020 (UTC)
 * Weak oppose - technically redundant per Xaosflux as the contributions page proper already has a link to deleted contribs for admins to use. It just seems to me this would just be a change based on personal preference. However, I'd be willing to support if the actual admins would like such a shortcut. Kirbanzo (userpage - talk - contribs) 21:45, 12 April 2020 (UTC)
 * oppose Unnecessary--it's already on hte user page header, which is a perfectly logical place for it. The sidebar should be kept relatively uncluttered, and this can be done  without loss of function by avoiding duplication.  DGG ( talk ) 00:30, 14 April 2020 (UTC)
 * Oppose feels like clutter to have this on the sidebar for every user page. However it might make a good userscript or gadget if this is something particular users want faster access to. the wub "?!"  22:01, 18 April 2020 (UTC)
 * , It's in pop-ups, which I find super helpful. ~ Amory <small style="color:#555"> (u • t • c) 10:24, 20 April 2020 (UTC)

Search page
Add link to the Search page in the main section -- it has all the ways to browse for content, but does not have search. I recently read somewhere (can't find where now) that many readers don't realize Wikipedia has a search function and rely on Google to find info and articles. Gripes about the quality of our search aside, we should be promoting searching within the project.

Survey (Search page)

 * Support as proposer. Renata (talk) 04:20, 14 April 2020 (UTC)
 * Oppose. There is already a search bar in the top right which is very widely used. Why have a link to Special:Search again in the sidebar? Besides, having a link to search, in my opinion, is quite useless as opposed to a search bar. I do know searching through Special:Search instead of through the search bar gives you more options, but if we want to encourage use of Special:Search we could just have a link at the bottom of the search results (like the current one saying 'containing...') that says 'Advanced search' GoodCrossing (talk) 12:29, 14 April 2020 (UTC)
 * Oppose as redundant since we already have a search bar in the top right. Also, if you really want another obvious way to search in the left sidebar, wouldn't you just put a search bar there and not a link to the search page? <b style="color:#090">Semi</b><i style="color:#099">Hyper</i><u style="color:#009">cube 12:52, 14 April 2020 (UTC)
 * Oppose as redundant to the search bar. We do not need to compete for the user's attention. Utopes (talk / cont) 22:16, 14 April 2020 (UTC)
 * Oppose, we already have a prominent search bar. – Teratix ₵ 14:30, 18 April 2020 (UTC)
 * Support as "Advanced search". Oppose as "Search". CJK09 (talk) 05:01, 22 April 2020 (UTC)
 * Oppose as we have a very clearly defined search bar. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)

Discussion (Search page)
Perhaps somewhere in ? &#123;{u&#124; Sdkb  }&#125;  talk 04:54, 15 April 2020 (UTC)

Removals
This area is for proposals to remove links in the current version of the sidebar.

Featured content
Modern readers use the search function or blue links to find the pages they are interested in, not a list of pages, as evidenced by |Wikipedia:Contents|Portal:Current_events|Help:Contents|Wikipedia:Community_portal|Special:RecentChanges|Wikipedia:About|Wikipedia:Contact_us|Wikipedia:File_Upload_Wizard|Special:SpecialPages pageview statistics. There should be (at most, and possibly less) one directory-style list of pages in the sidebar, and it should be the main one, WP:Contents. Featured content could be added as a module to the main contents page so that it remains highlighted, plus it will continue to be linked from the Main page's "Today's Featured Article" module.

Survey (Featured content)

 * Support as proposer. &#123;{u&#124; Sdkb  }&#125;  talk 21:46, 10 April 2020 (UTC)
 * Neutral I agree with the rationale above....but content editors work very hard to get those things on that page. It's contributing encouragement page and I can see some upset if it's removed.... should have a section to remove portals.-- Moxy 🍁 22:10, 10 April 2020 (UTC)
 * Oppose people should be able to browse if they want. Plus ’s logic assumes MediaWiki’s search is functional. It is not. There’s a reason the only way to navigate commons is via categories: the native search function in MediaWiki might as well not exist outside of direct matches, so unless you know the name of a redirect or the title page, you very well might not be able to get somewhere. If a reader wants to browse, let them. Lack of page views isn’t a particularly good excuse either. We should make it easy for people to be able to browse featured content as a category if they want. This harms nothing by keeping it these and is a possible benefit to readers. No case for removing has been made. TonyBallioni (talk) 23:33, 10 April 2020 (UTC)
 * Support - I partly disagree with 's reasoning. The page WP:Contents is the main way to browse Wikipedia and there's a link to it at the bottom of the page. To simplify the page, I think it should be removed so if readers want to browse Wikipedia and/or see featured content, they can click on WP:Contents and then look for the featured content at the bottom of the page. Interstellarity (talk) 23:42, 10 April 2020 (UTC)
 * That makes zero sense: why on earth would anyone look at a contents page of a 6 million article website. Also why would we want to point them there rather than to the actually good content; most of our articles aren’t that great...It also defeats the entire point of it being featured content. Featured means called out. If anything get rid of the actual contents page in it’s entirety. I’d probably not comment either way on it, but if you want to do the makework or cleaning up pages 99% of editors don’t have an opinion on, that’d be the one I’d get rid of. TonyBallioni (talk) 23:55, 10 April 2020 (UTC)
 * 100% agree. ~ Amory <small style="color:#555"> (u • t • c) 10:28, 20 April 2020 (UTC)
 * Support – per nom and Interstellarity. The sidebar should have one link for browsing, and it should be to WP:Contents. As it is now, both WP:Contents and WP:FC are linked in the sidebar, and WP:Contents gets about 33% more page views than WP:FC, so I think that's the one "browsing" link to keep. Featured content is already featured on the main page; it doesn't need a link on every page. Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 23:52, 10 April 2020 (UTC)
 * Oppose per Tony: why on earth would anyone look at a contents page of a 6 million article website. Also why would we want to point them there rather than to the actually good content. If I had to make a choice, I'd rather direct readers to our best content than WP:Contents. — Wug·a·po·des​ 00:14, 11 April 2020 (UTC)
 * I disagree with that because the purpose of the link isn't to direct readers to content that we want them to read, it's to direct readers to the content that they want to read. (And if they find that content lacking, perhaps they'll, you know, edit it.) So if someone wants a topical directory to browse all content, WP:Contents would be the only place to start. (Whereas if the reader is looking for our best content, that's already really easy to find: it's at the top-left corner of the main page.) Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 01:48, 11 April 2020 (UTC)
 * I think makes a good point regarding WP:READER. But my chief concern here isn't that we give too much emphasis to featured content — I don't think that's the case — but just that we have too many links on the sidebar and need to consolidate some. In my ideal scenario, WP:Contents gets substantially redesigned so that featured content becomes a major part of the page. (And some user research on who is visiting WP:Contents and why would be useful — something tells me it's 90% technophobic senior citizens who will switch to using the search box as soon as their grandchild shows them how.) &#123;{u&#124;  Sdkb  }&#125;  talk 04:35, 11 April 2020 (UTC)
 * I'm neutral on this proposal, but I would quite like to see such a redesign. (I have never clicked either link before this discussion.) <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 04:40, 11 April 2020 (UTC)
 * Oppose Building on TonyBallioni's point, we should be very proud of featured content and should emphasize that to the relatively few editors who do the heavy lifting in that area. Johnuniq (talk) 03:27, 11 April 2020 (UTC)
 * Oppose per TonyBallioni. Useful link for showcasing our best content. SD0001 (talk) 04:22, 11 April 2020 (UTC)
 * Support As a person interested in *Wikipedia* per se I would be interested in featured content, as a person seeking *specific information* I'm interested in the contents. Two very different purposes - pointing people who are interested in specific information to random (high quality) content seems superfluous. The question of whether Contents should be better is a different issue.--Goldsztajn (talk) 13:03, 11 April 2020 (UTC)
 * Support The link is redundant to the adjacent Contents link. The Contents page naturally has a sub-section about featured content and that seems the appropriate level for it – alongside other content classifications such as vital, popular, topical, &c.  Andrew🐉(talk) 09:32, 12 April 2020 (UTC)
 * Support and redesign WP:Content. People do not go to Wikipedia to find featured articles, they are usually looking for specific info. <b style="color: White">b</b><b style="color: White">uidh</b><b style="color: White">e</b> 23:40, 12 April 2020 (UTC)
 * Support, thought about it a lot. The page is ugly and in a way duplicates links on Main page. Also the main link section is already cluttered. Might reconsider if and when featured content page gets a redesign. Renata (talk) 19:26, 18 April 2020 (UTC)
 * Oppose. These pages (Featured content and the specific types it links to like Featured articles) could definitely use a redesign, but they are a showcase for our best work. That showcase is valuable to both readers and the editors creating them. Sometimes people do come to Wikipedia just wanting to see some of our best rather than look up something specific: the entire Main Page is built around that use case, but only spotlights a limited amount of content at any one time. Contents has its own use for browsing, but only links to featured content right at the bottom of the page. the wub "?!"  14:47, 19 April 2020 (UTC)
 * Support, people generally don't read articles because they are listed in a "featured\good articles" section, they read articles they are looking for, featured or not. One section presenting the wiki's contents is enough Daveout (talk) 05:08, 20 April 2020 (UTC)
 * Why on Earth would we not advertise the best we have to offer? I'm not particularly wild about the page itself, but a portal to the best content on the project is awesome!  Vastly more useful than linking to a random page, and I certainly wouldn't want to get rid of that. ~  Amory <small style="color:#555"> (u • t • c) 10:28, 20 April 2020 (UTC)
 * Oppose as Featured content is probably the easiest way to view high-quality pages. Contents should be removed if anything. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Oppose: casually browsing and searching something specific are very different things. I think featured context has nothing to do with search. I think it is good to be able to learn about the existence of featured context and also access it whenever you want to check out how the best articles look like, both as reader and as editor. --MarioGom (talk) 19:49, 27 April 2020 (UTC)
 * Support - I appreciate the work that goes into the featured content, but most casual readers don't even know what it is, much less browse it. Therefore it is well served being on the main page only. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)
 * Support - If any of the links in the top section should be removed, it's this one. Instead, we should direct people to featured content from the contents page. Kaldari (talk) 17:13, 30 April 2020 (UTC)
 * Support. We need to be assisting people find the content they want to read rather than the content we want them to read. Featured articles and Good articles are part of an internal system to help us improve the content, it is not a substitute Wikipedia of articles we prefer people to read. We are not estate agents directing people away from the rooms they want to see because they are in poor condition, and instead directing them to the lovely view out the window. We help people find what they want, and if the readers are not happy with the condition of the room, they can roll up their sleeves and help improve it. By being simple and honest we help the reader and the reader helps Wikipedia. It's a win win. Featured articles are part of the content, not a replacement for it. SilkTork (talk) 10:10, 5 May 2020 (UTC)

Discussion (Featured content)

 * Either way, both Featured content and Contents badly need a redesign. Renata (talk) 04:09, 14 April 2020 (UTC)

Upload file
A vast majority of uploads should happen on Commons. Those who have the know-how and understanding for why and how to uploaded files locally, know where to go. This is an old link that has very infrequent use now.

Survey (Upload file)

 * Support as proposer. --- C &amp; C (Coffeeandcrumbs) 23:03, 10 April 2020 (UTC)
 * Strong oppose only place for info on uploading media. The link allows you to choose Commons or here to upload files.-- Moxy 🍁 23:08, 10 April 2020 (UTC)
 * , Special pages has a link to "Upload file". People that don't know the difference between Commons and Wikipedia file upload are going to go to the wrong place (the most prominent link on the page).--- C &amp; C (Coffeeandcrumbs) 01:03, 11 April 2020 (UTC)
 * Oppose This doesn't appear to be technically possible. Even if it were, I agree with that it is not a good idea. * Pppery * <sub style="color:#800000">it has begun...  23:17, 10 April 2020 (UTC)
 * Oppose I think it is nice to have a link that directs people on how to upload the file. It is a matter of convenience. Interstellarity (talk) 23:31, 10 April 2020 (UTC)
 * Support there is so much content already uploaded and in my experience the good quality content is batch uploaded on commons. We don't need a link here that every person and their dog are invited to use. We are beyond that point. --Tom (LT) (talk) 00:14, 11 April 2020 (UTC)
 * Oppose the page gets like 5k views a day. There's no reason to make uploading harder. — Wug·a·po·des​ 00:17, 11 April 2020 (UTC)
 * , 5k is almost nothing. Other links get 10s of thousands of views. --- C &amp; C (Coffeeandcrumbs) 01:05, 11 April 2020 (UTC)
 * It's also nothing to thumb our noses at. That's 1.8 million clicks per year which help expose readers to the process of contributing files. Like I said, there's no reason to make it harder to upload media. — Wug·a·po·des​ 02:55, 11 April 2020 (UTC)
 * Oppose, making it harder for people to get the upload link isn't friendly to new editors - we already have it pushing them to commons via the dialog that is used when you click there. — xaosflux  Talk 02:05, 11 April 2020 (UTC)
 * Oppose per Xaosflux. Personally, I use this all the time to upload new film posters.  Lugnuts  Fire Walk with Me 07:47, 11 April 2020 (UTC)
 * Oppose I use this link more than most on the left. Many of our articles lack good images and we should not make it harder for people to add them. Andrew🐉(talk) 09:25, 12 April 2020 (UTC)
 * Oppose - any images added to Wikipedia can always be transferred to Commons at a later date, so why make them have to move over to Wikimedia Commons just to add an image to an article? Seems unnecessarily tedious to have to switch projects when you want to upload an image every time when you can add a semi-temporary version on Wikipedia and go through the trouble of transferring to Commons later. Kirbanzo (userpage - talk - contribs) 21:49, 12 April 2020 (UTC)
 * Weak oppose Many non-free images (eg. covers of works, historical portraits) are uploaded or could be uploaded locally. I use this more frequently than most of the other links and it would be annyoing to have it go away. <b style="color: White">b</b><b style="color: White">uidh</b><b style="color: White">e</b> 23:37, 12 April 2020 (UTC)
 * Oppose If anything should be changed, it should be the upload page, which should have a concise explanation of why things should be uploaded to commons. When I was a new user, I was thankful that the button existed, as I had no clue that you could upload files, let alone to commons. CaptainEek  Edits Ho Cap'n!⚓ 22:07, 17 April 2020 (UTC)
 * Strong support: our current editors can learn to navigate to a different place for this, or spend an extra couple of clicks (it's not like the NFC uploading process isn't already fairly lengthy). Putting it on the main sidebar visible on every page just encourages readers or new editors to misuse the feature by uploading non-free content that doesn't meet our NFCC—as commonly and regularly happens. It also wastes comprehension time for everybody else reading the sidebar. If someone asked us to redesign the sidebar bar for Wikipedia from scratch, by describing the purpose of the sidebar and asking which functionalities should be present, I am confident that not a single editor who opposes this removal would ask for a button for "Upload a file which belongs locally rather than at Commons". Thus we should remove it. — Bilorv ( talk ) 17:32, 18 April 2020 (UTC)
 * Support I'd recommend a maximal utilitarian approach here – what is the greater good? I agree it is essentially an open door for abuse. For dedicated users of that link an optional simple javascript code could be created and the link inserted on an individual basis. --Goldsztajn (talk) 11:14, 21 April 2020 (UTC)
 * Making it harder for people to contribute because of the possibility they might not contribute well seems very against the spirit of Wikipedia. &#123;{u&#124; Sdkb  }&#125;  talk 11:43, 21 April 2020 (UTC)
 * Strong oppose Wikipedia is already impenetrable enough. We shouldn't add yet another barrier to entry for new editors. CJK09 (talk) 05:03, 22 April 2020 (UTC)
 * Oppose, this would be an unnecessary loss of functionality. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Oppose, one of the few sidebar links that was actually useful for me. Not because of frequency, but because of discoverability. It has appropriate pointers to Commons, so it serves as a good entry point for uploading media. --MarioGom (talk) 20:51, 27 April 2020 (UTC)
 * Strong oppose - New editors may not be aware of Commons, but will still need to upload files on occasion. The wizard in the link guides them to Commons when appropriate, so removing the link would also reduce correct usage of Commons. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)
 * Oppose - non-free media files, such as album covers, need to be uploaded on Wikipedia, and it is useful to have a link on the article page itself so people don't have to look elsewhere. My main qualm is with the word "file", as that doesn't speak to me as a reader to mean I can upload the missing image. When I started on Wikipedia, images were called images, but at some point they got renamed to files, though the guidance still talks about images. So we have a file: File:RayCharlesDebut.jpg, and we have advice about images: Images; and we are supposed to intuitively know that files and images mean the same thing on Wikipedia, and that the guidance on images actually refers to files. SilkTork (talk) 10:25, 5 May 2020 (UTC)

Discussion (Upload file)

 * Do we have access to any data about what percentage of uploads come from that link? &#123;{u&#124; Sdkb  }&#125;  talk 23:37, 10 April 2020 (UTC)
 * No, because that link leads to 5 different upload processes. It gets 4-8 thousand pageviews daily though. --AntiCompositeNumber (talk) 00:14, 11 April 2020 (UTC)
 * We are sending people to the wrong place. 99.5% (educated guess) of uploads should be directed to Commons. --- C &amp; C (Coffeeandcrumbs) 00:57, 11 April 2020 (UTC)
 * The discussion we're both having at Wikipedia talk:File Upload Wizard may be relevant for others here. If the "Upload file" link ends up as more a soft redirect to Commons, with perhaps a small button at the bottom for Wikipedia-specific uploads, would you be more likely to support retaining it? Given the importance of images and other files to Wikipedia (and the fact that readers have asked for more of them, and the fact that they're likely to become increasingly important in the future), I'm hesitant to make changes that'd make it harder for casual editors to upload them. The link in Special:SpecialPages is very insufficient — that page is such a flood of links that, even in the unlikely event a casual editor intuits to go there, it'll turn them off long before they scroll enough to find it. &#123;{u&#124; Sdkb  }&#125;  talk 18:21, 11 April 2020 (UTC)
 * , I would be happy with that. We need to move people to Commons much quicker without confusing them. --- C &amp; C (Coffeeandcrumbs) 20:54, 11 April 2020 (UTC)
 * So we should fix that by updating File Upload Wizard - not by removing the link to get to the upload process for someone that wants to contribute. — xaosflux  Talk 22:29, 14 April 2020 (UTC)

Permanent link
As I understand it, the main benefit of this tool, for readers, is easy access to a reproducible, stable link to mainspace articles for citations. This function is duplicated by Special:CiteThisPage, which provides the link as part of the bibliographic information. If editors or other interested parties need a permanent link to non-mainspace content, where "Cite this page" does not appear, they only need spend one more click (→page history→latest revision). I suppose this may be a slight inconvenience, but one that could be likely remedied with a userscript or preference and is outweighed by the usability benefit of removing low-utility links from the sidebar.

Survey (Permanent link)

 * Support as proposer (assuming technical possibility), though I'm interested to know if I've missed any helpful uses of the tool. – Teratix ₵ 13:57, 18 April 2020 (UTC)
 * Support: "Cite this page" is new to me, whereas "Permanent link" is one of the ones I actually use. Nonetheless, I'll happily spend an extra click per usage to de-clutter the sidebar. We should not have both, because other than for experienced editors with obscure purposes, the main use for a permalink is indeed citations. — Bilorv ( talk ) 17:38, 18 April 2020 (UTC)
 * Oppose removing permanent link which is often required by editors when reporting issues. We could achieve the fake ideal of a perfect design with minimal clutter by hiding every link behind a single "tools" button that opened a cascade of options—totally useless for a working encyclopedia. Johnuniq (talk) 00:03, 19 April 2020 (UTC)
 * Support Maybe the "cite this page" link could use a little more info about permalinks. But as stated, they are mostly redundant. Also, the "reporting of issues" seems to be done mostly by diffs. Daveout (talk) 05:26, 20 April 2020 (UTC)
 * Oppose. An extra click is an extra click, and removing "Permanent link" would inconvenience readers who want to cite Wikipedia URLs in their (external) articles. feminist #WearAMask😷 07:43, 20 April 2020 (UTC)
 * Strong Oppose I know I use this link all the time, and I use it on other projects constantly. It is a core function (unlike C-T-P which is an extension) that just works. —  xaosflux  Talk 14:08, 20 April 2020 (UTC)
 * Support. While I do appreciate the presence of the "Permanent Link" link (as I use it myself), I understand that it is probably useless for a majority of our readers who don't plan on editing. To that regard, I'd think that it may be more useful to implement a gadget or a user script that adds the "Permanent Link" link to the sidebar, rather than have it be standard by default. Removing the link should not be undercutting its usefulness, as all of the functionality is one click away in the "Cite this page" tab. I do see the appeal with making the "Permanent Link" link accessible, but this feature being commonly used by readers; only a selection of editors working in the Wikipedia namespace. Utopes (talk / cont) 15:13, 20 April 2020 (UTC)
 * Strong oppose. I do use this, though I might also get the rev. ID from the History page with some extra clicks.  Internally I use Special:Permalink/…, the permanent URL is for readers who want to link from outside, more so than editors.  The big reason for having it is that it tells people there  as a permalink to a specific revision.  It sends the message "hey this content is always changing, there is a right way to link to this".  The phrase cite this page doesn't convey that up-front, and how many non-academics would be interested in "citing" rather than "linking"?  Pelagic (talk) 14:06, 21 April 2020 (UTC)
 * Strong oppose – Wikipedia is already too complicated. This should stay, it's useful and necessary in a variety of contexts. Many people will have no idea how to generate a permanent link otherwise. And even if they realize they need to start at "view history", there's a very strong possibility they'll be confused by all the links on that page, and give up. CJK09 (talk) 05:06, 22 April 2020 (UTC)
 * Oppose. Unconvincing reason. – Ammarpad (talk) 14:03, 24 April 2020 (UTC)
 * Oppose, as the reasoning seems pretty shaky. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Oppose. And by the way, permalink/permanent links pointers are pretty standard. --MarioGom (talk) 20:53, 27 April 2020 (UTC)
 * Support - It is easily accessible from elsewhere, and is of no use to most readers and a significant portion of editors. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)
 * Support - This isn't useful for most people and people who need it can still find this functionality elsewhere. Kaldari (talk) 17:10, 30 April 2020 (UTC)

Discussion (Permanent link)
You raise some interesting thoughts about why a reader might want to use the permanent link button. In most cases, when citing a page, it's probably best to use the permanent link button so that people know exactly what you were citing. In other cases, it might be best to link to the "fluid" version, so that people who follow your citation can benefit from any potential improvements to the page. It's kinda analogous to the subst vs. transclude options we have for templates. On a mostly unrelated note, you inspired me to think about the permanent link notice which led to this. &#123;{u&#124; Sdkb  }&#125;  talk 21:43, 22 April 2020 (UTC)
 * I completely agree,, it depends on your purpose. I was overstating things when I wrote "the right way". I was trying to curb my natural inclination toward verbosity and over-qualified statements.  😉  Pelagic (talk) 04:31, 25 April 2020 (UTC)

Wikipedia store
It links to https://store.wikimedia.org/. Per Hick's law, every link on the sidebar is a net negative unless it can demonstrate a significant and frequent usage by readers. I don't know how many people are buying a $40 hoodie with the Wikipedia logo on it in 2020, but it is surely a negligible proportion of desktop readers, all of whom see this link on every page they visit. Does not serve readers and does not serve editors. Anyone wishing to buy Wikipedia merchandise has a huge number of avenues available to them, including many which will take them immediately to Wikimedia's store (e.g. any search engine). Their first instinct will not be to read all the sidebar links from the article WrestleMania 36 (or whatever they happen to be viewing). Additionally, this page is only applicable to certain countries (not all English-speaking ones, even), and we have readers from all the countries in the world.

EDIT: Per below, roughly 20% of the purchases from the donation store originate from a click of "Wikipedia store", the other 80% from other avenues.

Survey (Wikipedia store)

 * Support as proposer. In additions to the reasons I listed above, which I imagine most editors and readers will find agreeable, I personally believe that Wikimedia should not be using our editors' work as a vehicle for profit promoting donations in the way that they do, which ranges from this link in the sidebar to the intrusive, persistent, misleading and frequent "FOR THE PRICE OF A CUP OF COFFEE" banners they advertise all over our articles with. A link to the "Wikipedia store" may have been a good novelty in 2003, when the concept of Wikipedia was modern and hip and you might want a water bottle to show your support, but in 2020 when we are just a part of everyday life, it's about the most bland and useless link we could put on our sidebar. Imagine if one of the links at the top of every Amazon page was a link to a collection of T-shirts with the Amazon logo on it. — Bilorv ( talk ) 18:08, 18 April 2020 (UTC)
 * Changed "using our editors' work as a vehicle for profit" to "promoting donations" upon learning what the donations are earmarked for. — Bilorv ( talk ) 11:41, 23 April 2020 (UTC)
 * Support as mentioned above, per Bilorv. Anyone interested in merchandise can still find it with relative ease (if I Google "Wikipedia merchandise" the first hit is https://store.wikimedia.org/ ). If it's a major source of money (which I doubt, but what do I know), it could be linked from https://donate.wikimedia.org instead (which is where I land if I click "Donate to Wikipedia" in the sidebar). Ajpolino (talk) 18:22, 18 April 2020 (UTC)
 * Re money: See Merchandise income, and Wikimedia_merchandise ("All proceeds are filtered back into the store to keep production costs low, subsidize shipping and help to provide merchandise specifically aimed towards community members."). --Yair rand (talk) 17:11, 19 April 2020 (UTC)
 * Support per above. Money isn't an issue here, because the profits from the store don't fund Wikipedia, they're used to fund free merchandise giveaways to editors . I'm generally opposed to merchandising Wikipedia because it leads to nonsense like this (300-euro shirts and 120-euro hats) and this (how did that happen?). Anyway, anyone wanting to find the store will easily be able to find it; it's not necessary to put a link to the store on every page, and if anything, it draws clicks away from the "donate" link. Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 18:52, 18 April 2020 (UTC)
 * Support, prominent location for a link with negligible net benefit to the foundation and the project. Renata (talk) 19:06, 18 April 2020 (UTC)
 * Oppose, I wouldn't even know it existed if it weren't there. But if it were removed I agree that it should be linked in the donate page. GoodCrossing (talk) 23:30, 18 April 2020 (UTC)
 * Support, this type of thing should be merged with the "make a donation" section. Daveout (talk) 04:58, 20 April 2020 (UTC)
 * Support per Daveout. feminist #WearAMask😷 07:43, 20 April 2020 (UTC)
 * Comment, WMF would prefer to keep this for now, and perhaps revisit it later. The store is used by people who love Wikipedia, and the money is earmarked to supply gifts to community-nominated volunteers, a programme we are in the midst of refreshing. Quiddity (WMF) (talk) 23:09, 21 April 2020 (UTC)
 * thanks for providing the WMF stance, which I respectfully disagree with. Do the WMF have any record of what proportion of items bought on this store originate from a click from this particular link (rather than e.g. search engine traffic)? — Bilorv ( talk ) 11:41, 23 April 2020 (UTC)
 * (sorry for the reply delay). The link in the sidebar leads to roughly 20% of the items bought at the store. The majority of the remainder of the traffic and purchases come via the "Thank you for donating" confirmation-emails. HTH. Quiddity (WMF) (talk) 19:26, 7 May 2020 (UTC)
 * thank you, this information is very useful. I've mentioned it in the top of this section so that people can use it to inform their opinion. — Bilorv ( talk ) 21:00, 7 May 2020 (UTC)
 * Oppose. This is a classic example of the kind of link that has low usage, but has extremely high value for the 0.1% of readers who want it.  It's worth keeping for those 0.1% of users.  SnowFire (talk) 06:32, 25 April 2020 (UTC)
 * Support This is nowhere near important enough to merit such a prominent spot. * Pppery * <sub style="color:#800000">it has begun... 22:27, 25 April 2020 (UTC)
 * Weak support, as long as the link was moved to the donations page. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Weak oppose, no better place for it to go I think (it should be displayed somewhere).--YTRK (talk) 13:28, 27 April 2020 (UTC)
 * Oppose, one might disagree with the existence of an official Wikipedia Store or its prices, but given its existence, I think it really belongs there, close to Donate/About/Contact/etc. --MarioGom (talk) 20:48, 27 April 2020 (UTC)
 * Oppose If it exists, and I suppose some people actually do want to buy the merchandise, It should go where such things are is normally found on websites, with donations. I suggest a single Support Wikipedia link, which goes to the various possibilities.  it should be a on the Donations section of things. DGG ( talk ) 22:08, 27 April 2020 (UTC)
 * Support - I think most people who want Wikipedia merch (which isn't exactly a large market) would be able to find it elsewhere. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)

Discussion (Wikipedia store)

 * Discussion is related to Wikipedia store → Merchandise above, and partly spun out of it due to users and  saying that they could support a removal of this link. — Bilorv ( talk ) 18:10, 18 April 2020 (UTC)
 * I'd be interested to hear you or your colleagues' perspective on this. &#123;{u&#124; Sdkb  }&#125;  talk 22:08, 18 April 2020 (UTC)
 * IIRC, Seddon's role as Advancement department liaison is currently being held by User:Quiddity (WMF), while Seddon is temporarily working with the Product department. --Yair rand (talk) 17:25, 19 April 2020 (UTC)
 * Also, it may or may not be the case that the store is now managed by User:KHansen (WMF). It's hard to tell. Unfortunately, much about the store (and the staff roles) is terribly documented. --Yair rand (talk) 03:31, 20 April 2020 (UTC)
 * If I oppose, will I get a t-shirt in the mail?  I don't think I've ever tapped that link before today.  Never is a long time, but not in recent years anyway.  It's probably more noticeable to new or infrequent visitors who haven't yet become accustomed to ignoring segments of the UI.  For those who do notice, it does serve to bring to mind the  of wiki-merch. If they then go on to a web search and find a €300 hoodie, then fine.  Can we make a deal with Randall to sell these?   I do note that this and many other sidebar elements were intentionally left out of the Minerva/mobile and mobile-app interfaces, and that mobile is a primary medium for many of our readers.  So a large part of our audience is already not seeing the link.   Sure, Wikipedia is an encyclopaedia, but it's also a website.  That we have on the desktop site a store, and badges which say "a Wikimedia project" and "powered by MediaWiki", and legal disclaimers, etc. doesn't bother me: it goes with the territory.   [Sorry if my formatting is objectionable; I'm thinking about ways to do multi-paragraph talk-page posts. It feels like we can do well-structured output or readable source code but not both.]  – Pelagic (talk) 22:41, 22 April 2020 (UTC)
 * Many people (including volunteer-me, years ago) have suggested that we stock Citation needed stickers in the store. The hesitation is that we don't want to encourage what could be seen as public-property vandalism, e.g. someone putting these stickers on bus-stop advertisement posters, or within busses, etc.
 * I'll also note that we're currently investigating the feasibility/cost of offering 3D-printed Wikipedia puzzle globes in the store, for people who don't want to go through the hassle of using the freely available files themselves. Cheers. Quiddity (WMF) (talk) 22:07, 7 May 2020 (UTC)
 * public-property vandalism oh, good point! Pelagic ( 📝 messages ) 🌲 – (23:14 Sun 10, AEST) 13:14, 10 May 2020 (UTC)

Print/export (both "Download as PDF" and "Printable version")
Those options have already been included in virtually all web browsers for quite some time now. (Chrome, Firefox, Opera, Etc). Really. Even simple mobile browsers have those.

Survey (Print/export)

 * Support as proposer. Daveout (talk) 21:48, 21 April 2020 (UTC)
 * Strong oppose for ease of use reasons. We need to keep in mind systemic bias here – the demographic of editors differs vastly from the demographic of readers. Many older people have difficulty navigating the zillions of menus and buttons on modern operating systems, browsers, etc, and stick to workflows they are familiar with. I've observed this helping my father, who's in his 60s, with computer stuff. I've also seen it far more acutely when my grandmother was alive (I helped her with her email). I see no good reason to remove a simple and obvious one-click workflow in exchange for a (presumed) alternative workflow usable only by means of (often hidden) menus and/or keyboard shortcuts. CJK09 (talk) 05:11, 22 April 2020 (UTC)
 * Oppose per, who makes the point about systemic bias very well. And it's even more important when we're talking about the print function, given how much the older generation likes to print things rather than view them online. &#123;{u&#124; Sdkb  }&#125;  talk 11:04, 22 April 2020 (UTC)
 * Weak Oppose the way to save as a PDF on google chrome requires you to press print and then select save to PDF as the printer. This is slightly counterintuitive (as you print to save). Therefore, for those who find it hard to save the page as a PDF document through the browser, having this link is useful and quicker. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 22:10, 26 April 2020 (UTC)
 * Support, as the modern browser does both quite easily. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Weak oppose to plain removal. I would rather get it elsewhere if there is any major UX revamp. --MarioGom (talk) 20:54, 27 April 2020 (UTC)
 * Support - As others have said, these features are included in most browsers. Though there are some who don't know how to access them, I doubt that they are often enough used to warrant sidebar entries anyway. Most people - even those who are bad with technology nowadays - would bookmark a page to make note of it instead. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)

Discussion (Print/export)

 * I don't see an option for downloading as PDF in any major browser? --Yair rand (talk) 21:21, 21 April 2020 (UTC)
 * Hi, Yair. That's because most of them use the term "Print to PDF" instead of "Save as PDF". Just look for the option to "Print" the page (keyboard shortcut: press "Ctrl" + "P" at the same time) and the option to print to PDF will definitely appear. Daveout (talk) 21:46, 21 April 2020 (UTC)


 * Question When I click the printable version, it goes right to my browser's (desktop Chrome's) print dialogue. Is that the case for all users? If so, perhaps we should rename "printable version" to "print this page". &#123;{u&#124; Sdkb  }&#125;  talk 11:06, 22 April 2020 (UTC)
 * It should be called just "Print". Daveout (talk) 11:51, 22 April 2020 (UTC)
 * I get the same on an iPad (Safari). Though if I cancel then subsequent attempts produce a dialog box "this website has been blocked from automatically printing [ignore] [allow]".  Probably the only users who get a "printable version" onscreen without a print dialog would be those with JavaScript disabled? (haven't tested this) Pelagic (talk) 00:11, 23 April 2020 (UTC)
 * , correct —Th e DJ (talk • contribs) 10:31, 14 May 2020 (UTC)


 * Another question: when using the browser's Print function, do we use the magic of CSS @media to get the same layout as from "Printable version" (no navbars, alternate fonts), or is it different? Pelagic (talk) 00:11, 23 April 2020 (UTC)
 * They should be the same. You can preview this "printable version" in browser (without the system's print dialog) by copying the link's url and pasting it in another tab. Daveout (talk) 00:52, 23 April 2020 (UTC)
 * I see, so the  does do what it says and strips out the navigation elements server-side.  (And the two approaches do look identical.)  Combining this with what  said above, and testing a bit with some desktop browsers (where I can access F12 tools): it appears that, when JS is enabled, we intercept the click and just launch the native print dialog, allowing @media selectors to do their job and saving a round-trip to the server.
 * That explains why, for users who (a) have working JS and the right level of CSS support (most people), and (b) know how to use the browser's print function (maybe not as many as we'd assume, see TheDJ's comment below), this link is unnecessary.
 * Do we keep this for those who lack (a) or for (b)? For me, the (a) case merits consideration, making Wikipedia usable on as many devices as possible. Whether that has to accommodated in the default Desktop skin is an open question.
 * – Pelagic ( messages ) 🌲 – (11:43 Sun 17, AEST) 01:43, 17 May 2020 (UTC)
 * I can't see how this link could be useful for someone who lacks (a). In case (a), if someone wants to print the page they are previewing, they would need to resort to the browser's print option anyway (which probably already has a "print preview" feature). Daveout (talk) 04:58, 17 May 2020 (UTC)
 * If the web browser doesn't have a sufficient level of CSS support to do it for you, then the &printable=yes version provides another means to strip out the extraneous navigation elements, for printing ... or other reasons. Another rare (these days) use case occurred to me: say you wanted to "save page as HTML" without the cruft, you could load the printable version then save that.  Sigh, I've been around the interwebs too long.  Simplified view and click here to print are two different things that we've smooshed together in the belief (probably true) that most people only care about the latter. Pelagic ( messages ) Z – (08:06 Mon 18, AEST) 22:06, 17 May 2020 (UTC)
 * Printing and exporting might be old-school, but an analogous modern feature that produces stripped-down pages is the "reading view" found in several non-Google web browsers. (I do wonder how many people use reading view for accessibility compared to those who use it as an ad killer, noting that the latter doesn't apply to Wikipedia since we're ad-free.) Pelagic ( messages ) Z – (08:06 Mon 18, AEST) 22:06, 17 May 2020 (UTC)
 * Those are very -very- extreme scenarios indeed 😅. but i'm guessing that if someone really really wanted to do those things (strip the webpage), they probably would be able to find a 3rd party workaround to do that somewhere in the internet Daveout (talk) 22:54, 17 May 2020 (UTC)
 * As someone who has advocated for the removal of printable version link for a LONG time. I will note that I have been surprised by the amount of users who CANNOT find the print feature in their browser. Yes I know it sounds insane, but long time users (especially those who long clung to IE) are so used/trained to having to use a 'print link' because each ticketing service they use has a 'print ticket' button, that they are unaware that their browsers are perfectly able to handle printing these days. This is why eventually I chose to rename it to 'print' instead and just trigger the JS print function. —Th e DJ (talk • contribs) 10:29, 14 May 2020 (UTC)
 * needless to say that 'download as pdf' is an even bigger crowd (which is why the foundation spent so much engineering trying to keep that functionality alive). —Th e DJ (talk • contribs) 10:33, 14 May 2020 (UTC)
 * I'm surprised there wasn't a push for 'Download as ePub / Mobi / etc.' when e-book readers were all the rage. Pelagic ( messages ) 🌲 – (11:46 Sun 17, AEST) 01:46, 17 May 2020 (UTC)
 * I'm surprised there wasn't a push for 'Download as ePub / Mobi / etc.' when e-book readers were all the rage. Pelagic ( messages ) 🌲 – (11:46 Sun 17, AEST) 01:46, 17 May 2020 (UTC)

Random article
One of the reasons presented in favor of putting the "Featured Content" inside "Contents" was that most "Modern readers use the search function or blue links to find the pages they are interested in". Based on that logic, with which i agree entirely, the "Random Article" link should be a simple button on the main "Contents" page. Daveout (talk) 15:50, 20 April 2020 (UTC)

Survey (Random article)

 * Oppose. It is difficult to articulate why, especially without straying into WP:ILIKEIT territory, but this is a widely-used button that serves both to entertain and to find articles on smaller topics, which likely spurs editing. I predict a snowstorm. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 21:04, 20 April 2020 (UTC)
 * Oppose. The "Random article" link is basically part of Wikipedia's identity, and shows the scope of what types of pages Wikipedia offers. I don't have statistics for its usage, but I am aware of its popularity. I echo KarasuGamma that my !vote is influenced by personal preference, but the "Random article" link is still very useful for Random page patrollers. Utopes (talk / cont) 21:44, 20 April 2020 (UTC)
 * Strongly oppose. You might say but I think the random article function is very iconic as Utopes says. Also, it's useful, for finding cool things to learn about or articles that need some corrections. Definitely keep. GoodCrossing (talk) 23:24, 20 April 2020 (UTC)
 * Heck no, my favorite link in the toolbar, even if it leads to one-sentence substub on a village somewhere. Renata (talk) 05:59, 21 April 2020 (UTC)
 * Super duper strong oppose it takes all oppoose everywhere in wikimedia: If it's taken away, then we'll once again, have to press more buttons. You can't even transclude a random page. Look (see the source code)! Random Page Patrollers would have to click up to twice as much buttons. &#123;&#123;replyto&#125;&#125; Can I Log In 's   (talk) page 16:44, 23 April 2020 (UTC)
 * Oppose: this iconic link is easily the most famous of the links on our left sidebar. It serves a clear purpose that a casual reader would never learn how to find otherwise, and serves as symbolic of a site where we hope readers learn something they never expected to learn, as well as the stuff they wanted to. — Bilorv ( talk ) 21:58, 26 April 2020 (UTC)
 * Oppose. It is iconic. People play the "random article game" where they click on the random article link in the sidebar and try to get to a predefined article through wikilinks in articles. I even played this game a few years back before I started regularly editing. This example isn't probably the main use case of the link, but there are plenty more use cases for the link. If I want to improve a random article, the link is very useful as it allows me to quickly move on to the next article if the article I just randomly visited was not in need of editing / had just been edited. Also it shows off our breadth of content to readers. A random visit to a article with a grammar mistake or spelling mistake may encourage a reader to edit to fix said mistake and so this article would receive edits where it otherwise might not have. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 22:21, 26 April 2020 (UTC)
 * Strong oppose. Random article is used for a variety of reasons. As mentioned above, this function is actually the focus of a few Wikipedia games. It is also used by editors (including myself) to find articles in need of improvement outside our usual interests, as well as casual readers trying to find new content. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Oppose per reasons above, it can be a way to learn about something new or find an article to work on.
 * Oppose - It is far more used than some of the links that are being proposed. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C

Discussion (Random article)

 * We don't have access to pageviews since it doesn't lead to a page, but I share the perception that, among sidebar links, the random article link is uniquely beloved by those who know about it. I've been thinking about it and discussing it briefly recently, so I'm glad to have a space to bring it up here. Regarding its appropriateness for the sidebar, it has a unique argument for a persistent presence, since unlike any other link in the sidebar, it's nice to be able to click it over and over, whereas if it was just a button on the Main Page (which perhaps it still should be), clicking it would take you away from the button, so you'd have to go back to use it again.The main issue with the link is that, while it's useful for getting a sense of the full scope of Wikipedia, most articles it leads to are stubs about small towns, minor sports topics, or obscure species, and thus of limited interest to actually read. There could be several other versions of the button, leading for instance to a random good/featured article, or to a random vital article at a designated level. I can envision a module with two sliders, one for quality and one for obscurity, that editors could adjust before clicking the button, but I don't know how that could be integrated into the sidebar. What do you all think? &#123;{u&#124;  Sdkb  }&#125;  talk 05:40, 21 April 2020 (UTC)
 * I think it's really fine as it is, even if it does tend to lead to stubs. However, I'm all for customization, so having a way to configure the quality of the random articles sounds like a good feature (although in my case, since I like the current random button, I'd leave the settings like that) for the people that don't want to see just stubs when they click the button. GoodCrossing (talk) 10:40, 21 April 2020 (UTC)
 * I had no idea that this link was so beloved by so many editors, User:KarasuGamma was right, this was a snowball in hell, lol. /// I have no idea of how to implement those variants. Maybe after someone clicks the link for the first time, other options could appear bellow it?, maybe a narrow top-banner with more options could appear for those randomizing articles? I don't know... Daveout (talk) 11:34, 21 April 2020 (UTC)
 * I think the button would be improved if it only led to articles B-class or higher. Still a fairly large selection, but with the worst filtered out. --Yair rand (talk) 21:24, 21 April 2020 (UTC)
 * Comment I'm not too familiar with closing RfCs, but it seems like this can be closed as WP:SNOW, right? GoodCrossing (talk) 18:17, 25 April 2020 (UTC)
 * This was definitely a snowball in hell. I'm not sure how to proceed tho. Should I simply delete it? or should I let it here for "documental reasons"? Daveout (talk) 19:47, 25 April 2020 (UTC)
 * I believe as per WP:CLOSING an uninvolved editor should close this. GoodCrossing (talk) 19:53, 25 April 2020 (UTC)

Recent changes
I think that this link is not (at all) useful to the average reader or editor. It should be left inside the "special pages".


 * Support as proposer Daveout (talk) 23:17, 22 April 2020 (UTC)
 * Oppose: You the proposer are a vandal for proposing this. I'm calling WP:ARBCOM to WP:SITEBAN you! Stuck because WP:AGF If I want to go recent changes patrolling, then I'll press that button on the left. Sure you can do [alt-shift-r], but nah. So what do you want us to do? Not RCP? I'm not going to press and extra button and scroll through to find recent changes. Otherwise, I might have to resort RCPing on my userpage! For example, see this new invention.

P.S. I would support this, but it's not very interactive. &#123;&#123;replyto&#125;&#125; Can I Log In 's  (talk) page 01:13, 23 April 2020 (UTC)
 * I certainly won’t object your mass patrolling habits, but you gotta admit that patrolling 6.000.000 pages at once is not something average users normally do. This seems to be a feature used by advanced editors only, and they can easily bookmark that page in their browsers so it will be one click away. People say that we shouldn’t rename ‘’print this page’’ to ‘’print’’ because the elderly might get confused, imagine what would happen to grandmas if they clicked on that ‘’recent changes’’ by mistake, they would probably drop dead out of mental overload. Think about that. Daveout (talk) 02:13, 23 April 2020 (UTC)


 * Oppose What? This link is widely used by the RCP, which is one of the most important parts of controlling the quality of the project. I'll argue that having the link on the sidebar, where it's very easily accessible, is important to encourage its use. GoodCrossing (talk) 10:49, 24 April 2020 (UTC)
 * Oppose per above. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 22:27, 26 April 2020 (UTC)
 * Oppose, I don't see the harm in its inclusion, but I do see the value. Not convinced. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Oppose, actually very useful for patrolling, as well as promoting more people patrolling for vandalism and other issues. --MarioGom (talk) 20:56, 27 April 2020 (UTC)
 * Oppose - Not only does it serve a important purpose to editors, but it also serves as a live demonstration of Wikipedia's editing activity to those unfamiliar with the site. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T  C  03:46, 28 April 2020 (UTC)
 * Oppose the link is an excellent introduction to the ever-changing nature of Wikipedia. – Teratix ₵ 04:36, 29 April 2020 (UTC)
 * Strong oppose - Many of us use the link for detecting vandalism. There is no way I would support removing this link. Interstellarity (talk) 11:38, 29 April 2020 (UTC)

Autocollapsing
A key component of usability is reducing visual clutter by hiding less important links. Accordingly, these proposals suggest collapsing some sections by default, with readers able to click to expand them if desired.

"Tools" section
The links in this section are used only moderately frequently even by editors. Far more importantly, though, Wikipedia should be designed for readers, not editors, and there is definitely no need for readers to see these links on every page they visit. A recent user research report confirms that. A setting could be introduced for editors to keep the section expanded by default if they want.

Survey (collapse Tools)

 * Support as proposer. &#123;{u&#124; Sdkb  }&#125;  talk 21:46, 10 April 2020 (UTC)
 * Support Although collapsing is strongly discouraged every where when concerning readers due to accessibility.... we all know that collapsed things make people look.-- Moxy 🍁 22:08, 10 April 2020 (UTC)
 * Oppose Explaining to someone how, for example, that a hidden category can be seen by clicking "Page information" should not be complicated by some design dream of the perfect page where nothing is visible. People who vaguely remember that there is an "information" something can search and find it under Tools. They would never find it if Tools is collapsed. Collapsing requires JavaScript which is not compulsory for Wikipedia. Johnuniq (talk) 23:33, 10 April 2020 (UTC)
 * Oppose usability > design. Also per Johnuniq. TonyBallioni (talk) 23:39, 10 April 2020 (UTC)
 * Qualified support if, like a "normal" website, we could make it a preference whether to collapse or expand the tools section by default. Something tells me not to assume that this is doable, even if other websites have had this functionality for years. My understanding is that the number of web users without javascript is incredibly tiny, like 0.1%, so if that's true I don't think that's a concern. Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 00:07, 11 April 2020 (UTC)
 * Weak oppose prefer just renaming it something like "Editor tools" or "Advanced tools". I get that readers may be confused by it but this seems like more work than it's worth. Readers aren't spending hours every day looking through the "tools" section and wondering what it all means; they may spend a few seconds, go "huh" and then move on with the rest of their lives like they do with every other editorial button. Most of our readers are on mobile where they don't even see the toolbox. — Wug·a·po·des​ 00:24, 11 April 2020 (UTC)
 * Oppose likely to cause accessibility problems. And those who want to use the links will need to make one extra click. There is a lot of space in the sidebar, I see no reason to collapse. SD0001 (talk) 04:21, 11 April 2020 (UTC)
 * Fair enough, but consider that there's also a lot of empty space on Google's homepage (and plenty of products that could reasonably fill the space), but there's good reason they keep it that way. Every item that we remove or collapse helps the remaining items stand out more and makes it quicker for readers to find them. &#123;{u&#124; Sdkb  }&#125;  talk 04:47, 11 April 2020 (UTC)
 * Oppose, due to both accessibility problems and I don't believe an extra click is required on the side bar, which is designed for easy navigation around Wikipedia. An extra clicking step defeats the purpose, (and there's so much room!) Utopes (talk / cont) 22:23, 14 April 2020 (UTC)
 * Oppose any collapsing option, these are meant to be quick links. — xaosflux  Talk 22:28, 14 April 2020 (UTC)
 * Oppose As an editor, I would constantly be using an extra click, which would drive me nuts. I'm with Tony: if it ain't WP:BROKE don't make it more complicated The only way I might support would be if you could turn it off in preferences, but that sounds like more coding and back-end work than is needed. Addendum: I would also support if it were only auto collapsed for logged out users, if that is technically feasible.  CaptainEek  Edits Ho Cap'n!⚓ 22:09, 17 April 2020 (UTC)
 * Not helpful in the least. ~ Amory <small style="color:#555"> (u • t • c) 10:31, 20 April 2020 (UTC)
 * Oppose, might rename the section and move it down, but it should not be hidden. Renata (talk) 08:36, 21 April 2020 (UTC)
 * Out of scope. WMF has a separate effort looking at the design and behaviour of the sidebar, this RFC is meant to be about content only. Also, design philosophy of current Vector is to put all the things out in the open (compare user links – name, Sandbox, Preferences, … – at top right which are also not hidden in a drop-down).  A single collapsible section feels out of place, would want all headings collapsible for consistency. Pelagic (talk) 20:32, 21 April 2020 (UTC) Edited Pelagic (talk) 00:22, 23 April 2020 (UTC)
 * Support for logged-out users only: While I believe they should be shown by default for editors, they're of no use to the average reader. — python coder (talk &#124; contribs) 21:40, 25 April 2020 (UTC)
 * Strong oppose. You're saying you want editors to have to expand the tools menu every time they want to use it? Sure, it's one click, but that's one extra inconvenience every time I want to use it. There is no usability issue with leaving it open and I get the feeling this change would quickly reverted once the entire editor base experienced it. Support for logged-out users only per nominator. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * My intention is that most active editors would choose to keep the sidebar expanded by default, so it would be no different than now. Would you be open to supporting this for logged out users only, as per PythonCoder above you? &#123;{u&#124; Sdkb  }&#125;  talk 04:33, 27 April 2020 (UTC)
 * Yes, I've missed that. Thanks. 5225C (talk &bull; contributions) 04:53, 27 April 2020 (UTC)
 * Oppose, I feel it won't look very "beautiful", if you get what I mean. Renaming it so that people would know the tools aren't intended for them would be better I think.--YTRK (talk) 13:28, 27 April 2020 (UTC)
 * Out of scope - this is major UX work that shouldn't be included in this RfC. I would rather see WMF's proposal for skin changes, or a dedicated proposal with actual UX rationale and implementation details. --MarioGom (talk) 20:57, 27 April 2020 (UTC)
 * Oppose Major loss of discoverability and convenience for only a very marginal improvement in appearance. -- The Anome (talk) 15:22, 29 April 2020 (UTC)

Discussion (collapse Tools)

 * Wouldn't this problem be solved simply by renaming it "Editor tools"? I acknowledge that it would make it look like there's a wall between readers and editors, but I contend that that wall already exists and this merely makes it visible, with the addition of not forcing readers to feel like they need to worry about this section. I'm neutral on the specific proposal to collapse. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 22:56, 10 April 2020 (UTC)
 * Neutral I would support this for logged out editors if there was a way to have it autoexpanded by preference or for logged in editors. It is very useful.--Tom (LT) (talk) 00:14, 11 April 2020 (UTC)
 * Neutral per Tom, I would like to see it collapsed for logged out users and autoexpanded for me. <b style="color: White">b</b><b style="color: White">uidh</b><b style="color: White">e</b> 23:38, 12 April 2020 (UTC)
 * collapsing only for logged out users would be fine by me. Is there someone we could ping who might know how technically feasible that is? &#123;{u&#124; Sdkb  }&#125;  talk 19:17, 13 April 2020 (UTC)
 * Opposers Would you be willing to support collapsing only for logged out users? If so, would you mind noting this in your !votes? This division covers 99% of non-editing readers and removes 99% of active editors, and the tools in this section are basically 100% useless to users who do not actively edit. (For enticing readers to edit, the soon-to-be "contribute" section will be far better, whereas the tools section links are terrible for newcomers, and the contribute links will be more noticeable if the tools section is collapsed.) &#123;{u&#124;  Sdkb  }&#125;  talk 02:16, 20 April 2020 (UTC)
 * No. I don’t see the point of any of this. That’s more complicated. The more complicated things are the easier it is for there to be issues. TonyBallioni (talk) 02:19, 20 April 2020 (UTC)
 * I know people are looking for things to do in these difficult times, but fiddling with the sidebar is not helpful. Wikipedia is and should be focused on content, not design. A key point is discoverabiity: in principle, someone could click all the expand buttons and eventually discover what is possible, but it's actually a lot better to leave the discoverable items expanded because most people have worked out that websites which hide content with beautiful design don't actually have any content and it's not worth clicking those useless buttons. What benefit will come from all this discussion? Johnuniq (talk) 02:24, 20 April 2020 (UTC)
 * No, just checks out a page as a logged out user, I don't see any benefit of adding a collapsing section there - it is very easy to ignore that part, and one thing that is very reader useful is in there: "Cite this page". — xaosflux  Talk 02:43, 20 April 2020 (UTC)
 * To see drop-down menus done well in a design that's responsive to different window sizes, try Timeless. Contrast the mobile app, where the space on the left is used for ToC navigation instead. Intead of addressing a single section of one design, let's consider some bold alternatives! (but outside of this RFC) Pelagic (talk) 00:19, 23 April 2020 (UTC)
 * I agree that the sidebar should be very different and much shorter for logged out users. Almostall ofthem have not come here to write anything., tho they may want to print something or to contribute funding.    DGG ( talk ) 22:51, 19 May 2020 (UTC)

Changing tooltips
Most of the links in the sidebar feature an additional tooltip that appears when the cursor hovers over the link. These tooltips contain explanations for the functions of their respective links, and are useful for accommodating all types of readers and editors who may be unsure about what a page does before they follow the link. These proposals outline potential changes in the wordings of the tooltips.

General tooltip discussion
Thanks for delving into this! I'm wondering, do you think there are any links that don't have a keyboard shortcut that ought to? &#123;{u&#124; Sdkb  }&#125;  talk 10:05, 21 April 2020 (UTC)
 * Sdkb: to be honest, I did not know that the shortcuts existed... Renata (talk) 17:12, 22 April 2020 (UTC)
 * +1 to the above, thank you Renata. I knew once I started drafting out the first couple of tooltip changes that there were many more problems, but I didn't want to start too many discussion for fear of a trainwreck. However, this table nicely summarizes a lot of what I was thinking, so thank you for doing this. And to answer your questsion Sdkb, I think the keyboard shortcuts are just fine where they are, and I do not think any of the links without keyboard shortcuts need one. Utopes (talk / cont) 15:50, 21 April 2020 (UTC)
 * I've edited the tooltips in both columns to maintain the current capitalization style for the keyboard shortcuts. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 21:20, 21 April 2020 (UTC)
 * KarasuGamma: I am seeing all lower-case shortcuts showing up currently. To capitalize "Alt" and "Shift" would be an additional change. Renata (talk) 17:12, 22 April 2020 (UTC)
 * Odd. Perhaps it's browser-specific? This is what I see, on Firefox 75.0. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 20:44, 22 April 2020 (UTC)
 * KarasuGamma: ha! Indeed, it seems browser specific. The list above I compiled based on Chrome. It's all lower-case there. Just checked Internet Explorer and the shortcuts are different. E.g. the random page shortcut is alt-x [lowercase]. Renata (talk) 01:18, 23 April 2020 (UTC)
 * I'm now curious about the code behind this. I expected the tooltip to be raw text. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 02:00, 23 April 2020 (UTC)

Featured content tooltip
The Featured content tooltip, which currently reads "Featured content – the best of Wikipedia", is the only tooltip on the sidebar that separates the name of the link and its purpose with an en dash. While many of the tooltips are redundant to the names on the sidebar, no other link in the sidebar has a tooltip in the format of "Title – Purpose". With this being said, I propose that the tooltip be changed to read "The best content of Wikipedia". The associated MediaWiki page is MediaWiki:Tooltip-n-featuredcontent.


 * Support as the proposer. Utopes (talk / cont) 15:49, 20 April 2020 (UTC)
 * Support per nom. &#123;{u&#124; Sdkb  }&#125;  talk 23:40, 20 April 2020 (UTC)
 * Support "The best of Wikipedia" per below. The word "content" isn't my favorite anyways; it seems overly commercial. &#123;{u&#124;  Sdkb  }&#125;  talk 14:57, 29 April 2020 (UTC)
 * Support The tooltip is for a extra explanation. Just repeating the link text is unnecessary. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 22:30, 26 April 2020 (UTC)
 * Support per nominator. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Propose "The best of Wikipedia", "content" seems unnecessary.--YTRK (talk) 13:28, 27 April 2020 (UTC)

Current events tooltip
Current events tooltip is oddly specific. "Find background information"? This implies that there are no articles about the actual current events. Propose to simplify to "Articles on current events".


 * Support as proposer. Renata (talk) 08:21, 21 April 2020 (UTC)
 * I'd prefer Articles related to current events, since "on" seems to imply that we're writing news articles, which we're not, especially in cases like recent deaths. Support either over status quo, though. &#123;{u&#124; Sdkb  }&#125;  talk 09:24, 21 April 2020 (UTC)
 * Weak Oppose both. While we technically have articles about current events, we don't really have "articles" about current events. It's important to note that Wikipedia is not a reliable source, as it can be edited by anyone. Therefore, all we have is information, and we should continue to describe it like so. (My oppose is weak because I agree that "find background information" is not the strongest wording. Do keep in mind that the current events link targets a portal, and not just a list of articles on or related to current events.) Utopes (talk / cont) 16:31, 21 April 2020 (UTC)
 * Support "Articles related to current events", as we don't actually have coverage of recent events in the style of Wikinews. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)

Random article tooltip
There is no article being "loaded", and is the only tooltip to use this language. I propose "Visit a random article" instead, or perhaps "Visit a randomly selected article". I have more of a preference towards the latter, because the former may give off the impression that the random article has already been picked and is just being delivered to you. (Plus, redundancy). Regardless, I would like to remove "load" from the tooltip.


 * Support as proposer. Utopes (talk / cont) 16:05, 21 April 2020 (UTC)
 * Support "Visit a randomly selected article [Alt+Shift+x]". <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 21:22, 21 April 2020 (UTC)
 * Support "Visit a randomly selected article [Alt+Shift+x]" Renata (talk) 17:13, 22 April 2020 (UTC)
 * I agree that this should be changed, but I don't think a simple addition of "Visit" to the text would make a good tooltip. --Yair rand (talk) 17:22, 23 April 2020 (UTC)
 * It would be akin to the main page tooltip that reads "Visit the main page", from which the word "visit" provides some level of consistency. Utopes (talk / cont) 20:19, 24 April 2020 (UTC)


 * Support "Visit a randomly selected article [Alt+Shift+x]". Simpler to read. "load" is not needed. Consistency with "Visit the main page" is useful too. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 22:33, 26 April 2020 (UTC)
 * Support "Visit a randomly selected article [Alt+Shift+x]" for clarity. 5225C''' (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Support "Visit a random article [Alt+Shift+x]", seems lengthy with the "selected".--YTRK (talk) 13:28, 27 April 2020 (UTC)

Donate to Wikipedia tooltip
The tooltip on this link currently reads simply, "Support us". In line with the proposed change above to rename this link "Donate", the tooltip should have further explanation; I propose "Support us by donating to Wikipedia", or a similar wording such as "[...] to the Wikimedia Foundation" (credit to Bilorv) as appropriate.


 * Support in any form as proposer; I suggested the "to Wikipedia" variant above, and I welcome the addition of a tooltip-only discussion section. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 21:02, 20 April 2020 (UTC)
 * Support per proposer using either "to Wikipedia" or "to the Wikimedia Foundation". Utopes (talk / cont) 22:11, 20 April 2020 (UTC)
 * Comment, WMF supports the change to "Support us by donating to the Wikimedia Foundation". Quiddity (WMF) (talk) 23:10, 21 April 2020 (UTC)
 * Support per proposer. First choice is the the WMF supported idea listed by Quiddity and second choice is "... to Wikipedia". The tooltip gives more information and being clearer on who the donation goes to is better. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 22:36, 26 April 2020 (UTC)
 * Support the WMF option per nominator and the fact donations aren't exclusively used for Wikipedia. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)

Discussion (change Donate tooltip)

 * Regarding the proposals, I think it'd be more streamlined to use just "Support Wikipedia" or "Support the Wikimedia Foundation". Regarding the overall idea of redoing this tooltip, I'd like some perspective from WMF folks with marketing experience. We shouldn't let marketing incentives detract from usability/design considerations (e.g. we're not going to use giant blinking red font screaming "CLICK HERE!!!" for the link itself), but if something like "Support our vital mission" for the tooltip would lead to more engagement, I'd be fine with going with that. Pinging and : if possible, it'd helpful to know if you have any thoughts before this goes too much farther, as it'll be harder to change course once consensus starts to form. &#123;{u&#124;  Sdkb  }&#125;  talk 00:23, 21 April 2020 (UTC)

Wikipedia store tooltip
Current tooltip "Visit the Wikipedia store" is redundant and provides no new info. Suggest changing to "Support us by purchasing Wikipedia merchandise" so that it is parallel with the proposed "Donate" tooltip. (This might be mute if proposal to get rid of the link altogether goes through.)


 * Support as proposer. Renata (talk) 08:21, 21 April 2020 (UTC)
 * Comment the best tooltip here is highly dependent on the outcome of the renaming discussion above. Hopefully someone will come in soon and start closing some of the more SNOWy proposals, but until then, it might be best to put this on pause. &#123;{u&#124; Sdkb  }&#125;  talk 09:27, 21 April 2020 (UTC)
 * The WMF doesn't make money off the store, so this might be misleading. People wearing/using Wikipedia-branded items is "supporting" in a certain sense, but with this located just below the donate button, it might be taken another way. --Yair rand (talk) 17:24, 21 April 2020 (UTC)
 * It could be argued that providing money for the WMF to buy merchandise for active contributors, which then boosts editor retention, is a form of support. But yeah, it's somewhat more indirect than e.g. server maintenance. &#123;{u&#124; Sdkb  }&#125;  talk 17:55, 22 April 2020 (UTC)waiting to be nominated someday...
 * Oppose. A tooltip is not required to provide new info. It should be used to aid a reader when they're not sure what the purpose of a link is. In that regard, the "Wikipedia store" is pretty self explanatory, and the funds do not go to the WMF. Therefore, the link's function is as a way to access the Wikipedia store. To this point, I suppose that what is defined as "new info" is subjective and many of the changes that have been suggested are trivial in the whole scheme of things. But these tooltips to not need to become this long when the purpose of the link is very much clear. Also, "visit" would be consistent with other tooltips. Utopes (talk / cont) 20:23, 24 April 2020 (UTC)
 * Support per nominator. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Oppose per Yair rand. Also if the link is renamed (and I think it's pretty likely), it will be providing new information.--YTRK (talk) 13:28, 27 April 2020 (UTC)

About Wikipedia tooltip
Current tooltip "Find out about Wikipedia" is not very helpful. We have an article on Wikipedia in the main space. It seems that About describes more about how things work. Therefore, I suggest "Learn more about Wikipedia and how it works".


 * Support as proposer. Renata (talk) 08:21, 21 April 2020 (UTC)
 * Comment; this new tooltip kind of falls in vein with the first, in the sense that you can learn about Wikipedia and how it works in the mainspace article. However, I'm inclined to support any change here, because "find out about" is clunky. Utopes (talk / cont) 15:51, 21 April 2020 (UTC)
 * Support as proposed. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 21:23, 21 April 2020 (UTC)
 * I agree with the exclusion of "more" per Dreamy Jazz. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 02:32, 27 April 2020 (UTC)
 * Oppose. This seems to be adding a bunch of words that don't do much. I'd prefer Learn about Wikipedia. As the most active recent contributor to WP:About (which unfortunately is not saying much), I find your thoughts on how it ought to be differentiated from Wikipedia interesting; it'd be good to have some further discussion on that at WT:About, since it's somewhat of an open question, and we could change the answer as we make badly needed renovations to the page. &#123;{u&#124; Sdkb  }&#125;  talk 17:45, 22 April 2020 (UTC)
 * Support "Learn about Wikipedia" as it is more concise than the original proposal. However, I consider "Learn about Wikipedia and how it works" (note the removal of more as the user may not actually know anything about Wikipedia) as my second choice. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 22:39, 26 April 2020 (UTC)
 * Support per nominator. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Support "Learn about Wikipedia and how it works" (without "more"). It's a tooltip so we can afford the extra length.--YTRK (talk) 13:28, 27 April 2020 (UTC)

Community portal tooltip
The Community portal tooltip, which currently reads "About the project, what you can do, where to find things" is somehow a violation of WP:XY, which shouldn't even apply here. This is the only tooltip that uses punctuation besides the Featured content tooltip, and gives three different ambiguous uses for the portal. One of these uses also overlaps with another link, as "About the project" could also refer to the About Wikipedia link. While the Community portal does accomplish all three of these tasks, I personally believe that it may be confusing to give this broad of a tooltip, especially one that says "what you can do", because there are hundreds of ways to help out on Wikipedia. I do not have a suggested new tooltip for this case; I just believe that this should be changed to something more concise, while also being a good definition of the Community portal.


 * Support as the proposer. Utopes (talk / cont) 16:10, 20 April 2020 (UTC)
 * Suggest "The hub for editors". I agree with your rationale for change, and I think this sums up the portal's role. &#123;{u&#124; Sdkb  }&#125;  talk 23:46, 20 April 2020 (UTC)
 * Support a change. I am neutral on the wording "The hub for editors". Although I have used the community portal before, I now hardly ever use the page. However, this doesn't mean it isn't the hub for editors and so I am neutral on this wording. If I have any ideas I'll come back to suggest them. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 22:42, 26 April 2020 (UTC)
 * Support "The hub for editors" per nominator, until a better suggestion arises. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Support a change but weak oppose "The hub for editors", as per Dreamy Jazz.--YTRK (talk) 13:28, 27 April 2020 (UTC)

Recent changes tooltip
Current tooltip "A list of recent changes in the wiki [alt-shirt-r]" introduces whole new terminology by including "wiki" (all other tooltips reference Wikipedia specifically). Also "recent changes" seem very ambiguous -- recent management changes? recent policy changes? Therefore suggest to changing to "A list of recent changes made by editors [alt-shirt-r]"


 * Support as proposer. Renata (talk) 08:21, 21 April 2020 (UTC)
 * I'd prefer A list of recent changes to Wikipedia [alt-shirt-r], since "made by editors" is a little redundant. Support either over status quo, though; "in the wiki" is terrible. &#123;{u&#124; Sdkb  }&#125;  talk 09:30, 21 April 2020 (UTC)
 * Support Sdkb's tooltip. Utopes (talk / cont) 16:06, 21 April 2020 (UTC)
 * Support "A list of recent changes to Wikipedia [Alt-Shift-r]". <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 21:26, 21 April 2020 (UTC)
 * I think it would be better if the tooltip mentioned that the changes are edits to pages somewhere. I agree that the text "the wiki" should be replaced with "Wikipedia". --Yair rand (talk) 21:29, 21 April 2020 (UTC)
 * Support a change. "in the wiki" should be definitely changed to something more specific. Perhaps "A list of recent edits to Wikipedia [alt-shift-r]" (changing changes to edits). I will likely come back to support a particular wording if many are suggested. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 22:46, 26 April 2020 (UTC)
 * Support "A list of recent changes [alt-shift-r]" per nominator. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)

Contact page tooltip
Current tooltip says "How to contact Wikipedia". Well, there is no "Wikipedia" to contact. Therefore, suggest "Contact Wikipedia editors and report issues"


 * Support as proposer. Renata (talk) 08:21, 21 April 2020 (UTC)
 * Comment I see the logic in this, but the contact page also includes some options that go to WMF email addresses, rather than community editors. Any alternate ideas? Perhaps a simple "Get in touch"? &#123;{u&#124; Sdkb  }&#125;  talk 09:33, 21 April 2020 (UTC)

Upload file tooltip
Current tooltip "Upload files [alt-shift-u]" is completely redundant with no greater explanation. Suggest changing to "Upload copyright-compatible files to be used on Wikipedia [alt-shift-u]" "Add images or other media for use on Wikipedia [Alt-Shift-u]" It highlights both copyright issues and purpose of the files upfront. It explains what a "file" is and what is the intended purpose of these files.


 * Support as proposer. Renata (talk) 08:21, 21 April 2020 (UTC)
 * Oppose I think this gets into too much detail for a tooltip. All a tooltip should do is give someone enough information for them to figure out whether or not they want to click. If they do, then explain things like copyright at the landing page. I think the more useful thing to do here would be to explain what we mean by "files", since that may not be obvious. To that end, I propose Add images or other media for use on Wikipedia [alt-shift-u]. &#123;{u&#124; Sdkb  }&#125;  talk 09:37, 21 April 2020 (UTC)
 * Oppose Renata's tooltip, as not everybody is familiar with copyright rules, you can technically upload non-copyright compatible files. It's like telling people that the edit tab's function is to create high quality edits; it would be preferred, but not always recognized. Support Sdkb's tooltip. Utopes (talk / cont) 15:59, 21 April 2020 (UTC)
 * Support "Add images or other media for use on Wikipedia [Alt-Shift-u]". <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 21:27, 21 April 2020 (UTC)
 * Comment, ok, I see the point. Changed the proposal to "Add images or other media for use on Wikipedia [Alt-Shift-u]". 17:17, 22 April 2020 (UTC)
 * Support the ammended proposal per nominator. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)

Special pages tooltip
Current tooltip is not very helpful "A list of all special pages [alt-shift-q]". Is there a concise way to describe "special pages" and give a clue to a user what to expect?
 * Going off of the description and Help:Special page, perhaps "List of automatically generated pages [alt-shift-q]" or "List of pages generated by the software on demand for specialist purposes [alt-shift-q]"? &#123;{u&#124; Sdkb  }&#125;  talk 09:42, 21 April 2020 (UTC)

Permanent link tooltip
Change "Permanent link to this revision of the page" to "Permanent link to this revision of this page". All other tooltips refer to "this" page or "this" user. It's minor, but consistency also OCD.


 * Support as proposer. Renata (talk) 08:21, 21 April 2020 (UTC)
 * Support per my OCD tendencies. &#123;{u&#124; Sdkb  }&#125;  talk 09:43, 21 April 2020 (UTC)
 * Support as proposed. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 21:28, 21 April 2020 (UTC)
 * Support change proposed. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 22:48, 26 April 2020 (UTC)
 * Support ammended proposal per nominator. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Support... better. Jason Quinn (talk) 14:44, 24 May 2020 (UTC)

Page information tooltip
Current tooltip is not very helpful "More information about this page". Suggest a bit more helpful "Statistical information about this page".


 * Support as proposer. Renata (talk) 08:21, 21 April 2020 (UTC)
 * Weak oppose, since the information isn't all statistical. I would prefer Technical information about this page, which could help ward off readers who won't find what they might be looking for at that link. &#123;{u&#124; Sdkb  }&#125;  talk 09:46, 21 April 2020 (UTC)
 * I like "technical", that's the word I was trying to find! Renata (talk) 17:07, 22 April 2020 (UTC)
 * Oppose, and I think the current tooltip is fine here. Utopes (talk / cont) 16:11, 21 April 2020 (UTC)

Wikidata item tooltip
Current tooltip is a combination of the obvious and of the techno-mumbo-jumbo "Link to connected data repository item [shift-alt-g]". It's a link - duh, but the rest is a big huh?? I know about Wikidata and still have issues parsing the meaning of this. Any suggestions how to make this more user-friendly and less intimidating (particularly since clicking on the link and actually visiting Wikidata will only confuse people more)? Renata (talk) 08:48, 21 April 2020 (UTC)
 * Agreed that the current tooltip isn't great, but I'm not sure what to replace it with. Perhaps "link to structured data item"? That's still pretty technical, but might be a bit better. &#123;{u&#124; Sdkb  }&#125;  talk 09:49, 21 April 2020 (UTC)
 * Tbh, I'm not sure sounding overly technical is a bad thing for this particular link. Agree that "link to" isn't helpful, though. --Yair rand (talk) 21:27, 21 April 2020 (UTC)

How about "Structured data on this subject hosted by Wikidata"? Renata (talk) 17:06, 22 April 2020 (UTC)
 * I like that! Does "this subject" cover all the use cases, or are there some namespaces where it wouldn't fit (in which case, maybe use "this page")? Overall, support. &#123;{u&#124; Sdkb  }&#125;  talk 18:01, 22 April 2020 (UTC)
 * Even in the main namespace, "this subject" doesn't really work for disambiguation pages. --Yair rand (talk) 18:49, 22 April 2020 (UTC)
 * I would support a change to "Structured data on this page, hosted by Wikidata [Alt+Shift+g]", including the comma after "page". <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 20:49, 22 April 2020 (UTC)


 * Support "Structured data on this page hosted by Wikidata [alt+shift+g]" without the comma per nominator. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)

Logs tooltip
Current tooltip "View the list of actions by this user". Suggest "A list of logged actions by this user" for consistency with "A list of contributions by this user". Also "actions" is very vague. At least "logged actions" calls back to the page name which is "logs".


 * Support as proposer. Renata (talk) 08:21, 21 April 2020 (UTC)
 * Support sure, seems fine. I think the main risk of confusion here is that someone will think the link goes to a list of the user's contributions. This doesn't fully clarify that, but that might be asking too much. &#123;{u&#124; Sdkb  }&#125;  talk 09:52, 21 April 2020 (UTC)
 * Support "A list of logged actions by this user". Clarifying that this is "logged" actions means that it differentiates the user contributions page from the user log page. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 22:52, 26 April 2020 (UTC)
 * Support for consistency and clarity. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)

View user groups tooltip
There is currently no tooltip. Drawing a blank on how it could be described. Any suggestions? Renata (talk) 08:21, 21 April 2020 (UTC)
 * As with above, this depends on the outcome of the renaming discussion. But maybe something along the lines of "view the permissions of this user" would be good. For administrators, it could change to "manage the permissions of this user" if that's technically feasible, as it seems to be for the link name itself. &#123;{u&#124; Sdkb  }&#125;  talk 09:58, 21 April 2020 (UTC)

Mute preferences tooltip
There is currently no tooltip. Suggest "Mute emails and or notifications from this user".


 * Support as proposer. Renata (talk) 08:21, 21 April 2020 (UTC)
 * I'd prefer Mute emails or notifications from this user, which makes it clear you can do one or the other without doing both. &#123;{u&#124; Sdkb  }&#125;  talk 10:00, 21 April 2020 (UTC)
 * Support Sdkb's idea. Utopes (talk / cont) 15:52, 21 April 2020 (UTC)
 * Support "Mute emails or notifications from this user". <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 21:29, 21 April 2020 (UTC)
 * Comment agree on "or". Changed above. Renata (talk) 17:02, 22 April 2020 (UTC)
 * Support Sdkb's wording (with "or"). Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 22:54, 26 April 2020 (UTC)
 * Support ammended proposal. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)

Download as PDF tooltip
There is currently no tooltip. Suggest "Download this page as a PDF file".


 * Support as proposer. Renata (talk) 08:21, 21 April 2020 (UTC)
 * Support sounds good to me. It'd be nice if there was some way to explain here what a PDF actually is, but I don't know how we'd do that simply or concisely. &#123;{u&#124; Sdkb  }&#125;  talk 10:03, 21 April 2020 (UTC)
 * Support, sounds good. Utopes (talk / cont) 15:42, 21 April 2020 (UTC)
 * Support. --Yair rand (talk) 21:25, 21 April 2020 (UTC)
 * Support as proposed. <span style="font-family:'Lucida Sans Unicode','Arial'; color:#3A5A9C;">—&#8288; 烏&#8288;Γ (kaw) │ 21:29, 21 April 2020 (UTC)
 * Support as proposed. Clear tooltip which explains well the meaning of the link. Dreamy <i style="color:#d00">Jazz</i> 🎷 talk to me &#124; my contributions 22:55, 26 April 2020 (UTC)
 * Support, despite the tautology. 5225C (talk &bull; contributions) 00:42, 27 April 2020 (UTC)
 * Support, tooltips always good. Jason Quinn (talk) 14:46, 24 May 2020 (UTC)

A Customizable Sidebar (or an Advanced Mode)
While reading the discussions here, I found some comments expressing this sort of sentiment: ‘’I often use feature "X" and would be nice to have it just one click away but, because I want to make the sidebar less intimidating for readers and beginners, I vote for removing it’’. Since the sidebar is basically a list of shortcuts and tools, why not let users choose the ones that they want and need? A sidebar that could be personalized according to each user’s preferences. This would solve a lot of ‘’problems’’. Alternatively, there could be an ‘’advanced mode’’ (similar to what we have now in the mobile version) that would display tools and shortcuts that are normally used only by advanced editors. What do you guys think? Daveout (talk) 02:38, 21 April 2020 (UTC)
 * I know that this may seem like a radical proposal, but I thought it was worth a shot. If you think that this doesn’t belong here let me know and I’ll remove it Daveout (talk) 02:38, 21 April 2020 (UTC)
 * I've refactored a bit to make this a discussion rather than a survey; hope you don't mind. The reason is that I think there's probably general agreement that some degree of customizability or adaptability for the sidebar is desirable; the stumbling block isn't community consensus so much as technical capability. So I hope this thread can be a place to discuss how we might want to take steps to address that. Two initial thoughts: First, this is a complex enough task, and requires deep enough access to the code, that I think it's probably best handled by the developers at the WMF. The folks at the Desktop Improvements Project might have thoughts. Second, I think we probably do want to limit to some degree that customizability, since the more customizable it is, the more complex and harder to maintain it is. Two modes, one for readers/beginning editors and one for advanced editors, seems enough. Any other modifications are likely to be extremely niche and better accomplished with a gadget. &#123;{u&#124; Sdkb  }&#125;  talk 04:25, 21 April 2020 (UTC)
 * I think this could work on the various "tools". How I imagine this could work: in Special:Preferences you would be given a menu of links that can be included/excluded in your tools section (similar to the shopping list for gadgets). That obviously needs lots of coding. Renata (talk) 08:30, 21 April 2020 (UTC)
 * It's a great idea. Many websites have this functionality. The question is: who's going to code it? Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 17:32, 21 April 2020 (UTC)


 * Every regular user cares only about some of the links, but it's different for each of us. . We need a standard set for the many  users who do not wish to modify preferences, bu we also need the ability to choose what we individually need.  DGG ( talk ) 05:08, 22 April 2020 (UTC)

A note on power users, usability, and systemic bias
In these discussions let's keep in mind that hundreds of millions of people use en.wiki every month, and the vast majority of these people are far less tech savvy than the average Wikipedia editor commenting on this page. Functions and links that we rarely if ever use may be heavily used by the gen pop. Windows 8 was a case in point. Microsoft tracked how its users interacted with the Windows OS, and then decided to get rid of the start menu on the basis that hardly anyone used it. Well, it turned out that most people did use it, and power users who use keyboard shortcuts for everything were massively overrepresented in the pool of users who opted into the data collection.

Lots of less tech savvy people don't have the same mental models of the Internet that we do. For many, the computer is a magic box that can't be understood, and the way to get comfortable using it is to follow the same routines and workflows over and over and over again. Lots of people keep post-its on their monitor listing specific steps to access email, check bank account, etc. If one step in the instructions is no longer possible, the user gets confused and can't complete the task. Even among those who are pretty competent with tech, lots of them still have a limited grasp of the features the browser provides. I can't count how many people who were pretty comfortable using computers who had no idea that the Ctrl+F/"find in page" browser functionality existed, until I showed them.

The relevance of this is that we need to think about this through the eyes of the average user, not the power user with keyboard shortcuts and custom scripts and custom CSS at their disposal. If the "print" or "permanent link" button annoys an editor, that editor can hide it with a line in their personal CSS or JS file, or through a Preferences checkbox if available. Conversely, if a less tech savvy user wants to print or cite a page, they may not realize that you can print through browser functionality hidden inside a menu that's not usually visible, or via Ctrl+P. Even if they understand that you can get to a permanent link by clicking "view history", they're very likely to get confused by the literally hundreds of links on that page, with confusing and opaque linktext.

TL;DR: what seems obvious to power users is not obvious to the gen pop. Don't just think about your workflow, think about how your 70 year old grandparents would use Wikipedia. CJK09 (talk) 18:24, 22 April 2020 (UTC)
 * ✅. Improving the sidebar is at some level necessarily going to require making changes that users will just have to deal with adjusting to, but we should be keeping at top of mind throughout this process. &#123;{u&#124;  Sdkb  }&#125;  talk 06:05, 23 April 2020 (UTC)

I agree decisions on sidebar links should be made with readers in mind. In fact, this is the crux of my argument for removing the "permanent link" button; it is likely to be used by only a few readers (for the vast majority, a link to a current, updated version is suitable). The bulk of its usage comes from experienced editors reporting issues. Most of the readers who want a permanent link will likely be looking to complete a citation, a function duplicated by the link to "cite this page". If we read through the ensuing discussion, many opposers are motivated by disruption to the experienced editor's, rather than the reader's, experience. – Teratix ₵ 04:32, 29 April 2020 (UTC)

Display strings
Thanks for pointing out MediaWiki:Sidebar in the intro to this RFC. Entries on the right of the pipe like "mainpage-description" look like they would cause a lookup based on the user's interface language preference. Could someone say where these are stored? Is it the same for headings like "interaction"? Pelagic (talk) 22:07, 23 April 2020 (UTC)
 * The right hand entries are message keys. "mainpage-description" means fetch the message with that key. The fetched message will defend on the user/or site language. For instance, for French it will return MediaWiki:Mainpage-description/fr. – Ammarpad (talk)
 * Thanks, Ammarpad! (no ping, but Echo thanks sent from diff page) Pelagic (talk) 20:56, 24 April 2020 (UTC)

Link destinations
Some entries in MediaWiki:Sidebar on the left of the pipe look like regular wikilinks, e.g. "Wikipedia:About", but others seem to have a level of indirection, e.g. "sitesupport-url". Where are the name-to-link mappings stored? Pelagic (talk) 22:07, 23 April 2020 (UTC)
 * The entries with a level of indirection are stored in the corresponding page in the MediaWiki namespace. Ex, the URL for the donate button is at MediaWiki:Sitesupport-url. * Pppery * <sub style="color:#800000">it has begun... 01:35, 24 April 2020 (UTC)
 * Thanks, Pppery! (no ping, but thanked from diff page) Pelagic (talk) 20:56, 24 April 2020 (UTC)

Tools
I understand that this RFC is about what we want, and that how to implement the consensus is a separate step. But I'm curious what would be involved. Tools, languages, etc. appear to come from somewhere different to the Navigation and Interaction sections. Will modifying the tools (sensu lato) require forking the Vector skin? Is there a separate file that simply specifies the sidebar tools, or will it mean diving into the HTML and PHP? Pelagic (talk) 22:07, 23 April 2020 (UTC)
 * The text and tooltips of the Tools links, as well as the section names, are simple Mediawiki messages that can be edited. For overall Tools content, I suspect the outcome of this will be that long-term the devs set up a system for editing Tools, and short-term we just add duplicates of the Tools links where they should go and hide the originals with CSS. (Each item has its own ID.) Changing the ordering of the sections like "In other projects" will probably need to be done on the PHP side. --Yair rand (talk) 19:02, 27 April 2020 (UTC)

Comparison to other projects and languages
Moving this to a sub-page so that it doesn't swamp this one: /Comparison. Pelagic (talk) 14:13, 25 April 2020 (UTC)
 * Thanks for putting together that comparison! Do you see any ideas from other projects/languages that we might want to adopt here, or any trends we might want to take into consideration? &#123;{u&#124; Sdkb  }&#125;  talk 01:14, 26 April 2020 (UTC)
 * Good question, . I have another table which is more informative.  I'll add it later today when I get to a decent desktop PC where copying large blocks of text is more comfortable than on a tablet.
 * A couple of things come to mind, which will make more sense once that info is in place...
 * Some wikis have significantly fewer sidebar links than we do at en-wp, but a lot have similar numbers (11–14 above the tools).
 * I feel that what makes the difference between approachable and confusing is having them in logical groups, keeping those groups small (4–5 items max).  So the discussions we're having above about moving item A from group X to group Y are worthwhile, in my view. I'd also like us to seriously consider ways that we can split larger groups.
 * Zh has a sidebar item for "Five Pillars", and a few languages (e.g. fr) have some kind of "getting started".
 * How effective is it to do single entry points for (each of) Help and About? Do people find it overwhelming when they click/tap through to those pages?  Are there certain types of instruction that we want to highlight more prominently by giving them separate entries in the sidebar?
 * If you have a look at the Teahouse and Helpdesk, a of questions are like "how do I get my Wikipedia page?" or "how do I promote my company on wiki for the SEO?" or other fundamental misunderstandings about what Wikipedia is and isn't. Would an FAQ help?  (Or is there a fundamental disjoint between the type of people (like me) who read FAQs, and the type who really  read them?)  It would be useful to know how people arrive at those venues: is it via Help / About / Community Portal (and did they start from the sidebar?), or is it from welcome templates, or comments/messages from volunteers doing AFC/NPP?
 * I'd better leave off at this point, I've written too much already. Pelagic (talk) – (06:41 Mon 04, AEST) 20:41, 3 May 2020 (UTC) Fixed formatting. Pelagic (talk) – (06:49 Mon 04, AEST) 20:49, 3 May 2020 (UTC)
 * I think the Wikipedias with fewer links are on the right path. Logical groupings help a bit, but the main approach I wish we would take would be autocollapsing. Unfortunately, my proposal above looks unlikely to pass (I think a lot of the opposition is a mix of not having read 's excellent note above, not understanding how important reducing clutter is for good design, and not noticing that the proposal is basically only for logged out users at this point). The WMF is working on it anyways, and perhaps they'll have better luck.
 * Re question 2, see the proposal above to add an introduction to contributing link. I think Help:Contents is useful. WP:About is a mess that badly needs to be re-written, but there is a clear use for an introduction page for readers and it's definitely appropriate to have such a page in the sidebar. Cheers, &#123;{u&#124; Sdkb  }&#125;  talk 21:44, 3 May 2020 (UTC)

Follow-up
&#123;{u&#124; Sdkb  }&#125;  talk 02:31, 7 October 2020 (UTC)

Requests for comment/2020 left sidebar update was recently closed by and, and most of the results have been implemented. A huge thank-you to everyone who participated! Per the close, several items require follow-up due to low participation or lack of consensus. I am opening this discussion as a space for those discussions to take place. It is being transcluded to the WP:SIDEBAR20 page and will be moved there when it concludes. &#123;{u&#124; Sdkb  }&#125;  talk 06:47, 12 June 2020 (UTC)

Introduction page
The RfC found consensus to add an introductory page for new editors, but asked for further discussion on the details.

Link
Previously discussed options: Help:Introduction (5 !votes), Contributing to Wikipedia (1 !vote), and The Wikipedia Adventure (1 !vote)


 * Support Help:Introduction. To put it simply, this is our best introduction. It's where the deprecated Introduction now redirects and was made the primary link in the standard welcome template. It covers all the basics without going into unnecessary detail. It is mobile-friendly and accessibility-compliant. It follows the usability best practice of splitting information into easily digestible bite-sized chunks, rather than a single overwhelming page (although it has an option to be viewed as such if one wants). It's the preferred choice of the WMF Growth Team's product manager. It's being actively maintained and is overall ready for inclusion on the sidebar. &#123;{u&#124; Sdkb  }&#125;  talk 06:47, 12 June 2020 (UTC)
 * Support any page that is not Help:Introduction a huge 66 page tutorial that is not user friendly. |Help:Introduction|Help:Introduction_to_Wikipedia|Help:Introduction_to_policies_and_guidelines/1|Help:Introduction_to_editing_with_Wiki_Markup/1|Help:Introduction_to_editing_with_VisualEditor/1|Help:Introduction_to_navigating_Wikipedia/1 Stats show us that almost no-one is clicking the non-action action buttons to learn more so why send even more there???. The fact someone from the WMF with less then 350 edits and zero edits  in the help namespace likes the page should be a big red flag...last thing we need is another non experienced WMF member telling us what is best.-- Moxy 🍁 11:14, 12 June 2020 (UTC)
 * The WMF Growth Team is literally the team in charge of new user retention. They're not trying to force anything on us (I was the one who sought out their opinion), but I trust that they know what they're talking about when they say We think that help pages are better when they have a fewer number of links and options -- too many can be overwhelming. In that vein, I think that WP:Contributing to Wikipedia would likely overwhelm, and Help:Introduction would be better. As for the traffic stats, most people come to the page looking for help doing a specific thing and then click on the page relevant to that. Since there are 13 pages linked, of course none individually will be getting as much traffic as the portal. There's also the general 1% rule of the internet to consider. Even the custom-designed newcomer tasks feature only results in 9% of newcomers coming back after 3 days (compared to a baseline 4-5%), so keeping them around is a huge challenge. The stats for the Wikipedia Adventure are similar, and while we don't know how many people who visit WP:Contributing to Wikipedia actually read to the bottom of the page, my guess is that it's shockingly low. &#123;{u&#124; Sdkb  }&#125;  talk 15:25, 12 June 2020 (UTC)
 * Yup same team that brought us VE.-- Moxy 🍁 15:32, 12 June 2020 (UTC)
 * The team was formed in 2018, so no. &#123;{u&#124; Sdkb  }&#125;  talk 15:58, 12 June 2020 (UTC)
 * I guess I should have been more specific..old timers will understand-- Moxy 🍁 17:35, 12 June 2020 (UTC)

— Note: An editor has expressed a concern that editors have been canvassed to this discussion. (diff)
 * Support Help:Introduction. Although I don't disagree it is quite voluminous, it covers all the necessities in a fairly well-structured manner and I used it myself for getting started. 5225C (talk &bull; contributions) 13:02, 12 June 2020 (UTC)
 * Support The Wikipedia Adventure as I did in the previous discussion. I'm aware of accessibility criticisms and I'm even aware of data that suggests TWA doesn't improve editor retention (though I can't find the place where I read that a few years ago). However, the purpose of the link should be to get people thinking about becoming an editor—it's before the retention period, the part where we need to show them something just interesting enough to get them to make an account. I don't want another dry link with 400 subpages, none of which actually give me something to start editing or give me enough information to have my first edit not be immediately reverted. Barring TWA, I don't believe we have a page suitable for purpose but I would support Help:Introduction as a second and support any other page as better than nothing. — Bilorv (  Black Lives Matter  ) 13:21, 12 June 2020 (UTC)
 * Support Contributing to Wikipedia Its a one page, one stop wonder. Already well trafficked, lots of videos (which new users are always asking for), and long enough to be actually useful. I would also support Help:Introduction to Wikipedia, but would strongly oppose just Help:Introduction, as it is full of ...meaningless links for newbies, and already confuses folks with the VE/source distinction, and there are plenty more useful pages. CaptainEek  Edits Ho Cap'n!⚓ 14:39, 12 June 2020 (UTC)
 * <Small>I informed all that were in prior discussions even the ones that like your page. If I missed any fell free to inform..-- Moxy 🍁 17:35, 12 June 2020 (UTC)


 * Support, first preference: Contributing to Wikipedia, second preference Help:Introduction, third anything else. MER-C 16:54, 12 June 2020 (UTC)
 * Support The Wikipedia Adventure. I find this to be the most beginner friendly page on Wikipedia because it goes in depth into what contributing is like. The majority of editors who help out the newcomers recommend that particular tutorial and I agree with them. Interstellarity (talk) 17:34, 12 June 2020 (UTC)
 * With 50 views a day its clear most do not send people there. The |Wikipedia:TWA/1/Start|Wikipedia:TWA/2/Start|Wikipedia:TWA/3/Start Wikipedia:Adventure has more then a  50 percent drop in views by the second page....with a loss of 90 percent by page 3. Not as bad as Help:Introduction but close.-- Moxy 🍁 17:42, 12 June 2020 (UTC)


 * Support Wikipedia Adventure as I think Bilorv makes the best case. As the most prominent link for readers, we want to convert them to editors as fast as possible. For all the problems of TWA, it's best feature is that it gets readers editing quickly without having to read an entire manual. We can fix the other problems as we go along, and with added urgency given its prominent placement. Support the others as better than nothing. — Wug·a·po·des​ 19:18, 12 June 2020 (UTC)
 * Support TWA. It's where I'd send new editors, without a doubt; it's clear, concise, to-the-point, and engaging as a tutorial of how the site works technically as well as in policy, working with both in a hands-on environment. This approach is well-tested on other sites - indeed, it's what the onboarding experience looks like on many popular social media platforms - and it works in keeping people engaged throughout, making people less likely to skip the "boring policy bits" because they're actively doing something. Naypta ☺ &#124; ✉ talk page &#124; 19:43, 12 June 2020 (UTC)
 * I tried TWA recently and had high hopes for it, since the graphics are definitely nice and the interactivity is a plus. But I came away from it concluding that there are just too many problems, and those problems are too hard to address given how rigidly it's built. To list them out:
 * The JavaScript that keeps track of where you are is very buggy; several times it lost my place and I had to go back to the start of the module. Every time that happens, it's a potential exit point for someone to decide to give up.
 * It displays terribly on mobile, which loses us half of all potential editors right off the bat (and probably more in developing areas).
 * It's not accessibility-compliant, which introduces further issues of discrimination.
 * It's longer than Help:Introduction without really covering anything important that H:I doesn't, and it doesn't touch on all the most important things right off the bat the way H:I does. I don't think most newer editors will have that much patience.
 * There's no instruction on VisualEditor, and while that may not be what we all use, for newer editors it's a very important transition aid.
 * The juvenile tone seems to be okay with some people but very off-putting to others. We can be friendly without being juvenile, and I think H:I strikes a better balance.
 * Putting all those together, they add up to a dealbreaker for generalized use, and they would require a ton of work to solve. By comparison, expanding the sandbox elements for H:I into something more fully interactive would not be hard (I might work on it later today). &#123;{u&#124; Sdkb  }&#125;  talk 20:34, 12 June 2020 (UTC)
 * As I said in my original comment, I'm aware of its problems. These are all things that can (and should) be fixed. Despite that, the most important function of this link is getting readers to make an edit, not teaching them rules. For its problems, TWA's really good at that. — Wug·a·po·des​ 20:47, 12 June 2020 (UTC)
 * I agree on that point. I think the very best thing is to present newcomers with easy edits to make on Wikipedia itself, since it's infinitely more satisfying to make a live edit than one to a sandbox. That's what the Newcomer Tasks feature the WMF is developing will hopefully do extremely well, and we'll want to integrate it once it goes live. For some things, though, a quiz/sandbox environment is best. I've opened up a discussion at H:I and we'll work on adding more of those features; help is welcome from anyone who wants to contribute. Cheers, &#123;{u&#124; Sdkb  }&#125;  talk 21:25, 12 June 2020 (UTC)refactored 22:42, 12 June 2020 (UTC) to link to discussion
 * I think the points you raise here are definitely important ones. It ought to be possible for an interface admin to add code to MediaWiki:Guidedtour-tour-twa1.js that would automatically redirect mobile users from TWA to H:I, and for accessibility, it might be a good idea to add markup to the top of the page offering H:I as a more accessible alternative. One other option might be to have a choice - something like the below:Welcome to Wikipedia! Would you like to read a short, accessible introduction to editing Wikipedia, or learn interactively how to edit Wikipedia by taking a tour of the site?
 * That could then redirect mobile users automatically to H:I as described above. Naypta ☺ &#124; ✉ talk page &#124; 21:22, 12 June 2020 (UTC)
 * Closer's note: I had to remove a template from the above comment because it was interfering with archive templates. The code of the original comment was signed,Rosguill talk 22:22, 21 September 2020 (UTC)
 * Support Help:Introduction - TWA's format makes it difficult for a new editor to jump to exactly the information they need. Plus, the whole concept of an interactive "adventure" would be offputing and distracting for many newcomers. While Help:Introduction is far from perfect, it is clearly the better option, and it's a lot easier to iterate on and improve. - <span class="nowrap" style="font-weight:bold;font-size:85%;transform:rotate(358deg);display: inline-block;">Axisixa T   C  22:00, 12 June 2020 (UTC)
 * The proposals are dreadful—design-by-committee with every second word linked and pointless decorations. • Help:Introduction might be ok if each button led to a single page of information. However, few people want to dive into a labyrinth where you never know if you've missed vital points, and later you can never find anything you vaguely recall seeing. • WP:TWA would be suitable for, umm, certain levels of potential editors but a sidebar link should be for useful information you might want to see more than once. • Wikipedia:Contributing to Wikipedia is the best but has too much waffle. There should be a short page with core facts and many fewer links (something that can be searched after a first read), with links to the proposals here. Johnuniq (talk) 01:52, 13 June 2020 (UTC)
 * H:E is shorter then WP:CTW and just about additions ...not sure why so many think new editors will read over 50plus pages to learn anything considering the data we have about them ...odd very odd to me.- Moxy 🍁 12:23, 13 June 2020 (UTC)


 * Only support something that makes it clear in the first few sentences that Wikipedia is an encyclopedia based upon what reliable sources say about a subject and that editors' opinions and knowledge/expertise are not to be used. This could be followed by something short about reliable sources, being a mainstream encyclopedia and about original research. Doug Weller  talk 11:15, 14 June 2020 (UTC)
 * Support Quickstart – not sure about anybody else, but I just try out my new phone, program, tv remote, without reading the manual, or only after briefly scanning it. Maybe later, after I can't turn the phone off, or find Netflix, will I go to the manual (and then, slightly annoyed that the user interface is so poorly designed, that it isn't self-evident). I support an introduction that can fit on 3/4 of a laptop page and takes about a minute to scan. As a new Wikipedia editor, I just want to edit something, anything, to see how it works, and then learn by doing; not spend time reading endless explanations, and trying to remember what I read forty pages ago, and whether that was more important.  I'll get to reading all that later, after I've got some experience. Remember learning to ride a bike? The manual is for explaining how to adjust your seat height, attach a lamp, or change a tire; it's not about teaching you how to ride on two wheels. Mathglot (talk) 09:35, 16 June 2020 (UTC)
 * The first content page of Help:Introduction, Help:Introduction to Wikipedia, is basically what you're describing. &#123;{u&#124; Sdkb  }&#125;  talk 10:22, 16 June 2020 (UTC)
 * Support Wikipedia Adventure great for younger editors. — 104.249.229.201 (talk) has made no other edits. The preceding unsigned comment from a Canadian IP address was added at 05:50, 17 June 2020 (UTC).
 * Support Help:Introduction it is easy to use and looks good. --Tom (LT) (talk) 07:41, 21 June 2020 (UTC)
 * Update: Following up for those here who haven't clicked through to the Help:Introduction discussion, we've added a slew of interactive components, including custom sandboxes, quizzes, and invitations to make easy live edits to articles through tools like Citation Hunt. We're planning on adding a few more quizzes, and as mentioned above the interactivity will get a further boost once the new Growth Team features are implemented, but I hope the present efforts will be enough to satisfy the concerns of some of those who opted for TWA above and perhaps resolve the deadlock we seem to currently be at. &#123;{u&#124; Sdkb  }&#125;  talk 06:11, 1 July 2020 (UTC)
 * Support Help:Introduction, other pages have too many paragraphs, poor structure, and are too daunting. It keeps annoying me how we have dozens of introduction/"read this" pages, which are all so long, and then we try to create simplified versions of these but they're also so long, but also not comprehensive enough so you end up needing to read the even longer one anyway. Help:Introduction pretty much gets the point across and looks less scary. And as a sidenote, would like to say thanks to Sdkb's for their broad and important work to make Wikipedia easier to access for new editors. ProcrastinatingReader (talk) 13:04, 6 July 2020 (UTC)

Label and tooltip
''Previously discussed label options: "Tutorial" and "Editing tutorial". Previously discussed tooltip option: "Learn how to edit Wikipedia".''


 * Support Tutorial, with "Learn how to edit Wikipedia" as tooltip. The renaming of the section where this will presumably be located to "contributing" makes it clear that this is an editing tutorial, not a tutorial on how to read Wikipedia, so we should go with the shorter label for conciseness. No one has raised any concerns about or suggested any alternatives for the previously discussed tooltip. &#123;{u&#124; Sdkb  }&#125;  talk 06:47, 12 June 2020 (UTC)
 * Support Tutorial, with "Learn how to edit Wikipedia" as tooltip per Sdkb's reasoning. 5225C (talk &bull; contributions) 13:02, 12 June 2020 (UTC) 5225C (talk &bull; contributions) 23:53, 12 June 2020 (UTC)
 * In the new condensed sidebar there's less chance of the link getting lost, but I'd still prefer something very in-your-face as a label. I like an idea alluded to by here: "Start editing". Or "Learn to edit". (As a tooltip, "Learn how to edit Wikipedia" or similar would be fine.) As a last resort, I'd prefer "Editing tutorial" to "Tutorial". (Who reads the section title? People navigate much more non-linearly than that. I want to know what a link is the instant I look at it, no contextual clues needed.) — Bilorv (  Black Lives Matter  ) 13:09, 12 June 2020 (UTC)
 * I like "Learn to edit" a lot — it gives a nice call to action. "Start editing" would imply that you're making actual edits during the tutorial, which isn't the case apart from the sandboxes. &#123;{u&#124; Sdkb  }&#125;  talk 16:33, 12 June 2020 (UTC)
 * Support - first preference: "Learn to edit", then "Tutorial". MER-C 16:56, 12 June 2020 (UTC)
 * Learn to edit for label since it's short and actionable; no strong opinions on the tool tip. — Wug·a·po·des​ 19:20, 12 June 2020 (UTC)
 * Learn to edit per seems best to me. Tutorial isn't quite as clear - tutorial of what? Especially for an educational site, for people for whom English is not their native language, that could potentially lead to confusion. "Learn to edit" is clear in intent and action. For the tooltip, "Learn how to edit Wikipedia" seems good. Naypta ☺ &#124; ✉ talk page &#124; 19:43, 12 June 2020 (UTC)
 * Support "Learn to edit" with "Learn how to edit Wikipedia" as the tooltip. 5225C (talk &bull; contributions) 04:21, 14 June 2020 (UTC)
 * Learn to edit. Simple and straightforward --Tom (LT) (talk) 07:41, 21 June 2020 (UTC)

Positioning
Previously discussed option: Contribute section, just below Help.


 * Support previously discussed option. This seems like the logical placement, and no one has raised any concerns about it or suggested any alternative. &#123;{u&#124; Sdkb  }&#125;  talk 06:47, 12 June 2020 (UTC)
 * Support placement below Help as the logical spot. 5225C (talk &bull; contributions) 13:02, 12 June 2020 (UTC)
 * Above help, as the first thing under "Contribute" should be something that leads me somewhere where I will learn to contribute. — Bilorv (  Black Lives Matter  ) 13:22, 12 June 2020 (UTC)
 * Immediately below help, please. MER-C 16:57, 12 June 2020 (UTC)
 * Below help. --Tom (LT) (talk) 07:41, 21 June 2020 (UTC)
 * Below help. ProcrastinatingReader (talk) 14:20, 6 July 2020 (UTC)

Current events tooltip
''Previously discussed options: "Find background information on current events" (status quo, 0 !votes), "Articles related to current events" (2 !votes), and "Articles on current events" (1 !vote).


 * Support "Articles related to current events", since "on" would imply that we're writing news articles, which we're not, especially in cases like recent deaths. &#123;{u&#124; Sdkb  }&#125;  talk 06:47, 12 June 2020 (UTC)
 * Support "Articles related to current events", per Sdkb and for clarity with WP:NOTNEWS. 5225C (talk &bull; contributions) 13:02, 12 June 2020 (UTC)
 * Support "Articles related to current events" as above. — Bilorv (  Black Lives Matter  ) 13:23, 12 June 2020 (UTC)
 * Per above — Wug·a·po·des​ 19:23, 12 June 2020 (UTC)
 * Comment as previous closer: As I had indicated to Sdkb when discussing the close previously their reducing discussion to a strict vote (as indicated in the summary introduction to this section) is not consistent with policy or practice. I would encourage anyone considering a close of this section to read the previous discussion - it's short so won't take long - rather than merely accepting the !vote summary produced here as a vote summary. Best, Barkeep49 (talk) 23:14, 15 June 2020 (UTC)
 * Articles related to current events. This is a very clear description of what the page contains. --Tom (LT) (talk) 07:41, 21 June 2020 (UTC)

Community portal tooltip
''Previously discussed options: "About the project, what you can do, where to find things" (status quo, 0 !votes) and "The hub for editors" (2 !votes)


 * Support "The hub for editors". This concisely sums up the portal's role. &#123;{u&#124; Sdkb  }&#125;  talk 06:47, 12 June 2020 (UTC)
 * Weak support for "The hub for editors", since I have no viable alternative. 5225C (talk &bull; contributions) 13:02, 12 June 2020 (UTC)
 * Comment as previous closer: As I had indicated to Sdkb when discussing the close previously their reducing discussion to a strict vote (as indicated in the summary introduction to this section) is not consistent with policy or practice. I would encourage anyone considering a close of this section to read the previous discussion - it's short so won't take long - rather than merely accepting the !vote summary produced here as a vote summary. Best, Barkeep49 (talk) 23:15, 15 June 2020 (UTC)

Miscellaneous discussion

 * There were several other proposed tooltip changes that got very little discussion and closed as no consensus. I don't want to overwhelm this discussion by creating a section to follow up on each of them, but I'll just throw them out here, and if they turn out to be uncontroversial, perhaps we can find consensus to implement them. They are:
 * For Special pages, change from "A list of all special pages" to "List of automatically generated pages for specialist purposes"
 * For Page information, change from "More information about this page" to "Technical information about this page"
 * For View user groups, change from nothing to "view the permissions of this user" (for non-admins) and "manage the permissions of this user" (for admins)
 * How do those sound? &#123;{u&#124; Sdkb  }&#125;  talk 06:47, 12 June 2020 (UTC)
 * The suggested extra wording for special pages and page information does not help, the original wording is good. For user groups, I don't see why different text for admin/non-admin users is needed, just "Permissions of this user" would be fine (that's all that is needed for a hint about what groups do). Johnuniq (talk) 07:27, 12 June 2020 (UTC)
 * I concur with Johnuniq regarding special pages. Although the current tooltip is pretty useless, the proposal seems far too long. I would instead propose "List of pages for specialised purposes" to cut out some unnecessary elaboration and to clarify that special pages are for particular uses, not particular users. I support the proposed changes for page information and user groups, they seem to clarify their respective purposes quite well. 5225C (talk &bull; contributions) 13:02, 12 June 2020 (UTC)
 * I'd like "List of system pages" for "Special pages", because that's effectively what it is. Support the other suggestions. Naypta ☺ &#124; ✉ talk page &#124; 19:46, 12 June 2020 (UTC)
 * "List of system pages" sounds good to me. &#123;{u&#124; Sdkb  }&#125;  talk 06:31, 22 June 2020 (UTC)


 * Support all three: "A list of automatically generated pages for specialist purposes" ,"technical information about this page", and "view the permissions of this user." All three proposals make it more clear and are more accurate about what the targets do. In the past I have been confused by the titles and I think these tooltips would have helped. --Tom (LT) (talk) 07:41, 21 June 2020 (UTC)

Sidebar in mobile view
All of the discussion on the sidebar has been about the sidebar in desktop view. I think we should also discuss how we can improve the sidebar in mobile view. Do you have any opinions on how we can do that? Interstellarity (talk) 20:49, 12 June 2020 (UTC)
 * , I think we could certainly have a discussion analogous to WP:SIDEBAR20 for mobile. My sense is that the WMF has been more heavily involved with that than they have been with the desktop view, so it might be good to start at the idea lab and research the background. There are also other discrepancies such as the fact that mobile makes it very easy to see a user's edit count whereas desktop mostly hides it; we could talk more about those at WP:Usability. &#123;{u&#124; Sdkb  }&#125;  talk 21:32, 12 June 2020 (UTC)

Tidying up the sidebar
I recently had an edit request declined at MediaWiki_talk:Sidebar that should tidy up the sidebar a little bit. I think it is best that we seek consensus for this change. Pinging if he would like to comment. Interstellarity (talk) 11:08, 19 June 2020 (UTC)
 * Perhaps you could explain what you propose here so others can comment, as you suggest.--Tom (LT) (talk) 07:41, 21 June 2020 (UTC)
 * What I would like to do is on MediaWiki:Sidebar, I would like to change the bullet point from * interaction to * contribute? Then, on MediaWiki:Interaction, I would like to move the page to MediaWiki:Contribute? That is what I would like to do. Interstellarity (talk) 12:13, 21 June 2020 (UTC)