Wikipedia talk:Requests for comment/Rollback of Vector 2022

When moving someone's words to another page, please ping

@InfiniteNexus: In the future, please ping people when you move their words to another page (other than archiving, of course). Yes, a lot of people to ping in this case, but it's still a thoughtful step in wikicommunication. Moving someone's comments to another page has the potential for recontextualizing them in sometimes subtle ways (granted, not a big deal in this case), and the original authors might not be watching the new page by default, missing responses, etc. — Rhododendrites ^talk \\ 14:59, 23 January 2023 (UTC)

I didn't think it was necessary in this case, but I'll keep that in mind. But regarding the original authors might not be watching the new page by default, missing responses, etc., if the original author was watching the old page, they would have noticed the move (and the talk page discussion that led to the move), and if the author was anxious about responding to replies, they would have proactively checked the old page, which has a link to this page. So, not really a big deal in this instance. InfiniteNexus (talk) 01:05, 24 January 2023 (UTC)

Plus, if you were subscribing to the old section, you were still subscribed to the moved sections. Aaron Liu (talk) 12:23, 25 January 2023 (UTC)

This RfC is just a venting area

Withdrawn CactiStaccingCrane 12:09, 24 January 2023 (UTC)

With due respect to User:HAL333 (initiator of the RfC) and everyone else, I think that this RfC had provided little value the improvement of the skin itself aside from causing conflicts and maybe brainstorming a few improvement to Vector 2022. I think that most participants are here only to express their opinion about their dislike/like of the new skin and a few have already made border-line WP:Harassment remarks towards other editors. This is not helpful at all for developers, readers and editors. CactiStaccingCrane 18:14, 23 January 2023 (UTC) No, it’s a poll on whether readers and the community want V2022 to be the default, and there’s a 60>% majority saying they do not want it to be so. Of course nobody wants to discuss “improving” V2022 because that isn’t what this RfC is about! Dronebogus (talk) 20:20, 23 January 2023 (UTC) Correct. I don't want to "improve" V2022, I want to replace it with V2010. IWantTheOldInterfaceBack (talk) 21:12, 23 January 2023 (UTC)

The attempts to "organize" the second section...

Please stop. Or rather just undo. This is a giant mess. — Rhododendrites ^talk \\ 22:20, 24 January 2023 (UTC)

@Steue: appears to have started to move things around, then quickly abandoned that project hours ago. Now an unregistered users seems to be adding numbers for some reason... — Rhododendrites ^talk \\ 22:23, 24 January 2023 (UTC)

@Rhododendrites: I think his efforts are well-meant, but maybe he should seek some help. Æo (talk) 22:47, 24 January 2023 (UTC)

Between the stop-and-go reorganizing, the apparent socking or canvassing, and the various edits to the intro text attempting to bias it in one direction or another, the RFC is suddenly becoming an unmanageable mess, it seems to me. IWantTheOldInterfaceBack (talk) 22:48, 24 January 2023 (UTC)

Thanks Rhododendrites this unregisterd user is me, Steue. I did not log out intentionally, I don't know when and why I logged out.

These numbers are just temporarily for more easy orientation for me.

Can you tell me, how I get an indented line to "not interrupt the automatic counting" like

1. A

B

1. C

Steue (talk) 22:49, 24 January 2023 (UTC)

See Help:List § Common mistakes. (Incidentally, that link was much easier to access and retrieve with a table of contents in the sidebar than with it at the top of the page.) isaacl (talk) 22:55, 24 January 2023 (UTC)

Thank you isaacl now I know how to.

Steue (talk) 23:02, 24 January 2023 (UTC)

I agree with what Steue's trying to do (and I'm a veteran of the bullshit that was the CRASHlock debates). While I do have to criticise how he went about it, he's clearly trying to make the section easier to interpret, and we should understand that he's going to make mistakes if he's not familiar with wikicode. Assuming others don't do so, I'm likely to rejigger that section to put each argument in the appropriate section later tonight. —Jéské Couriano (No further replies will be forthcoming.) 23:08, 24 January 2023 (UTC)

@Jéské Couriano: This oldid contains the list as it was before Steue began his reorganisation: I suggest you use it, since Steue messed up the indenting entirely. There are only two new comments in the list thereafter: this and this one.--Æo (talk) 23:14, 24 January 2023 (UTC)

 Done. I've finished the job. InfiniteNexus (talk) 23:18, 24 January 2023 (UTC)

And I've fixed most of the indenting. —Jéské Couriano (No further replies will be forthcoming.) 23:31, 24 January 2023 (UTC)

Thanks. I tried to fix some myself when doing the sorting, but I know I probably missed a few. InfiniteNexus (talk) 23:34, 24 January 2023 (UTC)

Sorry that I have caused you trouble. I only returned to this talk page because I did'nt know what to do with the RfC chunk, which you put in "Comments". I was still working at it and not aware that InfiniteNexus had already done what I had intended. After all, it got done. You really showed me how old and slow I am. I never thought that participating at the wp would cause me to :=(((. Thank you Jéské Couriano for your warm words. Good night. Steue (talk) 00:25, 25 January 2023 (UTC)

Thanks for the group effort, all. Personally, I think big reorganizations during times of high activity wind up being more hassle than they're worth, and don't think there's much need to separate supports/opposes unless we're looking to do a straight head-count, but I appreciate others find it neater. All's well that ends well. — Rhododendrites ^talk \\ 04:20, 25 January 2023 (UTC)

No need to beat yourself up, we know you were acting in good faith. It wasn't clear based on your inactivity and the comments above whether you had abandoned the project, so I decided to just go ahead and finish it up for you, especially given that people were already asking questions. In the future, please use your sandbox when conducting major reorganizations or overhauls such as this one, so as to minimize disruption and avoid confusion. Thank you. InfiniteNexus (talk) 05:35, 25 January 2023 (UTC)

Why are folks putting 'support/oppose/neutral' etc in their posts

We already have the survey subsections named 'Support', 'Oppose', 'Neutral'. So, why are editors adding (in bold) 'Support', 'Oppose', 'Neutral' to their posts. Example - If you've posted in the 'Neutral' subsection? then we already know your stance is neutral. GoodDay (talk) 17:50, 24 January 2023 (UTC)

As I said above, it could be because they want to make their thoughts clearer, because it's common practice, or because the posts here were not initially split between supports and opposes. -BRAINULATOR9 (TALK) 17:52, 24 January 2023 (UTC)

Yup, when I voted the votes were not separated out yet, so it was imperative to indicate whether it was support, oppose, or neutral. ☿ Apaugasma (talk ☉) 18:05, 24 January 2023 (UTC)

There's also some people who wish to say it with passion; "Strongest possible support", or "Weak oppose", or my favourite "What makes an editor turn neutral? Lust for barnstars? Advanced privileges? Or were they just born with a heart full of neutrality?" Sideswipe9th (talk) 23:27, 24 January 2023 (UTC)

It's good to say so even if it is sorted into subsections. For example, some people are saying "Strong support" or "Weak oppose" and such. Makes sure that it's a spectrum of opinion rather than two polar opposite camps. Tim O'Doherty (talk) 20:28, 24 January 2023 (UTC)

That's pretty standard for RfCs and others of the sort, like CfDs. Half of the time people's comments aren't sorted and so it becomes a hodgepodge of varied opinions.

Plus it also helps me differentiate at a glance because certain bolded words call certain icons through my custom Javascript (like whenever someone says Oppose). —Tenryuu 🐲 ( 💬 • 📝 ) 23:39, 24 January 2023 (UTC)

• In addition to all of the above, it makes it easy to tell at a glance where one person's comment stops and another's begins. —Compassionate727 ^(T·C) 01:05, 25 January 2023 (UTC)

Have you ever seen a RfA? It's convention. Pawnkingthree (talk) 00:16, 26 January 2023 (UTC)

Moved to talk.— Qwerfjkltalk 07:18, 25 January 2023 (UTC)

Isn't this RfC too soon, I mean with all the adaptions that are taking place?

I know the question can also go the other round in isn't the launch too soon. I doubt the discussion closer will take the votes into account that were made before the adaptions were made for example yesterday. I believe many wcould invest their time better in getting back to editing wikipedia elsewhere. Paradise Chronicle (talk) 17:15, 25 January 2023 (UTC)

I expect the closer to take all comments into account, unless they specifically say "roll back because X" where X is a temporary problem which has been fixed. If they're going to discard early !votes, we at least need to be pinged so that we can review our statements and repeat them if still applicable. Certes (talk) 18:27, 25 January 2023 (UTC)

...and yes, this process is very disruptive. I've done a fraction of the useful editing that I would have done had I not been following the Vector 2022 discussion. However, that problem is caused as much by the hasty release as by the calls to roll back. Certes (talk) 18:28, 25 January 2023 (UTC)

Of course this goes both ways and the same applies to the foundation. They too would get more things done if we didn't throw a tantrum every single time. No one is having fun here. —TheDJ (talk • contribs) 23:32, 25 January 2023 (UTC)

I am not surprised by the RfC happening right away, it should've been expected. I am more concerned with the perception (whether true or not), that Vector 2022 was deployed by default before it was fully ready. One of the key lessons learned from the VisualEditor rollout was that it was rushed, and more time "could have prevented a lot of pain and frustration" (source). The fact the the "page tools" change was deployed the week after the default flips just adds to the perception that Vector 2022 isn't ready. Legoktm (talk) 19:49, 25 January 2023 (UTC)

I think it's good practice to let discussions run their course. Assuming all rules are followed (civility, on topic, etc.), folks should get their say. –Novem Linguae (talk) 20:51, 25 January 2023 (UTC)

The "inbetween discussion threads" (at the 2nd question) contain 'oppose' and 'support' arguments which, unfortunately, are not counted

In the "beginning", until there were about 120 comments to the 2nd question ('oppose' and 'support' all together and all mixed),

• the comments to the 1st question were:
  • sorted by 'oppose' and 'support' and
  • numbered and
• the comments to the 2nd question were just
  • bulleted,
  • not numbered and
  • contributors had put a "Support" or "Oppose" in front of their contributions.

At that point, I had thought, it would be better to have the comments for the 2nd question sorted too by "Support" or "Oppose" and numbered too.

I had started to sort them and someone else finished this sorting.

While I tried to sort these comments, I started to realize that there had discussions been going on inbetween these arguments, and that many of these inbetween-threads contained 'opposes' and 'supports' alternatingly (they still do).

But each new comment, also in the inbetween-threads, at least had a bullet (which now I find very good), but now these don't have bullets anymore.

