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. {{u| Sdkb}}  ^talk 21:46, 10 April 2020 (UTC) reply
• 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) reply
• Support seems reasonable enough. Semi Hyper cube 22:32, 10 April 2020 (UTC) reply
• Support, except that I think "Special pages" should stay within Tools. —⁠ 烏⁠Γ ^{( kaw)} │ 22:50, 10 April 2020 (UTC) reply
• 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) reply
• 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  ^{dubious – discuss} 23:16, 10 April 2020 (UTC) reply

  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, {{u| Sdkb}}  ^talk 23:31, 10 April 2020 (UTC) reply

• 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) reply
• Support a great idea.-- Tom (LT) ( talk) 00:12, 11 April 2020 (UTC) reply
• 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) reply
• Weak support – subject to technical feasibility, including not negatively impacting other skins - Evad37 [ talk 01:53, 11 April 2020 (UTC) reply
• 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) reply
• 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) reply
• Support reasonable proposal per above. -- Puddleglum ^2.0_{( How's my driving?)} 19:19, 12 April 2020 (UTC) reply
• Support. Should improve navigability. -- Yair rand ( talk) 20:36, 12 April 2020 (UTC) reply
• Support if technical difficulties can be overcome. Kirbanzo ^{( userpage -  talk -  contribs)} 21:40, 12 April 2020 (UTC) reply
• Support more logical + easier to find stuff. b uidh e 23:32, 12 April 2020 (UTC) reply
• Support with "special pages" in tools. Contribute is a much more logical header than Interaction. — pythoncoder ( talk |  contribs) 00:20, 13 April 2020 (UTC) reply
  • Although as I look at it more, "Help" also has information for readers too.... — pythoncoder ( talk |  contribs) 00:42, 13 April 2020 (UTC) reply
• Support it's a small improvement, but an improvement nonetheless. Thanks for proposing this! Ajpolino ( talk) 16:52, 13 April 2020 (UTC) reply
• 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) reply
• Support, looks good. Utopes _{( talk / cont)} 22:54, 14 April 2020 (UTC) reply
• 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) reply
• Support, clear improvement assuming technical feasibility. – Tera tix ₵ 12:57, 18 April 2020 (UTC) reply
• 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) reply
• 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) reply
• 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) reply
• 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) reply
• Support. These changes should help Jcoolbro ( talk) 16:48, 23 April 2020 (UTC) reply
• 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. Reywas92 ^Talk 19:41, 24 April 2020 (UTC) reply
• Support Definite improvement, though would prefer Special pages in 'Tools'. Nick Moyes ( talk) 07:29, 26 April 2020 (UTC) reply
• 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 | my contributions} 21:31, 26 April 2020 (UTC) reply
• Support, this seems to simplify it well.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• Support. Anarchyte ( talk • work) 10:08, 27 April 2020 (UTC) reply
• 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) reply
• Support - As others have stated, it would delineate things much more clearly for new users. - Axisixa T C 03:46, 28 April 2020 (UTC) reply
• Support - All looks good and sensible to me. -- The Anome ( talk) 15:17, 29 April 2020 (UTC) reply
• 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) reply
• Support. "Contribute" is a much stronger call to action than "Interaction". —  Newslinger  talk 09:27, 11 May 2020 (UTC) reply
• Support. Except "Special pages" under Tools. As per Wugapodes above. comrade waddie96 ( talk) 08:50, 14 May 2020 (UTC) reply

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 * _{it has begun...} 23:38, 10 April 2020 (UTC) reply

@ Pppery: 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. {{u| Sdkb}}  ^talk 23:51, 10 April 2020 (UTC) reply

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  ^{dubious – discuss} 00:11, 11 April 2020 (UTC) reply

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. — pythoncoder ( talk |  contribs) 00:37, 13 April 2020 (UTC) reply

SGrabarczuk (WMF), if there is consensus here, would you or someone else at WMF be able to assist with implementation? {{u| Sdkb}}  ^talk 05:05, 11 April 2020 (UTC) reply

This would be a great use case for phab:T249673 I think DannyS712 ( talk) 06:31, 11 April 2020 (UTC) reply

How is this meant to work in other skins like Timeless?

• View this page in the skin:
  
  • MinervaNeue (mobile)
  • MonoBook
  • Timeless
  • Vector legacy (2010)
  • Vector (2022)
• View Funabashi (city) in the skin:
  
  • MinervaNeue (mobile)
  • MonoBook
  • Timeless
  • Vector legacy (2010)
  • Vector (2022)

- Evad37 [ talk 01:00, 11 April 2020 (UTC) reply

@ Evad37: 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. {{u| Sdkb}}  ^talk 01:12, 11 April 2020 (UTC) reply

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 [ talk 01:27, 11 April 2020 (UTC) reply

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

@ ~riley: I was going off what Sdkb 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 [ talk 14:25, 11 April 2020 (UTC) reply

@ Evad37 and ~riley: 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. - {{u| Sdkb}}  ^talk 17:43, 11 April 2020 (UTC) reply

@ Evad37 and Sdkb: 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) reply

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

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 #Technical underpinnings). 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) reply

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

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

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

@ AHollender (WMF): 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 Wugapodes'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. {{u| Sdkb}}  ^talk 07:36, 15 April 2020 (UTC) reply

• 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) reply

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) reply
• Support. Wikidata is a project. —⁠ 烏⁠Γ ^{( kaw)} │ 07:44, 14 April 2020 (UTC) reply
• Weak oppose per AHollender's rationale. {{u| Sdkb}}  ^talk 04:40, 15 April 2020 (UTC) reply
• Oppose. The "In other projects" already has a Wikidata link if a page has an equivalent in Wikidata. For example, Wikipedia: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) reply
  • How does that work? I've never noticed it in article space. Pelagic ( talk) 21:22, 20 April 2020 (UTC) reply
    • @ Pelagic: 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) reply
      • 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, Yair rand. It creates a tricky edge case. Pelagic ( talk) 20:52, 21 April 2020 (UTC) reply
