When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
This RfC consists of a series of independent proposals to modify the sidebar located on the left side of every page in the desktop default skin view of Wikipedia (encoded at MediaWiki:Sidebar), aimed at improving usability and ease of navigation.
You may participate by !voting in the polls or contributing to the discussion section under each proposal, or by adding new proposals. Refactoring may be done as needed to keep this RfC organized. – ((u|Sdkb))talk 21:46, 10 April 2020 (UTC)[reply]
Background
The content of the left sidebar has changed remarkably little since the mid-2000s, despite the many advances in web usability best practices since then. In fall 2013, Steven Walling (ret.) launched an RfC proposing a major overhaul. The close (by Keithbob) noted that All participants seemed to agree that the sidebar's content, design and appearance could be improved but that there was a wide variety of suggested changes none of which appeared to have universal support, so no changes were implemented. Since then, only minor changes have been enacted, such as the removal of the "create a book" link last December.
The 2013 RfC articulated the following principles, most of which are copied here given their continued applicability:
Even compared to other pieces of site-wide navigation, the sidebar is an extremely important navigation tool. With the vast majority of readers and editors using a skin (Vector or Monobook) with the sidebar placed on the left, it is in a natural position of importance considering English speakers tend to scan left to right.
The sidebar is currently cluttered. On the Main Page, English Wikipedia readers see 22 linksin 2020, it's 21, not including language linksor "In other projects" links. Basic usability principles tell us that more choices increases the amount of time users have to spend understanding navigation (see Hick's law), and that simplicity and clarity are worthwhile goals. The most recent design of the homepage of Google.com, famous for its simplicity, has half the number of links, for comparison. While removing some semi-redundant links (like Contents or Featured contents) would be preferable, if we're going to have this many links it means prioritization is key, leading to the next point...
The sidebar has poor prioritization. Users read top to bottom, and it is not unfair to say that the vertical order of the links should reflect some basic priority. However, currently, this prioritization is sloppily done. Even if we assume all the current links are important and should stay, the order needs work.
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.
Monthly pageviews of the links in the sidebar typically range in the hundreds of thousands. The ongoing Desktop Improvements Project being undertaken by the WMF may result in future changes to the user interface on all Wikipedias that could affect the sidebar, but it is not focused on the contents of the sidebar, so should not conflict with the proposals here. – ((u|Sdkb))talk 21:46, 10 April 2020 (UTC)[reply]
Proposal: Reorder the links in the left sidebar to create a new "contribute" section
This proposal changes the ordering of the sidebar links in the manner shown at right. Only a section is renamed, and no links are added or removed. The "In other projects" and "languages" sections are ignored in the previews.
The main rationales here are to improve prioritization (by placing important links high up) and categorization (by placing links in more intuitive places, grouped with other similar links). For prioritization, important links like WP:About are moved up. For categorization, the vaguely-named "interaction" section is renamed to the clearer "contribute", and universal editor-focused links are consolidated there, while page-specific editor-focused links are consolidated in the "tools" section. Reader-focused links are consolidated in the top ("navigation") and "print/export" sections.
Survey
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. SemiHypercube 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]
Discussion
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]
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]
How is this meant to work in other skins like Timeless?
Note: Combined into one sidebar, or split into collapsed menus, for smaller screen sizes – see screenshots
@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]
Renamings
This set of proposals suggests renamings of the labels used for some of the sidebar links.
Donate to Wikipedia → Donate
Support as proposer. It's obvious where the donations will go. ((u|Sdkb))talk 21:46, 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]
About Wikipedia → About
Support as proposer. Readers know which site they're on. ((u|Sdkb))talk 21:46, 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)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]
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]
Contact page → Contact
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. SemiHypercube 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 - 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 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]
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]
Logs → Logged actions
Support as proposer. I have proposed a new link called "Logs" below, and this title is less ambiguous anyway. Note that this one appears only in user/user-talk space and on Special:Contribs. –LaundryPizza03 (dc̄) 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. — xaosfluxTalk 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]
Additions
This area is for proposals to add new links to the sidebar not present in the current version. When adding a new one, please specify the label you would like for the link to have, the location you would like it to have, and the tooltip you would like to display when a reader hovers their cursor over it.
An introduction to contributing page
Attracting new contributors is of the utmost importance to the project. I therefore propose the addition of a link going to an introductory page. Personally, I believe this should be Help:Introduction, the gateway to our recently revamped tutorial set that has been made the primary button in our new standard welcome message, but other possibilities could be Help:Introduction to Wikipedia (the first module of the tutorial set), WP:Contributing to Wikipedia (a single-page intro), or Help:Getting started (which links to tons of different intros). I would prefer the location directly beneath "Help", with the label "Tutorial" and the tooltip "Learn how to edit Wikipedia".
SupportWP: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]
Moxy recently broughtHelp: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]
Support addition of one of the proposed pages. SD0001 (talk) 04:22, 11 April 2020 (UTC)[reply]
Discussion
An FAQ page
Many websites have an FAQ page. I think this website should have one as well.
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]
Discussion
A dashboard
I think this link would be helpful to people so people can see what's going on behind the scenes with Wikipedia.
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]
Discussion
Logs
The logged actions of any page are important for any page, so linking Special:Log 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".
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 pare 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]
Discussion
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". — xaosfluxTalk 02:09, 11 April 2020 (UTC)[reply]
Removals
This area is for proposals to remove links in the current version of the sidebar.
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
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]
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]
A vast majority of uploads should happen on Commons. Those who have the know-how and understanding for why and how to uploaded files locally, know where to go. This is an old link that has very infrequent use now.
Strong oppose only place for info on uploading media. The link allows you to choose Commons or here to upload files.--Moxy🍁 23:08, 10 April 2020 (UTC)[reply]
Moxy, Special pages has a link to "Upload file". People that don't know the difference between Commons and Wikipedia file upload are going to go to the wrong place (the most prominent link on the page).--- C&C (Coffeeandcrumbs) 01:03, 11 April 2020 (UTC)[reply]
Oppose This doesn't appear to be technically possible. Even if it were, I agree with Moxy that it is not a good idea. * Pppery *it has begun... 23:17, 10 April 2020 (UTC)[reply]
Oppose I think it is nice to have a link that directs people on how to upload the file. It is a matter of convenience. Interstellarity (talk) 23:31, 10 April 2020 (UTC)[reply]
Support there is so much content already uploaded and in my experience the good quality content is batch uploaded on commons. We don't need a link here that every person and their dog are invited to use. We are beyond that point. --Tom (LT) (talk) 00:14, 11 April 2020 (UTC)[reply]
Oppose the page gets like 5k views a day. There's no reason to make uploading harder. — Wug·a·po·des 00:17, 11 April 2020 (UTC)[reply]
Wugapodes, 5k is almost nothing. Other links get 10s of thousands of views. --- C&C (Coffeeandcrumbs) 01:05, 11 April 2020 (UTC)[reply]
It's also nothing to thumb our noses at. That's 1.8 million clicks per year which help expose readers to the process of contributing files. Like I said, there's no reason to make it harder to upload media. — Wug·a·po·des 02:55, 11 April 2020 (UTC)[reply]
Oppose, making it harder for people to get the upload link isn't friendly to new editors - we already have it pushing them to commons via the dialog that is used when you click there. — xaosfluxTalk 02:05, 11 April 2020 (UTC)[reply]
Discussion
@Coffeeandcrumbs: Do we have access to any data about what percentage of uploads come from that link? ((u|Sdkb))talk 23:37, 10 April 2020 (UTC)[reply]
We are sending people to the wrong place. 99.5% (educated guess) of uploads should be directed to Commons. --- C&C (Coffeeandcrumbs) 00:57, 11 April 2020 (UTC)[reply]
Autocollapsing some sections
A key component of usability is reducing visual clutter by hiding less important links. Accordingly, these proposals suggest collapsing some sections by default, with readers able to click to expand them if desired.
Support as proposer. ((u|Sdkb))talk 21:46, 10 April 2020 (UTC)[reply]
Support Although collapsing is strongly discouraged every where when concerning readers due to accessibility.... we all know that collapsed things make people look.--Moxy🍁 22:08, 10 April 2020 (UTC)[reply]
Oppose Explaining to someone how, for example, that a hidden category can be seen by clicking "Page information" should not be complicated by some design dream of the perfect page where nothing is visible. People who vaguely remember that there is an "information" something can search and find it under Tools. They would never find it if Tools is collapsed. Collapsing requires JavaScript which is not compulsory for Wikipedia. Johnuniq (talk) 23:33, 10 April 2020 (UTC)[reply]
Oppose usability > design. Also per Johnuniq. TonyBallioni (talk) 23:39, 10 April 2020 (UTC)[reply]
Qualified support if, like a "normal" website, we could make it a preference whether to collapse or expand the tools section by default. Something tells me not to assume that this is doable, even if other websites have had this functionality for years. My understanding is that the number of web users without javascript is incredibly tiny, like 0.1%, so if that's true I don't think that's a concern. Levivich[dubious – discuss] 00:07, 11 April 2020 (UTC)[reply]
Weak oppose prefer just renaming it something like "Editor tools" or "Advanced tools". I get that readers may be confused by it but this seems like more work than it's worth. Readers aren't spending hours every day looking through the "tools" section and wondering what it all means; they may spend a few seconds, go "huh" and then move on with the rest of their lives like they do with every other editorial button. Most of our readers are on mobile where they don't even see the toolbox. — Wug·a·po·des 00:24, 11 April 2020 (UTC)[reply]
Oppose likely to cause accessibility problems. And those who want to use the links will need to make one extra click. There is a lot of space in the sidebar, I see no reason to collapse. SD0001 (talk) 04:21, 11 April 2020 (UTC)[reply]
@SD0001: Fair enough, but consider that there's also a lot of empty space on Google's homepage (and plenty of products that could reasonably fill the space), but there's good reason they keep it that way. Every item that we remove or collapse helps the remaining items stand out more and makes it quicker for readers to find them. ((u|Sdkb))talk 04:47, 11 April 2020 (UTC)[reply]
Discussion
Wouldn't this problem be solved simply by renaming it "Editor tools"? I acknowledge that it would make it look like there's a wall between readers and editors, but I contend that that wall already exists and this merely makes it visible, with the addition of not forcing readers to feel like they need to worry about this section. I'm neutral on the specific proposal to collapse. —烏Γ(kaw)│ 22:56, 10 April 2020 (UTC)[reply]
Neutral I would support this for logged out editors if there was a way to have it autoexpanded by preference or for logged in editors. It is very useful.--Tom (LT) (talk) 00:14, 11 April 2020 (UTC)[reply]