Fault:
Meanwhile, after I have slept over it, I see that many of these inbetween-threads contain valuable arguments, which now don't appear in the 'support'- and 'oppose'-counts. Only the argument at the start of such an inbetween-thread gets counted.

So, now, I think, these inbetween-threads should be sighted for valuable arguments and the valuable arguments which are found there, should be copied and placed as what I will call "1st level" arguments.

Ping welcome, Steue (talk) 13:04, 26 January 2023 (UTC)

​Sorry, I really don't understand what you're trying to say. What do you mean by inbetween-threads? Could you give an example? InfiniteNexus (talk) 04:16, 27 January 2023 (UTC)

I suggest not shuffling comments around anymore. The discussion is not a vote, so numbered viewpoints aren't necessary. isaacl (talk) 06:15, 27 January 2023 (UTC)

While consensus is not based on raw votes, they do assist in gauging consensus. InfiniteNexus (talk) 06:20, 27 January 2023 (UTC)

@ InfiniteNexus, I inserted an explanation at the top. --Ping welcome, Steue (talk) 08:04, 28 January 2023 (UTC)

Moved to the bottom of the thread. You cannot add new comments to the top of a section like that. And please stop changing other people's indentation, they were correct as is. InfiniteNexus (talk) 18:45, 28 January 2023 (UTC)

What I mean by "inbetween discussion threads":

• The contributions no. 1 to 12 to the "2nd question / support" do NOT contain an "inbetween discussion thread",
• contrib no. 13 of them is the first which does.

Ping welcome, Steue (talk) 08:04, 28 January 2023 (UTC)

Those are comments, not !votes. As such, they should not be tallied. InfiniteNexus (talk) 18:45, 28 January 2023 (UTC)

This page is too long

Maybe we should split this page into multiple sections. Thingofme (talk) 01:19, 27 January 2023 (UTC)

It's already split into multiple sections, and while I would appreciate this being split off into different pages to make loading faster, it's going to frustrate people who are directed to the RfC only to find that they have to click elsewhere. If this is possible, I think the §Discussion section should be the first to be split off. —Tenryuu 🐲 ( 💬 • 📝 ) 01:29, 27 January 2023 (UTC)

I think it's simpler if we keep everything on the same page. InfiniteNexus (talk) 01:41, 27 January 2023 (UTC)

But maybe the page is too long (already 880kB and maybe longer, and discussions should be focused on another page or this talk page). However, the talk page is only used for off-topic discussions relating to this page. Thingofme (talk) 03:20, 27 January 2023 (UTC)

What if we:

• split the 2nd question off into its own page and
• gave the original page, under the appropriate header, a link like [ To the 2nd question ] ?

After this we could do the same to the "Comments" part.

Ping welcome, Steue (talk) 08:23, 28 January 2023 (UTC)

Maybe this is ok, or splitting the Question 1, Question 2 and comments into 3 different pages. Thingofme (talk) 13:41, 28 January 2023 (UTC)

I agree with InfiniteNexus that the entire RfC should remain on the same page. Dividing Q1, Q2 and other discussions into three different pages would only complicate things. Æo (talk) 18:06, 28 January 2023 (UTC)

There are discussion pages that are 1M bytes+ long so it's ok. Thingofme (talk) 02:07, 29 January 2023 (UTC)

@Thingofme, well, it takes me ~10 minutes to load the page and then post a comment. — Qwerfjkltalk 10:55, 29 January 2023 (UTC)

Only two people (out of 484) have said that they are experiencing loading issues. I don't believe this is a major issue. InfiniteNexus (talk) 19:20, 29 January 2023 (UTC)

You can add me to the people who are finding it difficult to navigate such a large page. I feel that some of the discussion subsections would be a better fit for this talk page and help alleviate the size problem. Legoktm (talk) 17:14, 1 February 2023 (UTC)

We could move all the metadiscussion here (4.2, 4.6, 4.18, 4.21, maybe 4.9)? —Femke 🐦 (talk) 17:57, 1 February 2023 (UTC)

Perhaps adding some arbitrary/date breaks to the support/oppose/neutral sections would improve navigation? At the very least it would make it easier to jump to !votes made on or around specific dates for replying. Sideswipe9th (talk) 19:42, 1 February 2023 (UTC)

I wouldn't be opposed to moving some of the discussions here. InfiniteNexus (talk) 08:19, 2 February 2023 (UTC)

@InfiniteNexus: I would be in favour of moving some of the discussions here so as to shrink the size of the page. Also, I think it would behove to split the "Discussions" section into the subsections "Other proposals" (containing "Bring back the TOC", "Another option for changing the width", et al.), "WMF/Web team/ArbCom (?) responses" (containing "Vector 2022 Post-Deployment Update from WMF Team", "Jan 23 update from Web team: page tools and more upcoming changes", "Disclosure of email outreach", "Login button now to appear outside of menu for logged-out users"), and move everything else under "General comments" so as to then select what of the latter is so general that it may be moved here. Æo (talk) 15:41, 3 February 2023 (UTC)

Anyway, I let others decide. Æo (talk) 15:44, 3 February 2023 (UTC)

Those aren't "official" proposals, just ideas/complaints being floated around. By the way, if we decide to move any discussions over here, they should ONLY be the ones about the RfC process in general, not the ones about Vector 2022. InfiniteNexus (talk) 17:59, 3 February 2023 (UTC)

Okay, the thumb on my scroll bar has gotten so tiny, I agree it's getting absurd. I now fully support moving all of the 29 discussion threads to a subpage (Wikipedia:Requests for comment/Rollback of Vector 2022/Discussion). InfiniteNexus (talk) 01:06, 7 February 2023 (UTC)

• Support spinning out the discussion section and perhaps the 2nd RFC too. At 1.2 MB, this page is quite large. –Novem Linguae (talk) 07:15, 8 February 2023 (UTC)
• Weak support. If possible, discussions that have been inactive for some time should be moved to the proposed page, like an archive. —Tenryuu 🐲 ( 💬 • 📝 ) 07:24, 8 February 2023 (UTC)
• If they are moved, I think we should at least keep the sections' titles, with the template {{Moved discussion to}} linking to the same section in the new page.--Æo (talk) 14:57, 8 February 2023 (UTC)

I also propose the following subdivision:

== Discussions ==

=== Other proposals for the skin ===

==== Allowing for IP users to change the skin back if Vector 2022 is kept as the default ====
==== Bring back the TOC ====
==== What changes, if any, need to happen in order to make skin preferences work for anons? ====
==== Another option for changing the width ====
==== Why so complicated? (TOC right) ====
==== Dark mode ====
==== Sticky header in Vector Legacy ====
==== Borders and backgrounds: bring back the distinction between the article's space and the user's space ====

=== Web team/WMF updates ===

==== Vector 2022 Post-Deployment Update from WMF Team ====
==== Jan 23 update from Web team: page tools and more upcoming changes ====
==== Disclosure of email outreach ====
===== Canvassed vote review =====
==== Persistence for fixed width for all users coming this week ====
==== Login button now to appear outside of menu for logged-out users ====

=== Other discussions ===

==== General comments ====
==== Publicizing this RfC ====
==== Link to the research about limited line width ====
==== Selection bias ====
==== Question for the Web team ====
==== So people may not like it - now what? ====
==== What if any changes did the WMF make in response to the RfC closure conditions? ====
==== The difference between reading an encyclopedia article and reading a book or news article ====
==== Reviews of Vector 2022 ====
==== Strange pattern in recent opposes ====
==== Tools to the right ====
==== Some opposes and supports with same argument ====
==== What can we do if WMF again ignores community opinion and statistics? ====
==== Foreign language Wikipedias ====
==== In general ====
==== Workarounds for circumventing V22 problems for IP-users by further complicating scripts do not solve anything ====
==== Couple more questions (switched back to Timeless) ====

--Æo (talk) 16:03, 8 February 2023 (UTC)

It would not be feasible to constantly update the list of new sections. We can just put a {{main}} hatnote under § Discussion (not {{Moved to}}). InfiniteNexus (talk) 18:29, 8 February 2023 (UTC)

I thought it would be important to keep the sections' titles because they are already linked across various other discussions, both on the RfC's page itself, at the Village pump, on the talk page of Wikipedia:Vector 2022, and etc. And what about the subdivisions? If they are fine I can implement them. Æo (talk) 18:36, 8 February 2023 (UTC)

We can anchor all of the section links that existed prior to the move here. As for the subdivisions, I'm not opposed to them. InfiniteNexus (talk) 18:38, 8 February 2023 (UTC)

By WP:ANCHOR do you mean a bulleted list of links to the subsections of the new discussions' page? If so, I think it is a good idea. Æo (talk) 18:49, 8 February 2023 (UTC)

Addendum: We could leave the three level-three subsections (===) and turn all the level-four (and one level-five [==== & =====]) subsections into three bulleted lists of links to the corresponding discussions in the new page. I don't know if the same level-four (and one level-five) sections' titles can be WP:ANCHORed to the level-three titles so that the aforementioned links across Wikipedia are not broken.--Æo (talk) 19:42, 8 February 2023 (UTC)