• Oppose per AHollender and Peter James. – Tera tix ₵ 12:58, 18 April 2020 (UTC) reply
• 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. {{ replyto}} Can I Log In's (talk) page 03:29, 20 April 2020 (UTC); edited 06:04, 20 April 2020 (UTC) reply
• Support, as you're looking at the topic from another project's view. >> BEANS X2 t 12:29, 20 April 2020 (UTC) reply
• (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) reply

  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.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• I would like to but...: I would like to see this change, in principle. But after reading Peter James' concerns, I think this is something that would require more thought about the right UX. -- MarioGom ( talk) 18:45, 27 April 2020 (UTC) reply
• 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) reply
• 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) reply

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

• 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) reply

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) reply
• Support, makes sense. Utopes _{( talk / cont)} 23:23, 14 April 2020 (UTC) reply
• Support sounds fine to me. {{u| Sdkb}}  ^talk 04:42, 15 April 2020 (UTC) reply
• Support logical. – Tera tix ₵ 14:09, 18 April 2020 (UTC) reply
• 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) reply
• Support, great suggestion. Nouill ( talk) 11:48, 26 April 2020 (UTC) reply
• Support keeps similar links together. Makes sense. Dreamy Jazz 🎷 ^{talk to me | my contributions} 21:34, 26 April 2020 (UTC) reply
• Support for consistency and readability.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• Support, yes, please. This is pretty obvious. -- MarioGom ( talk) 18:48, 27 April 2020 (UTC) reply
• Support - Provided it is technically feasible. - Axisixa T C 03:46, 28 April 2020 (UTC) reply

Discussion (move In other projects)

"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) reply
• 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) reply
• Oppose per Utopes. {{u| Sdkb}}  ^talk 04:32, 15 April 2020 (UTC) reply
• @ Utopes: 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) reply
• Don't see a need to divide just for userspace. ~ Amory ( u • t • c) 09:57, 20 April 2020 (UTC) reply
• Support the term Page Tools as suggested by AHollender (WMF) 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) reply
• Support - The Tools section can get unwieldy in userspace, and I am not even an administrator. - Axisixa T C 03:46, 28 April 2020 (UTC) reply

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) reply
  • 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) reply

The Desktop Improvement Project 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 #Move "In other projects" under "Print/export" are agreed on, then the order would be: Print/Export, Tools, In other projetcs, Languages. Renata ( talk) 06:27, 21 April 2020 (UTC) reply

Survey (move up print/export)

• Support as proposer. Renata ( talk) 20:05, 18 April 2020 (UTC) reply
• Support strongly. A clear application of WP:READER. {{u| Sdkb}}  ^talk 21:11, 18 April 2020 (UTC) reply
• Support as it's a short section. >> BEANS X2 t 12:35, 20 April 2020 (UTC) reply
• Support both moves, the resulting section order has a nice progression. Pelagic ( talk) 12:32, 21 April 2020 (UTC) reply
• Support pretty much as above. Print/exporting options are more useful to the reader than the tools section. Dreamy Jazz 🎷 ^{talk to me | my contributions} 21:44, 26 April 2020 (UTC) reply
• Support for usability.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• 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) reply

Discussion (move up print/export)

• If both this proposal and the one above, #Move "In other projects" under "Print/export", pass, then we'd have print/export, then tools, then "in other projects, then languages. That seems alright to me. {{u| Sdkb}}  ^talk 22:14, 18 April 2020 (UTC) reply
  • 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". – Tera tix ₵ 01:37, 21 April 2020 (UTC) reply
    • 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) reply

• Support as proposer. It's obvious where the donations will go. {{u| Sdkb}}  ^talk 21:46, 10 April 2020 (UTC) reply
• Support per above. Semi Hyper cube 21:57, 10 April 2020 (UTC) reply
• Support don't see why not.-- Moxy 🍁 22:01, 10 April 2020 (UTC) reply
• Support - This change is in line with the KISS principle. Interstellarity ( talk) 22:17, 10 April 2020 (UTC) reply
• Support, same reasons. I would suggest changing the tooltip to "Support us by donating to Wikipedia". —⁠ 烏⁠Γ ^{( kaw)} │ 22:52, 10 April 2020 (UTC) reply
• Support ~ riley ( talk) 23:03, 10 April 2020 (UTC) reply
• Support Levivich  ^{dubious – discuss} 23:17, 10 April 2020 (UTC) reply
• Good but please make another mock-up that includes the proposed renamings because details matter. Johnuniq ( talk) 23:44, 10 April 2020 (UTC) reply
• Support -- Tom (LT) ( talk) 00:12, 11 April 2020 (UTC) reply
• Support per proposer. – dlthewave ☎ 02:05, 11 April 2020 (UTC) reply
• Support. MER-C 09:18, 11 April 2020 (UTC) reply
• 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) reply
  • @ Samwalton9: 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. {{u| Sdkb}}  ^talk 17:46, 11 April 2020 (UTC) reply
    • Pinging @ Seddon (WMF): Sam Walton ( talk) 19:29, 11 April 2020 (UTC) reply
      • This could be A/B tested. Levivich  ^{dubious – discuss} 05:01, 12 April 2020 (UTC) reply
  • "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 ( u • t • c) 10:01, 20 April 2020 (UTC) reply
• 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) reply
• 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) reply
• Support. -- Yair rand ( talk) 20:36, 12 April 2020 (UTC) reply
• 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) reply
• 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) reply
• Support A/B testing to see which version is more effective. b uidh e 23:44, 12 April 2020 (UTC) reply
• Support - Equally clear with two fewer words. Ajpolino ( talk) 16:52, 13 April 2020 (UTC) reply
• Support, seems clear to me. Utopes _{( talk / cont)} 22:58, 14 April 2020 (UTC) reply
• Support The Department of Redundnacy Department strikes again. CaptainEek ^{Edits Ho Cap'n!} ⚓ 21:59, 17 April 2020 (UTC) reply
• Support per ToBeFree, with Sam Walton's caveat. – Tera tix ₵ 13:00, 18 April 2020 (UTC) reply
• 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) reply
• Support: It's not being donated to Wikipedia. It's being donated to the Wikipedia Foundation. {{ replyto}} Can I Log In's (talk) page 01:04, 20 April 2020 (UTC) reply
• 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) reply
• Support, as conciseness is one of the goals of this RfC. >> BEANS X2 t 12:47, 20 April 2020 (UTC) reply
• Strong support because the donation's aren't only spent on the 'pedias. Pelagic ( talk) 12:26, 21 April 2020 (UTC) reply
• 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) reply

  Thanks for letting us know, Quiddity. This conversation seems ready to close to me if anyone uninvolved wants to go ahead and do so. {{u| Sdkb}}  ^talk 09:59, 22 April 2020 (UTC) reply

• SupportIt is obvious where the donations are going to. Jcoolbro ( talk) 16:52, 23 April 2020 (UTC) reply
• 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 Jazz 🎷 ^{talk to me | my contributions} 21:41, 26 April 2020 (UTC) reply
• Support. The donations aren't used exclusively for Wikipedia anyway.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• Remove link entirely per WP:CANCER. Chris Troutman ( talk) 13:55, 27 April 2020 (UTC) reply
• 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) reply
• 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. - Axisixa T C
• Support ... make it cleaner. Jason Quinn ( talk) 11:53, 2 May 2020 (UTC) reply
• 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) reply

• Support as proposer. Reduces from two words to one. {{u| Sdkb}}  ^talk 21:46, 10 April 2020 (UTC) reply
• Support seems to clarify it. Semi Hyper cube 21:57, 10 April 2020 (UTC) reply
• Support don't see why not.-- Moxy 🍁 22:01, 10 April 2020 (UTC) reply
• Support - This change is in line with the KISS principle. Interstellarity ( talk) 22:17, 10 April 2020 (UTC) reply
• Support, same reasons. —⁠ 烏⁠Γ ^{( kaw)} │ 22:52, 10 April 2020 (UTC) reply
• Support ~ riley ( talk) 23:03, 10 April 2020 (UTC) reply
• Support – I'd also be OK with deleting this link. Levivich  ^{dubious – discuss} 23:17, 10 April 2020 (UTC) reply
• 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) reply
• Support. MER-C 09:18, 11 April 2020 (UTC) reply
• Support Seems reasonable and I like it better GoodCrossing ( talk) 12:43, 11 April 2020 (UTC) reply
• 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) reply
• Support: Not an application store; this is for physical merchandise. ~ ToBeFree ( talk) 03:10, 12 April 2020 (UTC) reply
• Support - Should clear up any confusion on what is being sold there. Kirbanzo ^{( userpage -  talk -  contribs)} 21:38, 12 April 2020 (UTC) reply
• Support - though my first choice would be deleting the link. Ajpolino ( talk) 16:52, 13 April 2020 (UTC) reply
• Support, seems clear about what this refers to. Utopes _{( talk / cont)} 22:59, 14 April 2020 (UTC) reply
• Support per dlthewave. – Tera tix ₵ 13:01, 18 April 2020 (UTC) reply
• Support, as a second preference to removal. — Bilorv ( talk) 18:11, 18 April 2020 (UTC) reply
• Support per dlthewave. the wub "?!" 20:52, 18 April 2020 (UTC) reply
• Support as a second choice per Ajpolino and Bilorv. feminist #WearAMask😷 07:33, 20 April 2020 (UTC) reply
• 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 ( u • t • c) 10:04, 20 April 2020 (UTC) reply
• 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. >> BEANS X2 t 12:48, 20 April 2020 (UTC) reply
• 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) reply
• 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) reply
• Oppose, it sounds a bit commercial and "Wikipedia Store" leaves less place for confusion.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• Support "Store" as that's the name of the page it leads to.-- YTRK ( talk) 13:28, 27 April 2020 (UTC) reply
• 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) reply
• 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) reply
• Support - "Merchandise" isn't ideal, but is better than the current solution, being both more clear and consise. - Axisixa T C 03:46, 28 April 2020 (UTC) reply
• 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) reply

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

• 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) reply

• UK vs US aside, I'm concerned about Merchandise being less universal and less recognizable. -- MarioGom ( talk) 18:59, 27 April 2020 (UTC) reply
• 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) reply

  @ Nemo bis: That's a separate proposal at #Wikipedia store. -- Yair rand ( talk) 17:24, 28 April 2020 (UTC) reply