No, I am talking about the {{anchor}} template, which will be placed on the Discussion section heading. That way, if someone follows a link to, say, [[Wikipedia:Requests for comments/Rollback of Vector 2022#Publicizing this RfC]], it will take them to the Discussion section (as opposed to the top of the page) with a hatnote linking to the new subpage. InfiniteNexus (talk) 07:19, 9 February 2023 (UTC)

Fine, I have never used the template {{anchor}} (I didn't even know it existed), but yours is a good idea. In any case, under the Discussion title I suggest to leave a bulleted list of links to the discussions in the new page. Æo (talk) 14:52, 9 February 2023 (UTC)

I just saw this. I get the sections now, but why are we using {{main}} instead of {{mdt}}? Aaron Liu (talk) 17:18, 14 February 2023 (UTC)

@Æo Aaron Liu (talk) 21:50, 14 February 2023 (UTC)

@Aaron Liu: I don't know. The template {{main}} is used not only for articles but across various technical pages too. If you think that the template {{mdt}} is more appropriate for the discussion section, you can swap them. Æo (talk) 22:21, 14 February 2023 (UTC)

Regarding the subdivisions, I am going to implement them. Æo (talk) 18:51, 8 February 2023 (UTC)

 Done. Æo (talk) 19:29, 8 February 2023 (UTC)

• Split We can split the discussion into a Fram-esque page like Wikipedia:Community response to the Wikimedia Foundation's deployment of Vector 2022. 🐔 Chicdat  ^{Bawk to me!} 12:21, 10 February 2023 (UTC)

  This could work as a redirect, but I think the subpage proposed by InfiniteNexus is better, since the discussions will still be part of the main RfC even if they will be split out, and the RfC itself is the "community response" to the deployment of V22. Æo (talk) 15:49, 10 February 2023 (UTC)

I've made the split: Wikipedia:Requests for comment/Rollback of Vector 2022/Discussion. InfiniteNexus (talk) 16:59, 14 February 2023 (UTC)

@InfiniteNexus: After a while I suggest to move also Selena Deckelmann's comment to the new discussion subpage. Æo (talk) 12:57, 18 February 2023 (UTC)

(Apologies for the long wait, I've been off-wiki since Friday.) Yeah, I'll do so right away. It seems people didn't see the part about adding new comments on the subpage. InfiniteNexus (talk) 00:56, 20 February 2023 (UTC)

Actually, Deckelmann saw the line advising readers to add their comments in the new page, but, as she stated in her post, she put the latter in the old location so that more readers might see it. Æo (talk) 16:18, 20 February 2023 (UTC)

Guillemets

Did I miss a memo? Why are so many comments using guillemets? Aka « and » Aaron Liu (talk) 14:53, 2 February 2023 (UTC)

It could just be that some French speakers who use French-language keyboard layouts (but contribute to en.wp) aren't bothering to replace their customary guillemets with English-language quote marks the way they would if they were editing an actual article. --Proginoskes (talk) 21:49, 2 February 2023 (UTC)

What makes this funny is that frWiki was one of the earliest Wikis to deploy V22, without much fanfare. DFlhb (talk) 14:53, 28 February 2023 (UTC)

WMF is now implementing some of the features that editors from early adopter wikis originally asked for. Perhaps people have decided to come here to make themselves heard ;) Daß Wölf 12:55, 5 March 2023 (UTC)

Question 3 idea

Please see Wikipedia:Village pump (idea lab)#‎Vector 2022 third question. Aasim - Herrscher of Wikis ❄️ 20:11, 2 February 2023 (UTC)

"Wikipedia:ROLLBACKVECTOR22" listed at Redirects for discussion

An editor has identified a potential problem with the redirect Wikipedia:ROLLBACKVECTOR22 and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2023 February 6 § Wikipedia:ROLLBACKVECTOR22 until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Aaron Liu (talk) 13:52, 6 February 2023 (UTC)

• To save people a click, this was closed as speedy keep. schetm (talk) 19:49, 9 February 2023 (UTC)

Expedited close?

While it hasn't yet been exactly 30 days (we still have 12 more days to go), this RfC already has nearly double the responses the previous RfC had. I think an expedited (and of course, impartial) close is warranted, the sooner we get through this first step, the better. InfiniteNexus (talk) 04:21, 7 February 2023 (UTC)

I think an expedited close would be good: if this closes with support, the skin will have to be rolled back (and probably also for a no-consensus close, given V10 is the status quo ante). For readers, this will be more confusing the longer V22 is online.

On the other hand, the web team is addressing some concerns. I've not seem them address the language issue and the icons issue from the previous close, but the whitespace issue is actively worked on. Giving them more time may allow them to address outstanding issues. Femke (alt) (talk) 09:47, 7 February 2023 (UTC)

We should ask the web team whether they plan to release significant improvements in the next 12 days. If not, let's close. However, as one of our most popular discussions, it deserves a "last chance to comment" notice of some sort (watchlist?) first. Certes (talk) 12:41, 7 February 2023 (UTC)

I highly doubt the WMF will be able to address the majority of the most pressing concerns raised in this RfC within the next two weeks. Any fixes they roll out would just be band-aids, not a permanent solution. InfiniteNexus (talk) 17:37, 7 February 2023 (UTC)

Hey everyone, we're currently preparing a longer update with some upcoming changes, questions we might have for the community on the changes we've made, as well as a look into the data that we're getting from the new skin. We hope to publish this either tomorrow or Thursday. OVasileva (WMF) (talk) 20:47, 7 February 2023 (UTC)

Okay, I'm willing to wait until then. InfiniteNexus (talk) 01:15, 8 February 2023 (UTC)

This RFC appears to be wrapping up. This should be closed soon, before this new situation becomes the status quo. Shall we post a closure request to WP:ANRFC? –Novem Linguae (talk) 07:13, 8 February 2023 (UTC)

@Novem Linguae, we might want to wait until the update mentioned above is published. — Qwerfjkltalk 07:18, 8 February 2023 (UTC)

If an update is coming on Thursday (9 Feb 2023) then it seems reasonable to give a few days after that for people to add or revise comments. If we're doing that, we may as well wait the full 30 days (18 Feb 2023) which gives them nine days to comment. It is also possible that some people are giving the new skin a thorough trial and have made a note in their diaries to comment just before the close. Certes (talk) 12:38, 8 February 2023 (UTC)

I don't see a need to do so, honestly. It is extremely unlikely that anything anyone says in the next week and a half will affect the outcome. Pretty much every possible argument has already been made, and there is no chance of the gap in votes closing enough to matter. —Compassionate727 ^(T·C) 19:47, 8 February 2023 (UTC)

Hey @Certes, @InfiniteNexus - just wanted to leave a quick note that we're running a bit late with our announcement and will most likely publish first thing Monday morning (we'll be ready with it today, but our availability to answer questions over the weekend is fairly low). We're planning on publishing a lot of data and details on ongoing work and it's taken a bit longer than expected to validate and double-check everything. It's going to be pretty long message :) We've noticed there's been a lot of questions recently about our data and interpretation so we want to make sure we have links to all the original sources for everything we publish so that folks can dig into the data directly (where our privacy policy allows). OVasileva (WMF) (talk) 16:32, 10 February 2023 (UTC)

Given we're nearing the end of the conversation here, it may be good to post today still. People understand you guys don't work weekends. And please try to be succinct :). Femke (alt) (talk) 16:46, 10 February 2023 (UTC)

Monday 13, 16:45 UTC. No word from WMF. May be, Do they want to make their announcement tomorrow, Saint Valentine's Day, to gather some love? (Irony with love.) 37.134.90.176 (talk) 16:49, 13 February 2023 (UTC)

Hello! The update has just been posted: Summary of work so far and next steps :) SGrabarczuk (WMF) (talk) 01:45, 14 February 2023 (UTC)

So, while I appreciate the WMF for continuing to solicit feedback from users, this further illustrates how the rollout was botched and premature. The Web team should have attempted to address the majority of concerns raised by editors in the previous RfC, rather than just one of them. Instead, Vector 2022 launched with serious defects and insufficient communication, and now the WMF is rushing to address the flood of complaints (well, some of them, anyway) — something that should have been done before the launch. Until most everyone's concerns have been fully addressed and the community is satisfied, Vector 2022 is clearly not ready for a wide adoption. Is anybody opposed to a closure request for this RfC now that the WMF has issued their closing statement? InfiniteNexus (talk) 19:47, 14 February 2023 (UTC)

So what happens next? will the WMF actually revert non-logged in users back to V10 upon the closure of this RfC? WikEdits5 (talk) 22:43, 14 February 2023 (UTC)

For sure, this RFC will be closed with a fake "consesus to improve V22" or the like. Obviously WMF will not rollback to V2010 in English WP, less they will rollback V22 in the French WP and all the other "Guinea pigs" WPs. Any bet? 37.134.90.176 (talk) 22:58, 14 February 2023 (UTC)

This RfC will not be closed by the WMF, it will be closed by an uninvolved volunteer editor. InfiniteNexus (talk) 23:43, 14 February 2023 (UTC)

They are two separate sentences. You may read the first one as "WMF will interpret the closing as...", etc., if you wish, but ultimately alea jacta est. I sincerelly hope to be wrong. 37.134.90.176 (talk) 18:12, 15 February 2023 (UTC)

If the closer determines that there is consensus to roll back V22, or that there is no consensus on which skin to use, then yes. If the closer determines that there is consensus to keep using V22, then no. In any case, it will ultimately be up to the WMF to decide whether to respect the community's consensus. InfiniteNexus (talk) 23:43, 14 February 2023 (UTC)

No objection; I think it is time to request closure at WP:RFCL BilledMammal (talk) 23:53, 14 February 2023 (UTC)

In my view, it would be a bad move to close this early. With something as delecate as this, it should be done by the book and to the letter of the law. schetm (talk) 01:22, 15 February 2023 (UTC)

I somewhat agree. However because it will reach that point in the next 4/5 days where it can be closed as not-early, putting in a request at CR now would make sense. Whether this is closed by a single editor or a panel, it's going to take probably a couple of days just to read through the discussions much less process it and determine what the consensus is. Sticking in a request now at least allows time to find volunteers for this monster read. Sideswipe9th (talk) 01:27, 15 February 2023 (UTC)

Upon your logic, I've posted a request at WP:RFCL. schetm (talk) 02:03, 15 February 2023 (UTC)

(edit conflict) There is no required duration for an RFC; An RfC should last until enough comment has been received that consensus is reached, or until it is apparent that it won't be. There is no required minimum or maximum duration; however, Legobot assumes an RfC has been forgotten and automatically ends it (removes the rfc template) 30 days after it begins, to avoid a buildup of stale discussions cluttering the lists and wasting commenters' time.

With over five hundred !votes, and a clear consensus in favor of restoring Vector2010, I think this condition has been met. Also, it took weeks for the previous RfC to be closed after I posted on RFCL; I doubt this will be any faster. BilledMammal (talk) 01:28, 15 February 2023 (UTC)

I wouldn't be so quick to say there is a clear consensus for anything. RfCs are not closed based on the numerical distribution of the !votes, consensus is determined by the quality of the arguments as viewed through the lens of policy after all. Sideswipe9th (talk) 01:34, 15 February 2023 (UTC)

I considered quality of argument when making that statement. BilledMammal (talk) 01:40, 15 February 2023 (UTC)

With respect, because like myself you have contributed to the RfC, I would say that you're almost certainly too involved with the discussion to make any sort of objective statement about there being or not being a clear consensus. There's a reason why we ask uninvolved editors to close discussions, and why requests at CR should be short and neutral, with no opinions from the editor requesting the closure. Sideswipe9th (talk) 01:44, 15 February 2023 (UTC)

This isn't an attempt to close, or a request at CR? BilledMammal (talk) 02:00, 15 February 2023 (UTC)

@BilledMammal, I don't want to clog up RFCL with a response to you there, but (A) I can't imagine one single editor would want to take this one on his/her own and (B), there's recent precident that massive discussions on Wikipedia are closed by a panel - see Wikipedia:Articles for deletion/Mass killings under communist regimes (4th nomination) for a comparitive discussion. Ultimately, the decision will be up to the closer(s). schetm (talk) 02:23, 15 February 2023 (UTC)

It's partly to avoid setting that precedent that I made that comment; while large RfC's can be closed by a panel, there isn't a requirement that they must, and I want to avoid creating such a requirement. BilledMammal (talk) 02:26, 15 February 2023 (UTC)

I was planning on sitting this "should be closed by a panel" discussion out because as far as such calls go it's more reasonable than most. But I 100% agree with BilledMammal that we need to avoid creating an expectation of this kind. We don't have enough editor hours as is to maintain all our processes and so spending multiple editor's time on something should be done only in exceptional circumstances, not that just because something is long and/or important. Best, Barkeep49 (talk) 02:32, 15 February 2023 (UTC)

If there's such a thing as an exceptional circumstance, it's this. This RFC could effect how everyone in the English speaking world experiences Wikipedia. I personally think that it would be improper for this to be closed by a sole editor. But, to be conciliatory, I've amended my close request to reflect a sole editor doing this. schetm (talk) 02:46, 15 February 2023 (UTC)

I believe that a no consensus would default to a return to V10, and there also appears to be a consensus that the past RfC which first introduced V22 was flawed, but people are saying that there is no clear indication as to what the WMF might do regardless of how this closes. WikEdits5 (talk) 02:36, 15 February 2023 (UTC)

Right, WMF has not said that they will respect the results of this discussion. I am convinced they intend not to, as they did in 2013. Meanwhile, it seems it may not be possible to force the implementation on our end. I am bracing for a storm. —Compassionate727 ^(T·C) 13:44, 15 February 2023 (UTC)

Oh, there's roughly a 0% chance they actually honor the results here. Like with VisualEditor, they clearly want this out now, community be damned. Toa Nidhiki05 15:06, 15 February 2023 (UTC)

WMF would be wise to respect the autonomy of the wikis and the consensus of the communities. Community relations has been improving lately. Would be disappointing to see a setback. –Novem Linguae (talk) 21:19, 15 February 2023 (UTC)

The WMF Chief Product and Technology Officer has responded to the RfC, and they said:

"I worry that RfCs are not an effective way to plan for and execute software development projects, and I would like to create more effective spaces across communities"

So it seems that not only are they not going to rollback V22, they are also questioning the legitimacy of the RfC do deal with this issue. WikEdits5 (talk) 00:37, 18 February 2023 (UTC)

The idea that there will be an expedited closure of a discussion that is 7.5 tomats (.75 decatomats) is pretty funny. At an average reading speed of 300WPM this discussion will take over ten hours just to read. Further clarifications and weighing will ramp that up. I think expedited is the wrong word to use here. ScottishFinnishRadish (talk) 13:56, 15 February 2023 (UTC)

Keep in mind that term was introduced a week ago, where an immediate request for closure probably would have resulted in the discussion being closed before thirty days ("expedited" in a particular sense of the word, although I agree it may not be the best description). However, the closure request was only just now posted, so obviously, that will not happen. —Compassionate727 ^(T·C) 16:33, 15 February 2023 (UTC)

Well, an expedited close would have been possible a week ago, but of course that is no longer the case. InfiniteNexus (talk) 18:05, 15 February 2023 (UTC)

Closure request

The discussion seems to have wound down over the last couple of weeks, and new !votes seem to be trickling in at a fairly steady 2:1 rate and mostly not brigning any new arguments either. How does everybody feel about submitting a WP:CR? Daß Wölf 13:06, 5 March 2023 (UTC)

A closure request was made over two weeks ago. schetm (talk) 13:26, 5 March 2023 (UTC)

Sorry, thanks for pointing that out. I skimmed the CR page looking for this but somehow managed to miss it, so I assumed it was removed/archived... Daß Wölf 13:59, 5 March 2023 (UTC)

Radlrb's comment

@Soni: The hatting apparently breaks the numerical sequence of !votes. I propose to move the entire commentary to Radlrb's !vote in a subsection of the discussion subpage: Wikipedia:Requests for comment/Rollback of Vector 2022/Discussion. @Radlrb: Is it okay for you if we move the discussion there? Æo (talk) 18:10, 14 March 2023 (UTC)

Totally! Whatever works best and maintains the intended flow, though if we can work out somehow to keep it in the mainspace that would be preferable. Maybe keep a small copy of the vote and commentary would also be appropriate, with a note directing readers to the full discussion. Thank you. Radlrb (talk) 18:17, 14 March 2023 (UTC)

@Radlrb:  Done. Of course I have added a direct link to the new location. Now please add a summary of your views about V22 yourself. You can restore part of your original comment, if you wish.--Æo (talk) 18:35, 14 March 2023 (UTC)

Final numbers

Main proposal: (355/226/24)—61.1% support.
Text width: (93/64)—59.24% support. Snowmanonahoe (talk) 16:02, 15 March 2023 (UTC)

Where does this rank in terms of RFC sizes in Wikipedia history? schetm (talk) 16:59, 15 March 2023 (UTC)

@Schetm: The only other page that is explicitly an RFC on WP:300 is Wikipedia:VisualEditor/Default State RFC. Some of the other discussions on WP:300#Miscellaneous are arguably RFCs. Snowmanonahoe (talk) 17:49, 15 March 2023 (UTC)

Ticket needed

Tracked in Phabricator
Task T332505

Tracked in Phabricator
Task T332426

With "rough consensus to make unlimited width the default" being found, someone will need to open feature requests to (a) make this be something that is configurable in the software, and (b) set that configuration to wide for enwiki. — xaosflux ^Talk 14:42, 16 March 2023 (UTC)

Ping to RFC initiator: @HAL333:. Please provide your phab ticket numbers here for reference when created. — xaosflux ^Talk 14:44, 16 March 2023 (UTC)

I've opened T332426; comments + edits welcome. – SJ + 18:57, 17 March 2023 (UTC)

@Sj: looks like you only did half of that. Completed with phab:T332505, which is now a blocker. — xaosflux ^Talk 14:06, 19 March 2023 (UTC)

Thanks. Not necessarily a blocker, but the right approach. Appropriate for that to be its own ticket. – SJ + 15:01, 21 March 2023 (UTC)

@Sj it is a blocker because that software capability doesn't exist yet. Building that capability requires someone to code it, which anyone can work on - but until it gets built there is nowhere to specify that option here (as opposed to if that was just going to be a skin-wide change on every project using vector-2022). — xaosflux ^Talk 09:50, 22 March 2023 (UTC)

• Please note, a developer has refused the underlying ticket to enable this to be selectable. — xaosflux ^Talk 16:22, 24 March 2023 (UTC)

Post-close discussion

A huge thank you to Isabelle Belato and Ingenuity for closing this RfC, in addition to Ritchie333 for their help.

• Pinging @OVasileva (WMF), SGrabarczuk (WMF), MMiller (WMF), AHollender (WMF), and SDeckelmann-WMF: The RfC has been closed. What is the WMF's response, and what does the Web team intend to do?
• Unlimited text width needs to be made default per the RfC close, see the #Ticket needed discussion above.
• Should Wikipedia:Requests for comment/Rollback of Vector 2022/Discussion be hatted and closed as well?

InfiniteNexus (talk) 16:32, 16 March 2023 (UTC)

AHollender's account has been globally locked with the summary "no longer work for wmf". Since I think he was the head designer on the Web team, this may delay the team's response. Sojourner in the earth (talk) 17:20, 16 March 2023 (UTC)

That's right, someone brought this up the other day, but I forgot. Hopefully the rest of the Web team will still be able to compose a response within the next few days. InfiniteNexus (talk) 17:24, 16 March 2023 (UTC)