• Support as proposer. Readers know which site they're on. {{u| Sdkb}}  ^talk 21:46, 10 April 2020 (UTC) reply
• Support per above. Semi Hyper cube 21:57, 10 April 2020 (UTC) reply
• Support don't see why not.-- Moxy 🍁 22:01, 10 April 2020 (UTC) reply
• Support - This change is in line with the KISS principle. Interstellarity ( talk) 22:17, 10 April 2020 (UTC) reply
• Support, same reasons. —⁠ 烏⁠Γ ^{( kaw)} │ 22:52, 10 April 2020 (UTC) reply
  • Oppose; Tony and Wugapodes convinced me otherwise. There is no harm in leaving this, and there potentially is harm in removing it. —⁠ 烏⁠Γ ^{( kaw)} │ 04:18, 11 April 2020 (UTC) reply
• Support or "About us" ~ riley ( talk) 23:03, 10 April 2020 (UTC) reply
  • @ ~riley: I agree. Many websites use those exact words when describing what their website is about. Interstellarity ( talk) 11:21, 11 April 2020 (UTC) reply
    • Oppose About - Support About us. ~ riley ( talk) 08:00, 12 April 2020 (UTC) reply
• Support Levivich  ^{dubious – discuss} 23:17, 10 April 2020 (UTC) reply
• 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) reply
• 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) reply
• 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) reply
• 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) reply
• 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) reply
• Question to the opposers - @ TonyBallioni, Wugapodes, Dlthewave, and GoodCrossing: 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) reply
  • 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) reply
  • About Wikipedia just sounds better. TonyBallioni ( talk) 15:30, 11 April 2020 (UTC) reply
  • 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) reply
    • 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. {{u| Sdkb}}  ^talk 23:55, 11 April 2020 (UTC) reply
      • 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 ( u • t • c) 10:09, 20 April 2020 (UTC) reply
  • I prefer "About Wikipedia". —⁠ 烏⁠Γ ^{( kaw)} │ 06:25, 12 April 2020 (UTC) reply
• Oppose. This change would take away a bit of meaning. — pythoncoder ( talk |  contribs) 00:38, 13 April 2020 (UTC) reply
• 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) reply
• Oppose It's obvious to us, but a newcomer rmight think it referred to the foundation. DGG ( talk ) 00:23, 14 April 2020 (UTC) reply
• 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) reply
• 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) reply
• 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. —{{u| Goldenshimmer}} (they/them)｜ Talk｜ Contributions 03:58, 15 April 2020 (UTC) reply
• 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) reply
• Oppose, ambiguous. – Tera tix ₵ 14:00, 18 April 2020 (UTC) reply
• 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) reply
• 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 ( u • t • c) 10:06, 20 April 2020 (UTC) reply
• Oppose because About Wikipedia is unambiguous; but would support a Wikipedia heading as suggested by Dlthewave, with single-word entries About, Contact, etc. Pelagic ( talk) 12:59, 21 April 2020 (UTC) reply
• Oppose as above just "about" could mean about this page to a reader. Adding Wikipedia stop confusion in this case. Dreamy Jazz 🎷 ^{talk to me | my contributions} 21:47, 26 April 2020 (UTC) reply
• Hesitant support, the phrasing of "About Wikipedia" seems more appealing to me, but this reduces the wordcount a bit.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• 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) reply
• 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. - Axisixa T C 03:46, 28 April 2020 (UTC) reply
• 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) reply

• Support as proposer. There's no need to label this as "page". {{u| Sdkb}}  ^talk 21:46, 10 April 2020 (UTC) reply
• Support "page" is redundant. Semi Hyper cube 21:57, 10 April 2020 (UTC) reply
• Support don't see why not.-- Moxy 🍁 22:01, 10 April 2020 (UTC) reply
• Support - This change is in line with the KISS principle. Interstellarity ( talk) 22:17, 10 April 2020 (UTC) reply
• Support, same reasons. —⁠ 烏⁠Γ ^{( kaw)} │ 22:52, 10 April 2020 (UTC) reply
  • I prefer "Contact us" as well. —⁠ 烏⁠Γ ^{( kaw)} │ 06:28, 12 April 2020 (UTC) reply
• Support ~ riley ( talk) 23:02, 10 April 2020 (UTC) reply
  • Prefer "Contact us" ~ riley ( talk) 07:59, 12 April 2020 (UTC) reply
• Support Levivich  ^{dubious – discuss} 23:17, 10 April 2020 (UTC) reply
• Support – dlthewave ☎ 02:05, 11 April 2020 (UTC) reply
• Support. MER-C 09:47, 11 April 2020 (UTC) reply

  Prefer "Contact us". MER-C 13:01, 11 April 2020 (UTC) reply

• Support, but "Contact us" would sound better. Sandstein 10:47, 11 April 2020 (UTC) reply
  • @ Sandstein: 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) reply
• 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) reply
• Support with preference for "Contact us" per Sandstein.-- Goldsztajn ( talk) 12:54, 11 April 2020 (UTC) reply
• Support "Contact us": That's even the name of the linked page. ~ ToBeFree ( talk) 03:13, 12 April 2020 (UTC) reply
• Support, either "Contact" or "Contact us". -- Yair rand ( talk) 20:36, 12 April 2020 (UTC) reply
• Support. No need for the "page". — pythoncoder ( talk |  contribs) 00:39, 13 April 2020 (UTC) reply
  • I'm okay with either "contact" or "contact us". — pythoncoder ( talk |  contribs) 13:20, 22 April 2020 (UTC) reply