I consider it deplorable that the closers recognized a large influx of new editors, most of whom are readers who wanted to make their voices heard and recognized the point made by experienced editors that this change heavily impacts unregistered users (i.e., primarily, readers), yet nonetheless applied the in-house standard to their detriment: Many of these readers are not familiar with Wikipedia's policy of consensus. The strongest arguments are those based on our policies and guidelines, while the weakest are those based on subjective opinion. As implicitly recognized by the close of the second RfC in favor of unlimited width, those subjective opinions were a refutation of the research the WMF was adducing. The assertion that only those with experience with UI design have opinions worthy of labeling concrete facts is simply not true; the experiences of actual users (readers) are facts, and germane to UI design. Unless the designers are only designing for fellow designers? Not unrelatedly, it's shameful that only after this outcry (I don't believe the percentage ever fell below 60% in favor, despite the high barrier to participation by unregistered users, including finding it in the first place, figuring out the mechanics of editing in a discussion for in many cases the first time, and multiple suggestions that unregistered and new editors—our readers, for whom we write this encyclopedia—should not be allowed to participate or taken seriously when they did; and in the face of a more or less organized effort from friends of the WMF and lovers of the new and shiny, including actual admitted canvassing) did the WMF eventually make the changes required in the previous RfC. Regarding these changes as obviating arguments made on the basis of the non-compliant and buggy software that readers were originally forced to use is torturous logic from where I stand given the rigid weighting of non-insider arguments; the WMF gets to ignore our governance requirements and only after the fact finish work that had already been imposed in its broken form on smaller communities less able or disposed to advocate for themselves and their readers, with no argument penalty for that ignoring, or the arguments that came close to presenting this community's work and the readers existing to support WMF developers with jobs, or the discounting of accessibility issues. But readers' arguments are cast aside on a strict interpretation of weighting arguments grounded in policy more heavily. Yngvadottir (talk) 22:09, 16 March 2023 (UTC)

As much as I agree with your sentiments, there is no point in continuing to argue. The RfC has been closed, the closers evaluated all arguments and concluded that no consensus was reached, and so now we move on. What we need to do now is compile a list of the most pressing concerns raised in the RfC so the WMF can prioritize its next steps. InfiniteNexus (talk) 22:16, 16 March 2023 (UTC)

I disagree. Expecting people to accept not just one, but two closures that are, at best, unorthodox and at worst patently against the consensus of editors is asking too much. If that's the response to this ordeal - to tell people to shut up and keep their head down - good luck with that. It's going to take more than a few bug fixes to repair the massive damage and loss of faith the WMF has yet again so graciously gifted the community. Toa Nidhiki05 23:53, 16 March 2023 (UTC)

It does raise the question of whether "no consensus" means that we should accept the change as a fait accompli or default to the status quo ante. Certes (talk) 22:55, 16 March 2023 (UTC)

Isabelle Belato addressed this in their close—Since we see the changes made by the WMF as compliance with the previous RfC, this means the previous close stands.

'The previous RFC' referring to Wikipedia:Requests for comment/Deployment of Vector (2022). Snowmanonahoe (talk) 23:02, 16 March 2023 (UTC)

We should simply not accept this incorrect close at all!! Tvx1 07:10, 19 March 2023 (UTC)

There was a very clear consensus, but closers simply mispresented it. Their evaluation is simply incorrect and should not be accepted in any way.Tvx1 07:13, 19 March 2023 (UTC)

There is another discussion on this at the village pump BilledMammal (talk) 23:07, 16 March 2023 (UTC)

And another discussion here. Æo (talk) 00:55, 17 March 2023 (UTC)

Knew this was gonna be the result from the start. This entire discussion was a waste of time because the result was pre-ordained from the start. Hundreds and maybe thousands of community hours wasted in two RfCs where the close clearly went against consensus. Toa Nidhiki05 23:46, 16 March 2023 (UTC)

• This was a good, fair, balanced close. Kudos to both Isabelle Belato and Ingenuity for taking this one. ThadeusOfNazereth(he/him)^{Talk to Me!} 16:02, 17 March 2023 (UTC)
  • TON: agreed, thanks to both closers. As with other close issues, one could also imagine a balanced close with a different outcome. Nidhiki, we definitely need faster + more efficient ways to identify + resolve design and rollout problems. Any time it gets to the point of a contentious RfC, something has gone seriously wrong. (RFCs don't have to be a waste of energy for changes like this, they can be a sanity check after identifying and addressing all major issues. But in that case the proponent should be ready to close it quickly if the check shows obvious problems remain.) – SJ + 18:57, 17 March 2023 (UTC)

It’s not a surprise people who opposed (like yourself) agree with the close and people like myself (who supported) don’t. The problem comes with how hilariously outnumbered the opposes are. Going against that requires a pretty firm reason and I didn’t see it in either review - to say I’m unimpressed with the closure’s rationale and justification is beyond an understatement.

But as I said, it doesn’t matter because this was never going to be overturned - and in fact, I doubt the WMF will even comply with the unlimited width consensus. So much time unnecessarily wasted. Toa Nidhiki05 22:43, 17 March 2023 (UTC)

Thanks, Sj, for recognizing that there was a serious problem with this rollout. It bears repeating that the new skin was imposed without addressing the requirements of the previous RfC, and necessary changes were only slowly made thereafter. The devs deserve no credit whatsoever for not fixing these issues before rollout, or for the tenor of their responses to reports of problems up to and including users being unable to figure out how to log in. Toa Nidhiki05, responding to bad changes to the software we have to use here, and holding the WMF to account, are never wastes of time. Sometimes we succeed, as with Mediaviewer (which gave me instant eyestrain headaches, and is now opt-in on this project), sometimes we don't. But if we don't respond, the WMF will take it as acquiescence to their treating the projects like social media, where our participation is for the benefit of their company and at their pleasure, rather than as collective production of a repository of knowledge.

The two closers undoubtedly felt constrained to close the discussion in accordance with prevailing guidelines, weighting opinions according to their invocation of PAG and employing our idiosyncratic definition of consensus, which does not correspond at all to numerical strength. But there was no need for them to ignore the WMF's having made the change without taking any account of the earlier RfC, tacitly accepting it as good enough that they eventually remedied that. And there was no need for them to dismiss the statements of actual readers that the change degraded their experience of the site, and instead to favor the statements of WMF people and others that readers prefer short lines; this is not article space, where published research trumps all, and people are accessing the site on a wide variety of devices and, I presume, consulting Wikipedia pages for a variety of reading purposes not all of which may have been captured in the research into reading. (To say nothing of the accessibility concerns that the close mentioned, which should weigh heavily.) The close was unnecessarily rude and dismissive. It applied insider standards only, to an issue involving our readers more than our editors, but the closers do not appear to have considered the broader perspective. It was in short myopic as well as insensitive. The WMF habitually forgets our purpose here. I am exceedingly unimpressed when our admins do so. Yngvadottir (talk) 02:46, 19 March 2023 (UTC)

Cessaune, an avid supporter, said I disagree with the outcome, but I agree with your reading of the RfC. It was a tough decision, and you laid out points very clearly. Aaron Liu (talk) 13:38, 19 March 2023 (UTC)

Isabelle Belato and Ingenuity - I do have to give great kudos for this close. I can imagine it be very difficult to close a discussion where the closer obviously might have an opinion one way or another, especially when the close will one way or another make some parties unhappy with the decision. I have to applaud both of you for taking your best effort for the close. Aasim - Herrscher of Wikis ❄️ 17:26, 19 March 2023 (UTC)

I don't see why they should be applauded in any way. Their close is a complete and utter misrepresentation of the discussion. Tvx1 19:00, 20 March 2023 (UTC)

This is such a petulant response. — The Hand That Feeds You:^Bite 16:12, 21 March 2023 (UTC)

Given you were in the minority that opposed rollback, that doesn't surprise me. However, a clear, decisive majority supported rollback, so it's not a surprise a close that tries (and fails) to justify a "no consensus" ruling would get some pushback.

I applaud the closers for putting in effort, but I'm not going to applaud a defective and incorrect close, myself. No need to sugarcoat it, honestly. And if my sneaking suspicions are correct (WMF will never, ever, ever concede on unlimited width), that makes the close even less defensible. Toa Nidhiki05 17:26, 21 March 2023 (UTC)

@Toa Nidhiki05, as WP:!VOTE clearly says, the strength of the comments, rather than number thereof is what is weighed, so givingclear, decisive majority as a reason is meaningless, especially given negativity bias. You may disagree with the close, and I disagree that unlimited should be made the default, but the closure itself was reasonable and well-thought-out. Please don't insult the closures by calling the closure defective. Finally, how does WMF not conceding on unlimited width make the close less defensible? — Qwerfjkltalk 17:38, 21 March 2023 (UTC)

I'm well aware of what consensus is, thanks. The problem, of course, is that the arguments against were not stronger than those in favor, and on top of that many of the oppose votes were canvassed out-of-site. I don't believe the close was reasonable or well thought-out, and I will continue to call the close defective, because that's what I think it is; if a review discussion does begin at some point (and I suspect it will, once the WMF actually admits their plan in the next week or two), I'd support overturning the close. I'm not obligated to agree with the close, nor to respect it, and I'd suggest you exert energy elsewhere other than criticizing people for not agreeing with clearly controversial close. Toa Nidhiki05 17:51, 21 March 2023 (UTC)

many of the oppose votes were canvassed out-of-site I wouldn’t call sixteen many out of 226. Aaron Liu (talk) 18:01, 21 March 2023 (UTC)

I'd suggest you exert energy elsewhere wise words indeed. — Qwerfjkltalk 21:49, 21 March 2023 (UTC)

Not it was not reasonable, nor well thought-out. It was a biased close that set out to reach a certain pre-desired conclusion right from the start. The support comments were put through a rigorous scrutiny, in order to be able to all but dismiss them, they never even started to subject the oppose comments to. Tvx1 01:25, 23 March 2023 (UTC)

@Tvx1: I have to agree with your description. I don't think it was written in bad faith, but I had the same impression when I first read the closing note. The direction of the conclusion seemed to be decided from the very first words of the note, and in it the support !votes were analysed and divided into different categories, while the oppose !votes were not. Æo (talk) 12:20, 23 March 2023 (UTC)

I also agree with the third sentence. Aaron Liu (talk) 13:37, 23 March 2023 (UTC)

And if my sneaking suspicions are correct

So we're at the conspiracy theory stage of this temper tantrum, then. Got it. — The Hand That Feeds You:^Bite 18:23, 21 March 2023 (UTC)

Let’s refrain from ad-hominem.

That being said, I still don’t see how WMF not respecting a consensus to rollback is different from not respecting a consensus to unlimited the width, and Toa has declined to clarify further. Aaron Liu (talk) 18:32, 21 March 2023 (UTC)

You don't think the WMF is going to "get back to you all next week with more details and a proposal for concrete next steps, as well as a general update on ongoing work", HandThatFeeds? Because that's what they've said they'll do. All my sneaking suspicion is, is that when they do announce this, they won't agree to unlimited width as default; that's hardly a conspiracy theory, given how core this design philosophy seems to be to them. I'd be pleasantly surprised if they listened to the community on this, of course. Toa Nidhiki05 19:09, 21 March 2023 (UTC)

I already unwatched this page, please don't ping me back to it. I don't care, waste all your time trying to fight this change if you want. It just strikes me as childish. — The Hand That Feeds You:^Bite 19:12, 21 March 2023 (UTC)

If you don't want people to ping you, or respond to you, don't respond, and don't accuse them of conspiracy theories. Even a child can understand that. Toa Nidhiki05 19:23, 21 March 2023 (UTC)

If you don't want to continue participating in something, just don't respond, no need for such petulant responses. Aaron Liu (talk) 21:18, 21 March 2023 (UTC)

March 16 brief update from the Web team

Hi everyone,

Once again, thank you all so much for your participation in this conversation, and specifically to the closers @Isabelle Belato, @Ingenuity, for taking the time to read over and analyze the entire discussion - it was an exceptionally long conversation. We wanted to confirm we're aware of the closure and let you know we have begun to discuss and evaluate different options for the width of the page and other next steps. Our plan is to get back to you all next week with more details and a proposal for concrete next steps, as well as a general update on ongoing work. OVasileva (WMF) (talk) 23:33, 16 March 2023 (UTC)

Can you explain what you mean by “evaluate different options”? There is only one option; unlimited width as default. BilledMammal (talk) 00:05, 17 March 2023 (UTC)

Several questions:

1. Who is leading this project now given the recent staff turnover?
2. How will this impact the implementation of unlimited width as the default?

A timeline for compliance - or more specifically, whether the WMF plans to comply with the result of this RfC - would not only be welcome, but should be expected, and I would argue this is integral to whatever acceptance this RfC close will see. Toa Nidhiki05 00:08, 17 March 2023 (UTC)

Hey @Toa Nidhiki05. I'll only explain the simplest part. The project lead is Olga, the Product Manager of the team. There's been no change about that since the project kickoff. SGrabarczuk (WMF) (talk) 01:14, 17 March 2023 (UTC)

@Toa Nidhiki05 see #Ticket_needed above, don't think anyone has actually filed these feature requests yet, feel free to for tracking and accountability purposes. — xaosflux ^Talk 15:09, 17 March 2023 (UTC)

The long-standing practice on English Wikipedia is that, in the absence of consensus, the status quo ante prevails, even if this involves reverting a bold change. Do you intend to follow this convention by restoring Vector 2010 as the default skin and, if not, why not? Certes (talk) 11:36, 17 March 2023 (UTC)

@Certes: The closers of the RFC have decided that no consensus means the previous RfC stands, which was supportive of the close: Since we see the changes made by the WMF as compliance with the previous RfC, this means the previous close stands. Snowmanonahoe (talk) 13:28, 17 March 2023 (UTC)

The previous RFC’s close was incorrect too. Tvx1 07:19, 19 March 2023 (UTC)

No it wasn't, the changes that the closers specified had to made weren't made and WMF changed it. However when closing this RfC these changes have been made so that stands. Aaron Liu (talk) 13:35, 19 March 2023 (UTC)

It was. The closers falsely claimed there was clear consensus in support of deploying V2022, when in reality the exact opposite is true. Tvx1 19:04, 22 March 2023 (UTC)

1. Even if we're just based on numbers it's 154-165-9 which is 47.0% to 50.3%, so the exact opposite definitely isn't true.

2. Overall, there is a positive reception to the changes. Supporters were enthusiastic in their appreciation of the UX improvements, and most editors currently opposed expressed specific and narrowly-scoped concerns, rather than wholesale objections to Vector 2022. which is true when reading the opposes Aaron Liu (talk) 23:04, 22 March 2023 (UTC)

"To discuss and evaluate different options for the width of the page and other next steps" can't mean anything but to discuss whether or not to ignore the consensus established in this RFC. Such a discussion cannot be taking place in good faith, as this would be nowhere near a justifiable application of WP:CONEXEMPT. The evaluation has already been done here, in great detail. The WMFs job should just be to facilitate the implementation of its conclusions. small jars tc 12:17, 18 March 2023 (UTC)

If the WMF doesn't implement this change I believe we can with Javascript, although as the best solution that I have currently identified is to interpret "limited-width-toggle-off" as meaning "limited-width-toggle-on" and vice versa it would be better for the WMF to do it, as it would be cleaner and more intuitive. BilledMammal (talk) 14:16, 19 March 2023 (UTC)

I concur. Inverting a toggle's function should be manageable. Aaron Liu (talk) 15:24, 19 March 2023 (UTC)

That's good to hear. Does interpret "limited-width-toggle-off" as meaning "limited-width-toggle-on" refer to class names? I'm guessing that would mean it could be done with common.css alone. small jars tc 18:10, 19 March 2023 (UTC)

Yes but just changing the class type doesn't do anything except change its appearance by 0.241516926. We have to change the functionality, and they meant to somehow reverse the functionality. Also, we'd have to do this in MediaWiki:Vector-2022.js/.css , not common. Aaron Liu (talk) 18:17, 19 March 2023 (UTC)

You shouldn’t jump the gun like that. This closure is very controversial and anything but definite. It’s a gross misrepresentation of the RFC. It will be most likely challenged.Tvx1 07:18, 19 March 2023 (UTC)

Closure Review

Someone has requested a closure review of this RFC at Wikipedia:Administrators' noticeboard#Closure review of RFC on Vector 2022. Pizzaplayer219^Talk_Contribs 19:05, 20 March 2023 (UTC)

Facepalm This is never going to end, is it? — The Hand That Feeds You:^Bite 20:16, 20 March 2023 (UTC)

I've boldly closed that review. While a review is needed, that review is not it. BilledMammal (talk) 20:58, 20 March 2023 (UTC)

I agree with BilledMammal's procedural close. The request for review opened by Tvx1 was hasty and not well-thought-out. Æo (talk) 21:27, 20 March 2023 (UTC)

And are you going to present you're "well-though-out" alternative now then? Tvx1 20:41, 22 March 2023 (UTC)

So a couple of admins can overrule the majority of users, and an appeal is shot down as too hasty. How long do we need to wait, exactly? Ann Teak (talk) 22:54, 20 March 2023 (UTC)

@Ann Teak: I also support an appeal for review, but Tvx1's one was really badly worded. Æo (talk) 23:00, 20 March 2023 (UTC)

So how would we word it better? Ann Teak (talk) 23:03, 20 March 2023 (UTC)

I'm waiting for some additional information from the closer; when the closer has provided it I'll ping you and any other interested editors to help draft a review? BilledMammal (talk) 23:11, 20 March 2023 (UTC)

I've not decided on whether I would support overturning the closure, but I wouldn't mind having some input on how the issues are framed. —Compassionate727 ^(T·C) 02:30, 21 March 2023 (UTC)

Who more do you want from the closer other than “I’m not going to change my mind”?? You’ve declared yourself the sole authority on whether an when a review can take place, well then take your responsibility and start the draft for the wording! Tvx1 18:59, 22 March 2023 (UTC)

Six months, apparently, Ann Teak. Good luck getting anything to happen until then. Toa Nidhiki05 02:34, 21 March 2023 (UTC)

The review will happen. We should all have a chance to discuss the best wording and the best way to bring it to WP:AN. Tvx1's review was poorly-worded and would've inevitably (look at the votes) ended with the close standing. Cessaune [talk] 20:03, 21 March 2023 (UTC)

I agree that review was malformed. I'm of the frame of mind that the WMF should be given an opportunity to comply with the RFC's result. If they don't, it should be reviewed immediately. Toa Nidhiki05 23:09, 21 March 2023 (UTC)

Why should we wait for them to comply with an incorrectly interpreted result that we all want to challenge? Tvx1 19:02, 22 March 2023 (UTC)

So you’re all saying it should be challenged, but no-one has the backbone to actually take the step. And when someone finally does, you all collectively shoot down that person??? What on earth is going on here?? Days and days pass and nothing is undertaken against that ridiculous close.Tvx1 19:07, 22 March 2023 (UTC)

I’ll draft something tonight; the delay is caused due to waiting for a response from the closer. In particular, there is one yes/no question that I want an answer for. BilledMammal (talk) 22:30, 22 March 2023 (UTC)

Still waiting… Tvx1 01:46, 24 March 2023 (UTC)

How long must we let the closers stonewall us? Ann Teak (talk) 00:20, 25 March 2023 (UTC)

You were pinged in the draft discussion. You should head there. Cessaune [talk] 03:13, 25 March 2023 (UTC)

Proposal for next steps following the closure of the Vector 2022 RfC

Hi everyone,

Thank you again for your participation in this conversation. I am Selena Deckelmann, Chief Product and Technical Officer for the Wikimedia Foundation, and I am providing an update on behalf of the teams who work on Vector 2022. We appreciate all of the time you took to help us make the skin better together. We wanted to share a draft of the next steps we are thinking of as a result of the RfC close and get your thoughts on some of the open considerations before proceeding.

Respecting the consensus of the RfC with respect to logged-in users is, as I mentioned before, our recommended approach. We know that rolling back the fixed width (as per the summary statement) will be a surprise to many logged-in users, so we have ideas below on how to make that transition smoothly, and want to hear what you all think.

Based on the data that we have, the research and recommendations for page width, and the new ability of logged-out users (vast majority are readers) to persistently select their preferred width, we don’t think we have the evidence to support rollback for the width for logged-out users. We believe this evidence suggests that readers are receiving the benefits from the width that we hoped they would. We believe that this path forward is aligned with the policy at WP:CONEXCEPT on behalf of readers.

That said, the perspectives of the editor community are an important input to making decisions about readers. Thus, we also want to take further steps to address width for readers and other logged-out users by making it clearer that they have the option to change the width of the page, and add more measurements to determine what the usage of the feature is.

An important technical challenge with all preference changes is that our system does not make it possible to keep choices users have made before a default is changed. This means that logged-in users who have explicitly chosen the limited width may see their preference reverted, and would be surprised or confused by the change. To account for this, we’d like to offer as smooth a transition from a user experience standpoint as we can. With that in mind here is what we propose:

Fixed width vs full width Current state: The fixed width is default for logged-in and logged-out users. Both logged-in and logged-out users can change their preference to full width, persistently.

1. Logged-in users: Roll back to full width, but consider how to allow people to keep their preferred width or to reduce confusion.
   The skin has now been default on English Wikipedia for more than two months. As logged-in users can currently switch to the previous skin or change their width preference in the Vector 2022 skin, we believe that many of the users who are logged-in and still use the limited width do so because of their personal preference. In addition, as many of you have mentioned before, layout decisions made on a specific width might negatively affect readers who are using limited width, as well as mobile users. More consistency across interfaces ensures that layout decisions will work for larger groups of readers and editors. Thus, rolling back might be an unpleasant surprise to many. The risk of making a disruptive change is high in my view based on the low use of the current toggle. With this knowledge, I would like to discuss different options before making a change.

   

   Draft modal design for width selection in Vector 2022

   • Option 1: Our proposal is to display a modal for all logged-in users, asking them whether they would like to keep the limited width, or revert to the full width. This modal might take a few weeks to build. The image above shows an early draft of what this could look like. We can have a further discussion about exact wording and behavior of the modal.
   • Option 2: We roll back to full width for all logged-in users. This change can be made next week.
   • Option 3: Do you all have other suggestions and ideas on how best to do this?
2. Logged-out users: Do not roll back fixed width, but prompt readers to decide the width they prefer.
   • Process: Instead of suddenly changing the width for millions of readers, we suggest displaying a tooltip (ticket that contains an example of what this could look like) for all logged-out users which clearly points to the location of the toggle for the fixed width and explains its purpose. This tooltip will be shown by default for all logged-out users, to ensure that they are aware of the ability to switch width if they want to.

White space concerns

1. Continuing with page layout work: We know that many of you raised the issue of white space as separate from the issue of the width of the page. Specifically, folks have reported that the current amount of white space makes it more difficult to focus on the content, and can potentially cause eye strain for those sensitive to light. To address these issues, we have developed this prototype, and the discussion with community members about how to evaluate it has already begun. We invite you to join it here.
2. Ongoing improvements: In addition to the concrete changes laid out above, we are exploring other ways to address white space concerns. For example, by adding a font size preference, which should make it easier to read overall and increase the overall width of the content (as recommended width is determined by the number of characters per line, not the absolute width of a line), or by adding dark mode to further help those who experience eye strain. Currently, we’re evaluating the possibility of these features in the future, but hope to come back with concrete next steps over the next couple of months.

Reviewing the impact of Vector 2022 in the future

For all of the options above, we will be measuring how many users choose the different options so that we can all look at the numbers together, learn more about peoples’ preferences around the skin, and determine any future actions based on what we learn about default states.

What do you think of the above options? We can begin implementation of either the modal, the tooltip, or both, and start making the switch.

It’s also important for us to continue the conversation on the nature of RfCs for making software decisions. A specific thank you to those who began the discussions on this with us and your thoughts and ideas so far. We would like to continue discussing how we make software decisions together in the future, in processes that promote further representation and earlier community involvement in decision-making than RfCs have so far. We will be beginning a larger conversation on this on the Village Pump over the next few weeks, including specific discussions on some of the ideas you all put forth, such as participation on a committee and explicit community agreement on project metrics.

Thank you,

SDeckelmann-WMF (talk) 18:33, 23 March 2023 (UTC)

As I said before, you’re jumping the gun. The RFC’s consensus is not certain yet and the current close is incorrect and very controversial. It’s going to subject of a full review. Secondly, why not rollback limited-width for everyone. Logged-in users are the least affected as they prefer to use VLegacy instead and the logged-out readers were actually the most vocal about wanting that seen rolled back. Tvx1 19:32, 23 March 2023 (UTC)

"Logged-in users are the least affected as they prefer to use VLegacy instead" — this is blatantly factually incorrect. Please provide any statistics to back up the assertion that logged-in users prefer the legacy skin. 2600:1700:87D3:3460:F106:5B2F:9D72:B3A5 (talk) 20:58, 23 March 2023 (UTC)

Option 3 Why not use the same tooltip for all users, with or without an account? Nonetheless I like this idea. The only thing better than choosing the option most people will like is letting people choose their personal preference. One potential issue that comes to mind is that users won't really understand why the text width would make that much of a difference, pick the option they don't prefer, and then never remember to try changing it. The differences line width makes with reading are quite subtle. Snowmanonahoe (talk) 19:17, 23 March 2023 (UTC)

I like the option of a modal, as this would allow us to gather data. Current data leaves more questions than answers. If we want to gain info from it, the modal should be worded as an equal choice without a default.

I do worry that creating a different experience for logged in users and logged out users will make V22's accessibility issues worse. Many layout problems in V22 fixed width are not evident for those with full width. These issues are now being fixed, which is also great for people with smaller screens. By creating a dual experience, that work will show down. —Femke 🐦 (talk) 19:18, 23 March 2023 (UTC)

Option 2, full width for logged-in users. PC users can change the window size. Mobile users can switch from landscape to portrait. Option 1, a modal, would be an unnecessary slow down for all logged-in users, including those who are happy with the current setting or just do not care. Other, bold suggestion: full width, text columns per paragraph, see User:Uwappa/common.css. Same story for logged out users, no distracting tooltip, simply use full window width and let users decrease window size or switch to portrait. Uwappa (talk) 19:30, 23 March 2023 (UTC)

@Uwappa, as an editor who uses both mobile and desktop devices, I don't think either of your suggestions for dealing with fixed-width help. For turning landscape to portrait, I (personally) would find that very awkward to do.

As for resizing windows, that is something I've seen a lot as an argument. Can you explain how this works? Does this mean that if you were on Wikipedia and found the width too much, you would decrease the width of the window you're on?

Also, please can your reason for being opposed to a modal - how would it slow down users, and how is it unnecessary? — Qwerfjkltalk 21:40, 23 March 2023 (UTC)

Yes, I would resize a window if text was too wide. On my computer it is super + left to get a half-size window on the left side of the screen. Super + right for right half of screen. Super + up to restore full width. Most of the time I use full width. On a mobile, simply turn the phone 90 degrees to switch from landscape to portrait.

Yes, a modal window slows down as it prevents interaction with the main window. NN Group: A model dialog interrupts the workflow. Alan_Cooper calls it "stopping the proceedings with idiocy" in his UI design book 'About Face'.

Proposed alternative: Let designers design something that uses available width. Let users control window width (and font, font size, etc, etc). That is existing, standard functionality, should not be a worry. Uwappa (talk) 22:35, 23 March 2023 (UTC)

Thank you SDeckelmann for taking the time to explain your team's thoughts and progress. The modal and tooltip seem perfectly fine options to me. As Femke notes above, seeing folks' preferences as they interact with the modal will be interesting, as will seeing if more folks use the new text-width-expander button after the tooltip launches (is that something we're able to track?). I'm glad to hear about ongoing improvements to the reading experience. These have been long needed. Ajpolino (talk) 19:51, 23 March 2023 (UTC)

SDeckelmann-WMF, I appreciate your thoughtful engagement with this issue. It bodes well for the future of the relationship between the WMF and the en.WP community. I understand that there is angst among the developers about suddenly changing the width for readers and editors alike, but with respect, we told you in significant numbers that the limited width was a bad idea, or at least poorly implemented, in our first RFC, and the WMF went ahead with it anyway. The WMF sowed the wind, and now it is time to reap. Just bite the bullet and change the default. I hope that the WMF carefully considers what it can learn from this whole experience. I look forward to continued improvements in the Vector 2022 skin, and I will continue to engage on Phabricator and elsewhere with WMF developers who want to make Wikimedia sites better for everyone. Forward together! – Jonesey95 (talk) 20:22, 23 March 2023 (UTC)

Thank you for the words of encouragement, Jonesey95. Our team and I really appreciates all the time you’ve put into collaborating on this project with the team both here and on Phabricator. I’m also optimistic about the future of how we all work together. We will soon be starting a series of conversations on how to improve our decision-making processes and collaboration as a whole - I hope you’ll be able to join us in those conversations, we would value your opinion. I know that introducing limited width did create a significant amount of work for both the developers and our community and I want to extend a thank you to all the volunteer developers and editors who have worked hard to update templates, gadgets, and tools to make sure the content looks great in this new presentation form. This work made reading the site easier for millions of users.

As I mentioned before, I believe that we made the right choice in the introduction of the limited width and that, for readers, we are continuing to make the right choice in the decision to keep it as the default, based on the data that we have, the research and clear recommendations for page width, and the new ability of logged-out users to persistently select their preferred width. For this reason, I cannot recommend that we follow the RfC’s rough consensus for all logged-out users on this point.

That said, the feedback from the community on this issue has also helped us in being able to serve even more users by making the site more customizable to individual preferences. As a direct result of this feedback, right now, all users on the site, logged-in or logged-out, are able to choose and stick with the width they prefer - fixed or limited. And going forward, we’ll now take steps to ensure that all users are aware of their ability to make this choice. We think this approach will allow us to continue serving the majority of users with a default that improves their experience, while allowing those with different needs and preferences to make a choice to change that default for themselves. SDeckelmann-WMF (talk) 21:22, 24 March 2023 (UTC)

@SDeckelmann-WMF: To be clear, we have the ability to implement full width by default ourselves, and while I would prefer you did it as the solution would be cleaner, I have no doubt that we will do it if you continue to refuse. Do you plan to continue to refuse to do so? BilledMammal (talk) 03:30, 25 March 2023 (UTC)

Option 3 - Full width for all users, logged in or otherwise. Assuming this is debatable is ludicrous. —Jéské Couriano (No further replies will be forthcoming.) 20:36, 23 March 2023 (UTC)

Option 3, Unlimited width for everyone as default. This is the most requested thing, even by unregistered readers. The proposed tooltips don’t give an option to select a default, but merely a choice that needs to be remade on every visit. That’s unacceptable. In any case, this survey is taking place to soon. The consensus of the RFC has not been established. The current close is very controversial, so please let the community deal with that first!Tvx1 20:39, 23 March 2023 (UTC)

@Tvx1, The proposed tooltips don’t give an option to select a default, but merely a choice that needs to be remade on every visit. I believe the preference is persistent, as the comment above mentions the new ability of logged-out users (vast majority are readers) to persistently select their preferred width. — Qwerfjkltalk 21:44, 23 March 2023 (UTC)

Still, it remains an unnecessary complication. Just make width unlimited by default and let everyone scale their browser windows to their preferred size.Tvx1 22:07, 23 March 2023 (UTC)

Let everyone do it the way I prefer, which is obviously the right way. ScottishFinnishRadish (talk) 22:13, 23 March 2023 (UTC)

Which is exactly what I said. Let everyonr scale their view of Wikipedia as desired. Don’t enforce any fixed width for anyone. Tvx1 01:42, 24 March 2023 (UTC)

Hi @Tvx1 - thank you for your feedback. I just wanted to jump in and confirm that the options for selecting a user's preferred width (whether that is full or fixed width) will continue to be available for all logged-out and logged-in users and will persist across pages for both logged-in and logged-out users. OVasileva (WMF) (talk) 14:55, 24 March 2023 (UTC)

Option 3 - I think the page width should still be capped, but the cap should be very very large. Somewhere along the lines of the span of a 16:9 or 3:2 monitor. Any wider should automatically limit the width. Also, I would propose replacing the toggle with the option to drag and resize the content of the window to set their preference as needbe. Wikipedia should certainly experiment with different configurations to provide the right amount of information density while not wasting any usable space. That is not what I am seeing though. Aasim - Herrscher of Wikis ❄️ 22:16, 23 March 2023 (UTC)

@SDeckelmann-WMF: why are we having these discussions in such an obscure place as the talk page of a closed RFC? I'm not sure but I feel like WP:VP/PR would be better. small jars tc 22:22, 23 March 2023 (UTC)

Agreed. I've added a link to this section to Village pump (WMF). Maybe we should consider adding it to centralized discussion too? Actually, I just noticed the WMF plans on making a larger discussion on VP later, so hold off on that for now. Snowmanonahoe (talk) 22:39, 23 March 2023 (UTC); edited 22:54, 23 March 2023 (UTC)

Ah, yeah, thank you. I wasn't trying to obscure the conversation, but more attempting to keep the conversation in the most logical place associated with the RfC. I'm going to be out of office next week, but when I return, I'll spend some time thinking about how best to approach these conversations. Something I could do is whenever I post something I think is worth discussion, I could also post to a page hanging off my user page, for example. I welcome advice on what would be helpful to those who are interested. SDeckelmann-WMF (talk) 21:18, 24 March 2023 (UTC)

Option 3, Unlimited width for everyone as default. This is the consensus, and if you don't implement it we can and will. BilledMammal (talk) 23:02, 23 March 2023 (UTC)

Do you have a reason beyond it simply being "the consensus"? The RfC was about which width is most likely to be preferred by the most users. If we allow users to pick, this isn't an issue. Snowmanonahoe (talk) 23:17, 23 March 2023 (UTC)

I don't have an issue with allowing users to pick. The issue is the WMF is telling us that they want to keep limited width as default for logged out users, and instead make the toggle-width button slightly more accessible.

I fully support them making the toggle width button more accessible (although I do have some concerns that a prompt that shows up every time a user is unrecognized might disrupt the reading experience, and believe there are likely better ways to explain what the button is - perhaps by getting rid of mystery meat navigation), but with full width as the default. BilledMammal (talk) 23:46, 23 March 2023 (UTC)

I also have two issues with the option one popup. The first is that it is not neutrally worded, and the second is that it will delay the implementation of consensus by at least a few weeks. If it is worded neutrally, and if the WMF can have it ready within a week, then I have no objection to it - if it is not ready, then editors will still have a choice through the current toggle width button, which I note they considered sufficient when the default was their preferred option. BilledMammal (talk) 00:15, 24 March 2023 (UTC)

No it wasn’t. Tvx1 01:43, 24 March 2023 (UTC)

Then what was it about? Snowmanonahoe (talk) 01:45, 24 March 2023 (UTC)

The first was about gouging support to deploying V2022, the second one about rolling back its deployment. Tvx1 04:32, 24 March 2023 (UTC)

@Tvx1 Please see Make unlimited width the default Aaron Liu (talk) 19:06, 24 March 2023 (UTC)

Support Snowmanonahoe's Option 3, with option 1 as a second choice. Giving all users this choice is a good idea. I imagine there will be a good subset of users who would prefer having a set width for accessibility/readability reasons. Wikipedia's own article on line width cites a study that indicates that some users prefer longer text lines while other users prefer shorter text lines. Aoi (青い) (talk) 23:30, 23 March 2023 (UTC)

Giving all users this choice is a good idea. – I need to stop repeating this, but default fullwidth (i.e., the consensus established in this already-closed, month-long RfC) is the easiest, least bug-prone, and most familiar way of providing this choice to users. Window resizing is about the second thing anyone ever learns about how to use a window manager, which has been the form of almost all desktop operating systems for several decades (with a few much hated exceptions). On the other hand, a modal will inevitably be clicked through at high rate with little thought, and the WMF's design will inevitably lead the eye towards the button that enables their faddy pseudo-technocratic line width constriction. small jars tc 00:44, 24 March 2023 (UTC)

I don't think there are many people who bother with the effort of resizing windows to desired width for every website they visit, not to mention it's something you'd have to do every time you visit the site. I also feel faddy pseudo-technocratic line width constriction is an excessive description considering there is actual research that backs it up, and most of the internet at least somewhat abides by these guidelines. I agree that the proof of concept of the modal isn't quite neutral, but keep in mind that because of the amount of editors already noting this fact it probably won't actually look like that if it is implemented. Snowmanonahoe (talk) 00:57, 24 March 2023 (UTC)

Why would you need to change it for every site? You can, which is nice, but it's unlikely that someone's comfortable reading width would be dependent on what site they're on, unless they visit a site with excessive and constrictive styling that messes up the connection between their setup and their experience... which is currently what Wikipedia is. small jars tc 01:13, 24 March 2023 (UTC)

@small jars, just personally, whilst I know how to resize a window, it has never occurred to me to do that because I don't like the width of a website. — Qwerfjkltalk 07:14, 24 March 2023 (UTC)

That suggests to me that too much line width is not a problem for you, at least bounded by your screen width. This is anecdotal evidence, but I help out in a IT class in my school, using medium-sized monitors: for most students I see there, it seems like wider is always treated as better, so they only resize when they want multiple things on screen at a time, and then stretch one thing back out when they're done with that. Personally, I do often want a narrower width, and get that by resizing, but I've always assumed that needing that was something to do with my dyslexia (of course it could become more general if you’re using a massive monitor or something). small jars tc 09:51, 24 March 2023 (UTC)

• Option 3, but Option 1 is better than 2. I still prefer limited width as the default for everyone, but failing that, showing a modal is better instead of a sudden change. EpicPupper (talk) 23:35, 23 March 2023 (UTC)

  Don’t you mean unlimited width? Tvx1 01:44, 24 March 2023 (UTC)

  There are improvements with limited width, and but failing that clearly indicates that they meant limited. Aaron Liu (talk) 19:07, 24 March 2023 (UTC)

• Follow Consensus as established in Isabelle Belato's close. If it gets reclosed, changes can easily be reversed. With regards to the second question presented in this RfC, arguments presented by both sides were very similar to the first question, in that some like the new limited width and others do not. Some of those supporting an unlimited width noted that many articles contain galleries, tables, etc., and were negatively affected by the new width. There was a lot of discussion on whether scientific papers reached any form of consensus on the best width, with both sides presenting studies with opposing views on the issue. The large amount of whitespace was one of the main concerns of those who supported the rollback of Vector 2022. Since the arguments are equal in strength, there is rough consensus to make unlimited width the default. Also per this close, Another point of contention was the fact that, while it is trivial for registered users to change back to the old skin if they dislike the changes, unregistered users do not enjoy that option. Many of those supporting the rollback were sympathetic editors who saw this as problematic. The only refutation offered to this was that the new skin was shown to be, according to the aforementioned studies and surveys, an improvement for readers, especially due to the reduced text width, implying that any change that only applies to registered users is missing the point. I feel that we are being dragged through the same time-wasting discussion again in the hope that chance (and manipulative framing, where the actual consensus is only implicitly a choice via option 3) might push consensus a different way. small jars tc 23:59, 23 March 2023 (UTC)
• Anything short of following community consensus is unacceptable Unlimited width should be default. If the WMF is unwilling to make this good-faith measure, the RfC should be overturned and the result changed to Consensus to roll back default. Toa Nidhiki05 00:23, 24 March 2023 (UTC)

  This doesn't make sense. Why should consensus be changed on the basis of someone not following it? Retribution? there might be other reasons that the RfC needs reclosing, but not this. small jars tc 00:29, 24 March 2023 (UTC)

  Given that fixed width is the number-one complaint people have, the idea that there's no consensus to rollback even if it says seems extremely tenuous. Tying both aspects of the RfC together seems reasonable. Toa Nidhiki05 00:36, 24 March 2023 (UTC)

  Yeah, but WMF doesn't have to do that. They could literally pick anything they wanted to keep and ignore the rest per CONEXEMPT. Cessaune [talk] 03:15, 25 March 2023 (UTC)

• Strongly oppose creating two different experiences for logged-in user and logged-out users by default, per Femke and the previous discussion on this idea which does not seem to be reflected in this new proposal. This idea did not receive support after it was last proposed, is not what the RfC suggested, and is simply a very poor idea. Editors edit based on what they see as readers, if there is a different default experience then editors won't be editing for what the majority of people see. (As a side-note, amused by the argument "Instead of suddenly changing the width for millions of readers" given the context.) CMD (talk) 01:10, 24 March 2023 (UTC)

Didn’t we already have a consensus at the RFD? Why are we discussing this again? Did I miss something? The close in the RFD literally says there is rough consensus to make unlimited width the default. Pizzaplayer219^Talk_Contribs 02:21, 24 March 2023 (UTC)

The WMF has deemed that a stupid-ass decision and elected to ignore it. Toa Nidhiki05 03:18, 24 March 2023 (UTC)

• I don't think we should do Option 2 - existing logged in users may have set/unset/set again this and got it working just as they like it already, so don't force a change on them. phab:T332505 has already been created to request functionality to be created to allow this to be a project setting, and how the default should apply to new registered users — xaosflux ^Talk 12:34, 24 March 2023 (UTC)

  @Xaosflux: unbolding to prevent misread as "support option 2" Aaron Liu (talk) 19:21, 24 March 2023 (UTC)

• I think we should randomize the width and then you only get the page if you guess the correct value. (yes, sarcasm) —TheDJ (talk • contribs) 14:21, 24 March 2023 (UTC)

  More seriously. I think this is VERY unwise. This is the moving of goal posts just because some people want to be uncooperative. This makes WMF very vulnerable, all because we want to keep it moving forward. I have said this many times in the past, it is unwise to give this much freedom and options to the community. People will NEVER be satisfied and they will always be the ones who turn up. en.wp doesn't get a say in this other than take it or leave it. Switch everyone BUT en.wp over and then degrade their experience like EVERY other site in the world does. —TheDJ (talk • contribs) 14:43, 24 March 2023 (UTC)

  Many sites degrade the experience to fit in ad sidebars. Wikipedia doesn't need to do that, even if the change necessary for those other sites is given a positive spin. Certes (talk) 15:12, 24 March 2023 (UTC)

  Yup and you don't have to use those sites either. —TheDJ (talk • contribs) 15:41, 24 March 2023 (UTC)

• Note: as phab:T332505 (allow a setting for default state of vector 2022-width) has been declined the request to set it for enwiki (phab:T332426) is now impossible. Someone would need to challenge that decline and reopen the ticket to get those requests moving again. — xaosflux ^Talk 16:26, 24 March 2023 (UTC)

  Note: These are now back to blocked on development / Stalled on blocked. — xaosflux ^Talk 17:30, 24 March 2023 (UTC)

  Perhaps we should just decline Vector 2022, just temporarily while the promised changes are stalled or blocked. Certes (talk) 18:08, 24 March 2023 (UTC)

  @Certes: We can't just "decline" V22, this is a server-side config change that we can't make through editing due to the JS/PHP/Mustache/HTML/IDK nature of skins.Aaron Liu (talk) 19:21, 24 March 2023 (UTC)

  Note: It was closed by TheDJ who is not with WMF.Aaron Liu (talk) 19:21, 24 March 2023 (UTC)

  But is a MediaWiki developer. —TheDJ (talk • contribs) 22:07, 24 March 2023 (UTC)

• Option 4: As Xaosflux proposed, make unlimited width the default for new editors and don't touch existing editors' settings. I'm still mixed on IP editors as WMF has a valid point on this and I've been mixed on this throughout the RfC, and it was closed 92 to 64. Aaron Liu (talk) 19:21, 24 March 2023 (UTC)

  TBF, I documented the second part of that, but didn't propose it. But agree that existing end users should be left alone. — xaosflux ^Talk 20:03, 24 March 2023 (UTC)