• Support - Agree "Contact" is clearer. Ajpolino ( talk) 16:52, 13 April 2020 (UTC) reply
• Support Contact us as it's pretty much standard across the web. Renata ( talk) 04:54, 14 April 2020 (UTC) reply
• Support Contact us As the universal standard CaptainEek ^{Edits Ho Cap'n!} ⚓ 22:01, 17 April 2020 (UTC) reply
• Support Contact us per ToBeFree, with "contact" as a second choice. – Tera tix ₵ 14:01, 18 April 2020 (UTC) reply
• 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) reply
• Support "Contact us" as first preference, "Contact" as second preference. the wub "?!" 20:57, 18 April 2020 (UTC) reply
• 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) reply
• 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 Wikipedia:Contact us, that's probably the better option. ~ Amory ( u • t • c) 10:11, 20 April 2020 (UTC) reply
• Support, otherwise we might as well rename it to "View the page on infomation to do with contacting us" >> BEANS X2 t 13:05, 20 April 2020 (UTC) reply
• 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) reply
• Support either Contact or Contact us. It is clearer and more concise. Dreamy Jazz 🎷 ^{talk to me | my contributions} 21:49, 26 April 2020 (UTC) reply
• 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) reply
• Support - Not only is the additional wording needless cruft, but it is also antiquated. - Axisixa T C 03:46, 28 April 2020 (UTC) reply
• Support ... this is a no-brainer. Jason Quinn ( talk) 11:54, 2 May 2020 (UTC) reply
• 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) reply

• 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) reply
• Support makes sense. Semi Hyper cube 21:57, 10 April 2020 (UTC) reply
• Support don't see why not.-- Moxy 🍁 22:01, 10 April 2020 (UTC) reply
• Support, same reasons. —⁠ 烏⁠Γ ^{( kaw)} │ 22:52, 10 April 2020 (UTC) reply
• 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) reply
• Comment: I am confused. It's already called Main Page. So why are we renaming a redirect to Main Page? {{ replyto}} Can I Log In's (talk) page 23:06, 10 April 2020 (UTC) reply
  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. {{ replyto}} Can I Log In's (talk) page 23:11, 10 April 2020 (UTC) reply
• ( edit conflict × 2) Support Any attempt to oppose this proposal is fundamentally relitigating Talk:Main Page#Requested move 1 April 2020. * Pppery * _{it has begun...} 23:11, 10 April 2020 (UTC) reply
• 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  ^{dubious – discuss} 23:15, 10 April 2020 (UTC) reply
• 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) reply
• Oppose per Riley and Johnuniq. — Wug· a·po·des​ 00:11, 11 April 2020 (UTC) reply
• 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) reply
• Oppose. Wikipedia uses sentence case. Sandstein 10:46, 11 April 2020 (UTC) reply
• 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) reply
• Oppose sentence case is preferable. LEPRICAVARK ( talk) 16:36, 12 April 2020 (UTC) reply
• 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) reply
• 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) reply
• 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) reply
• 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) reply
• 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) reply
  • Hah! I'm on Modern and intentionally remove the link! ~ Amory ( u • t • c) 10:14, 20 April 2020 (UTC) reply
• It's a link; as above, it should be sentence case for the user. ~ Amory ( u • t • c) 10:14, 20 April 2020 (UTC) reply
• Question to the opposers: @ ~riley, Levivich, Johnuniq, Wugapodes, Tom (LT), Sandstein, GoodCrossing, Lepricavark, CaptainEek, and The wub: 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) reply

• 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) reply
• 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) reply

• @ CaptainEek: 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) reply

• 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) reply
• Oppose - Goes against the consistent (and superior) use of sentence case. - Axisixa T C 03:46, 28 April 2020 (UTC) reply
• Oppose - Inconsistent with other links in that section. -- Netoholic @ 10:19, 6 May 2020 (UTC) reply

• 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. – LaundryPizza03 ( d c̄) 00:39, 11 April 2020 (UTC) reply
• 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) reply
• 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) reply
• 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) reply
• Oppose – "We should not use two or three words where one will do." Levivich  ^{dubious – discuss} 20:15, 12 April 2020 (UTC) reply
• Support "Logged actions" or "User logs" as more clear, "logs" can refer to a lot of different things. b uidh e 23:46, 12 April 2020 (UTC) reply
• 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) reply
• Support as "User('s) logs". —⁠ 烏⁠Γ ^{( kaw)} │ 07:46, 14 April 2020 (UTC) reply
• 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) reply
• Support "User logs" for increased clarity and the parallel with "User contributions". the wub "?!" 21:21, 18 April 2020 (UTC) reply
• Agree with Wub, "User log" is better; I'm either way on the s. I do this myself, actually. ~ Amory ( u • t • c) 10:15, 20 April 2020 (UTC) reply
• Support User logs a clearer label that is consistent with "User contributions". – Tera tix ₵ 01:58, 21 April 2020 (UTC) reply
• Support "User logs"" for consistency with "User contributions" per Teratix.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• Oppose per Levivich. Chris Troutman ( talk) 13:57, 27 April 2020 (UTC) reply
• Support "User logs", conditional to related proposal. Logs is highly ambiguous in this context. However, if #Separate "Page tools" and "User tools" passes, then it should be just "Logs". -- MarioGom ( talk) 19:14, 27 April 2020 (UTC) reply
• 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) reply

To mirror "In other projects" section.

• Support as proposer. Renata ( talk) 04:46, 14 April 2020 (UTC) reply
• Support. This is a much clearer title. —⁠ 烏⁠Γ ^{( kaw)} │ 07:46, 14 April 2020 (UTC) reply
• 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. {{u| Sdkb}}  ^talk 04:46, 15 April 2020 (UTC) reply
• Oppose, labels should be as concise as possible; I'm not sure this is actually confusing to many readers. – Tera tix ₵ 14:07, 18 April 2020 (UTC) reply
• Support for consistency. -- Yair rand ( talk) 17:28, 19 April 2020 (UTC) reply
• Oppose (strongly). I agree entirely with Teratrix. And there's nothing confusing about the language switcher. Daveout ( talk) 12:44, 22 April 2020 (UTC) reply
• Weak oppose as I don't see the problem with plain "Languages" but I understand the desire for consistency.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• Support-- YTRK ( talk) 13:28, 27 April 2020 (UTC) reply
• 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) reply
• Support - Yes, I know anecdotal evidence is flawed, but I know of people who didn't know exactly what these links do. - Axisixa T C 03:46, 28 April 2020 (UTC) reply
• Oppose, we want SHORT LABELS not verbose ones. This is going in the wrong direction. Chiswick Chap ( talk) 13:31, 3 May 2020 (UTC) reply

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

• Support as proposer. Renata ( talk) 05:20, 14 April 2020 (UTC) reply
• 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) reply
• Support - clarity improved, no observable negatives Nosebagbear ( talk) 12:37, 15 April 2020 (UTC) reply
• 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) reply

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

• 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) reply
• Support per proposer and Wugapodes. – Tera tix ₵ 14:26, 18 April 2020 (UTC) reply
• Support "Change user groups" which is actually the MediaWiki default now [1], 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) reply
• 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) reply
• 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 ( u • t • c) 10:19, 20 April 2020 (UTC) reply

  @ Amorymeltzer: 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) reply

  • I think it's clear we're being colloquial, at least until everyone comes around to my "say sysop instead of admin" position. ~ Amory ( u • t • c) 16:07, 20 April 2020 (UTC) reply

• Support for consistency. >> BEANS X2 t 13:14, 20 April 2020 (UTC) reply
• 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) reply
• 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) reply
• 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 Jazz 🎷 ^{talk to me | my contributions} 21:53, 26 April 2020 (UTC) reply
• Support for consistency.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• Support - More consistent and unique, as others have said. - Axisixa T C 03:46, 28 April 2020 (UTC) reply
• Support, it's a small improvement. Chiswick Chap ( talk) 13:32, 3 May 2020 (UTC) reply

We have a few options for renaming the tools section to help makes its purpose clearer and reduce confusion. "Editor tools" (from KarasuGamma and Wugapodes) 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 AHollender (WMF)) would help make it clear that the section is for page-specific tools. What do you all prefer? {{u| Sdkb}}  ^talk 07:56, 15 April 2020 (UTC)^{Refactored 23:05, 15 April 2020 (UTC)} reply

• Support any over status quo, with a weak preference for "editing tools". {{u| Sdkb}}  ^talk 07:56, 15 April 2020 (UTC) reply
• Support. "Editor tools" was my suggestion initially. I would prefer "Editing tools", though I'm fine with either. —⁠ 烏⁠Γ ^{( kaw)} │ 08:25, 15 April 2020 (UTC) reply

  @ KarasuGamma: Oops, sorry, I overlooked the discussion section where you made that proposal. I've refactored above. {{u| Sdkb}}  ^talk 23:05, 15 April 2020 (UTC) reply

• Support, "editing tools" first choice, "editor tools" second. Renata ( talk) 19:47, 18 April 2020 (UTC) reply
• 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) reply
• 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) reply
  • 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) reply
• 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.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• 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) reply

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. – Tera tix ₵ 14:24, 18 April 2020 (UTC) reply

  @ Teratix: 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) reply

• 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) reply
• 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. {{u| Sdkb}}  ^talk 21:52, 18 April 2020 (UTC) reply
• 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! {{ replyto}} Can I Log In's (talk) page

  @ Can I Log In: 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. {{u| Sdkb}}  ^talk 02:02, 20 April 2020 (UTC) reply

  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. {{ replyto}} Can I Log In's (talk) page 03:14, 20 April 2020 (UTC) reply

  @ Can I Log In: 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. – Tera tix ₵ 03:32, 20 April 2020 (UTC) reply

• 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) reply

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

• 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) reply
• 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) reply

  @ Daveout: 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) Facepalm CJK09 ( talk) 01:51, 23 April 2020 (UTC) reply

  @ CJK09: 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) reply

• Support "Print or export". —⁠ 烏⁠Γ ^{( kaw)} │ 21:07, 22 April 2020 (UTC) reply
• 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. – Tera tix ₵ 01:07, 23 April 2020 (UTC) reply
• Support to increase usability. Wouldn't have a major impact but removing the slash and unnecessary words would streamline the menu.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• 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) reply
• 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) reply

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) reply
• Support: Per the proposal reasoning. {{ replyto}} Can I Log In's (talk) page 00:50, 23 April 2020 (UTC) reply
• 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) reply
• 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) reply
• 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) reply
• Support for clarity, I have also experienced this confusion.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• Support for clarification. Semi Hyper cube 13:54, 27 April 2020 (UTC) reply
• Support but prefer "Mute user" as more consise. - Axisixa T C 03:46, 28 April 2020 (UTC) reply

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) reply
• 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. {{u| Sdkb}}  ^talk 18:07, 22 April 2020 (UTC) reply

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

• 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. {{u| Sdkb}}  ^talk 19:51, 22 April 2020 (UTC) reply
• 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. {{ replyto}} Can I Log In's (talk) page 01:24, 23 April 2020 (UTC); edited 02:38, 23 April 2020 (UTC) reply

  @ Can I Log In: Which browser are you using? Everyone here so far reported the opening of a print dialog. Daveout ( talk) 02:23, 23 April 2020 (UTC) reply

  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? {{ replyto}} Can I Log In's (talk) page 02:38, 23 April 2020 (UTC) reply

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

• Support. Menu should be concise and "Print" is exactly the function of the link.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• 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) reply

  @ Blythwood: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) reply

• Support. More concise and equally descriptive. Most people won't care about the small technical difference. -- MarioGom ( talk) 19:34, 27 April 2020 (UTC) reply

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) reply
• 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. {{u| Sdkb}}  ^talk 18:12, 22 April 2020 (UTC) reply
• Oppose: I think this is more for downloading a page's HTML rather than a PDF. {{ replyto}} Can I Log In's (talk) page 00:46, 23 April 2020 (UTC) reply

  @ Can I Log In: You thought wrong. It's for downloading an actual PDF file (as the link clearly says). Daveout ( talk) 02:31, 23 April 2020 (UTC) reply

  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. {{ replyto}} Can I Log In's (talk) page 02:36, 23 April 2020 (UTC) reply

  Lol. do you even know how to properly use a link? Daveout ( talk) 02:48, 23 April 2020 (UTC) reply

  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. 5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply

• Support. The link should reflect its function.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• Oppose, download is clear and widely understood. Chiswick Chap ( talk) 13:35, 3 May 2020 (UTC) reply
• 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) reply

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. {{u| Sdkb}}  ^talk 21:46, 10 April 2020 (UTC) reply
• 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) reply
• 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) reply
• Support an introduction page. No opinion on which one to use. Interstellarity ( talk) 00:25, 11 April 2020 (UTC) reply
• 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) reply

  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. {{u| Sdkb}}  ^talk 00:36, 11 April 2020 (UTC) reply

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

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

• Support addition of one of the proposed pages. SD0001 ( talk) 04:22, 11 April 2020 (UTC) reply
• Support. MER-C 09:52, 11 April 2020 (UTC) reply
• Support, very good idea to have an accessible link to an editing tutorial. -- Yair rand ( talk) 20:36, 12 April 2020 (UTC) reply
• Support no brainer. b uidh e 23:41, 12 April 2020 (UTC) reply
• 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) reply
• Support Wikipedia: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 Wikipedia: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. Wikipedia: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) reply

Really wish choice of help pages was based on editor retention and accessibility. The idea of the 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) reply

• Support Help:Introduction per Sdkb and the recent decision to make it the main introduction linked in the welcome template. Wikipedia: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) reply

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

• Support a link to some kind of introduction. Neutral on which one, however, it should be accessible and clear. Dreamy Jazz 🎷 ^{talk to me | my contributions} 22:01, 26 April 2020 (UTC) reply
• Support per nominator.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• 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) reply

  @ Chris troutman: 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) reply

  @ Interstellarity: 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) reply

• Support WP:Introduction sounds good. -- MarioGom ( talk) 21:01, 27 April 2020 (UTC) reply

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

page view stats showing the loss of interest editor's by thousands . -- Moxy 🍁 18:05, 8 May 2020 (UTC) reply

• 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"? - Axisixa T C 03:46, 28 April 2020 (UTC) reply

  @ Axisixa: 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". {{u| Sdkb}}  ^talk 14:47, 29 April 2020 (UTC) reply

• 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 Wikipedia: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) reply

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

• Support with something like Wikipedia:Village_pump_(proposals)/Archive_160#RfC:_Add_'create_an_article'_option_in_the_interface in mind. Headbomb { t · c · p · b} 17:31, 12 May 2020 (UTC) reply

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 ( u • t • c) 10:22, 20 April 2020 (UTC) reply
• We need a helpful, accessible, readable, community-backed tutorial before this proposal is implemented. – Tera tix ₵ 02:02, 21 April 2020 (UTC) reply

I am working on a new page that actually follows Wikipedia: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) reply

@ Teratix: 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. @ Moxy: 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? {{u| Sdkb}}  ^talk 04:47, 21 April 2020 (UTC) reply

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

My view is based on the feedback we received when you brought the page to WikiProject Accessibility. {{u| Sdkb}}  ^talk 06:03, 21 April 2020 (UTC) reply

Perhaps best review gudlines project page you just joined Wikipedia: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 loss the interest of thousands of potential editors - Moxy 🍁 06:16, 21 April 2020 (UTC) reply

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) reply
• 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.) {{u| Sdkb}}  ^talk 00:44, 11 April 2020 (UTC) reply
• 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) reply
• Oppose Don't see the need; feels redudant to the help and about pages. ~ riley ( talk) 08:01, 12 April 2020 (UTC) reply
• Oppose: not clear what the FAQ would contain and how it would aid readers. — Bilorv ( talk) 18:34, 18 April 2020 (UTC) reply
• 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) reply
• Oppose Help and About Wikipedia links are sufficient. – Tera tix ₵ 02:03, 21 April 2020 (UTC) reply
• OpposeAlready many places to get answers to questions. Jcoolbro ( talk) 20:48, 23 April 2020 (UTC) reply
• Oppose, there's enough introductions as it is.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• 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) reply
• 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. - Axisixa T C 03:46, 28 April 2020 (UTC) reply

Discussion (FAQ)

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) reply
• Oppose. This already exists on the sidebar as the Community portal. {{u| Sdkb}}  ^talk 00:45, 11 April 2020 (UTC) reply

  @ Sdkb: 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) reply

  @ Interstellarity: 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. {{u| Sdkb}}  ^talk 01:01, 11 April 2020 (UTC) reply

• Oppose: Redundant to the community portal. ~ ToBeFree ( talk) 03:30, 12 April 2020 (UTC) reply
• Oppose: Redundant per TBF. ~ riley ( talk) 08:02, 12 April 2020 (UTC) reply
• Oppose. Unnecessary. -- Yair rand ( talk) 20:36, 12 April 2020 (UTC) reply
• 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) reply
• Oppose too much overlap with Community portal. – Tera tix ₵ 02:04, 21 April 2020 (UTC) reply
• Oppose as I cannot see what function this would perform or any community value added.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• Oppose - If the community portal does not fulfill that purpose, it can be changed. - Axisixa T C 03:46, 28 April 2020 (UTC) reply

Discussion (Dashboard)

The logged actions of any page are important for any page, so linking Special:Log with parameter &page={{FULLPAGENAME}} 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. – LaundryPizza03 ( d c̄) 00:37, 11 April 2020 (UTC) reply
• Support a convenient link to page log. Very useful for experienced editors. ---  C& C ( Coffeeandcrumbs) 01:07, 11 April 2020 (UTC) reply
• 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 * _{it has begun...} 01:26, 11 April 2020 (UTC) reply
• Support this should probably go in the Tools section. SD0001 ( talk) 04:23, 11 April 2020 (UTC) reply
• Support. MER-C 10:00, 11 April 2020 (UTC) reply
• 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) reply
• 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) reply
• 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) reply
• Oppose we need fewer, not more, of these links for experienced editors in the sidebar, which should ultimately be focused on readers' needs. – Tera tix ₵ 02:07, 21 April 2020 (UTC) reply
• 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.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply

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

  Agreed with xaosflux. @ LaundryPizza03: since this is getting some support, can you flesh out your proposal a bit per the instructions at the top of the additions section? {{u| Sdkb}}  ^talk 17:54, 11 April 2020 (UTC) reply

   Done. – LaundryPizza03 ( d c̄) 03:28, 13 April 2020 (UTC) reply

  @ LaundryPizza03: Unless I'm missing something, you clarified only the link. Please read the instructions at the top of the additions section. {{u| Sdkb}}  ^talk 19:12, 13 April 2020 (UTC) reply

   Done – LaundryPizza03 ( d c̄) 02:33, 17 April 2020 (UTC) reply

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

  @ MER-C: 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) reply

  Yes, but I'd like to save a click. MER-C 11:17, 11 April 2020 (UTC) reply

• 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) reply
• 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) reply
• 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) reply

  The wub, It's in pop-ups, which I find super helpful. ~ Amory ( u • t • c) 10:24, 20 April 2020 (UTC) reply

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) reply
• 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) reply
• 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? Semi Hyper cube 12:52, 14 April 2020 (UTC) reply
• 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) reply
• Oppose, we already have a prominent search bar. – Tera tix ₵ 14:30, 18 April 2020 (UTC) reply
• Support as "Advanced search". Oppose as "Search". CJK09 ( talk) 05:01, 22 April 2020 (UTC) reply
• Oppose as we have a very clearly defined search bar.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply

Discussion (Search page)

@ Renata: Perhaps somewhere in this report? {{u| Sdkb}}  ^talk 04:54, 15 April 2020 (UTC) reply

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 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. {{u| Sdkb}}  ^talk 21:46, 10 April 2020 (UTC) reply
• 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) reply
• Oppose people should be able to browse if they want. Plus Sdkb’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) reply
• Support - I partly disagree with TonyBallioni'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) reply
  • 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) reply
    • 100% agree. ~ Amory ( u • t • c) 10:28, 20 April 2020 (UTC) reply
• 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  ^{dubious – discuss} 23:52, 10 April 2020 (UTC) reply
• 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) reply

  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  ^{dubious – discuss} 01:48, 11 April 2020 (UTC) reply

  I think Levivich 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.) {{u| Sdkb}}  ^talk 04:35, 11 April 2020 (UTC) reply

  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.) —⁠ 烏⁠Γ ^{( kaw)} │ 04:40, 11 April 2020 (UTC) reply

• 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) reply
• Oppose per TonyBallioni. Useful link for showcasing our best content. SD0001 ( talk) 04:22, 11 April 2020 (UTC) reply
• 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) reply
• 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) reply
• Support and redesign WP:Content. People do not go to Wikipedia to find featured articles, they are usually looking for specific info. b uidh e 23:40, 12 April 2020 (UTC) reply
• 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) reply
• Oppose. These pages ( Wikipedia:Featured content and the specific types it links to like Wikipedia: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. Wikipedia: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) reply
• 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) reply
• 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 ( u • t • c) 10:28, 20 April 2020 (UTC) reply
• Oppose as Featured content is probably the easiest way to view high-quality pages. Contents should be removed if anything.
  5225_C ( talk • contributions) 00:42, 27 April 2020 (UTC) reply
• 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) reply
• 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. - Axisixa T C 03:46, 28 April 2020 (UTC) reply
• 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) reply
• 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) reply