Wikipedia:Village pump (proposals): Difference between revisions
→RfC Discussion: Reply |
|||
Line 700: | Line 700: | ||
==RfC: Should Wikipedia return to Vector 2010 as the default skin?== |
==RfC: Should Wikipedia return to Vector 2010 as the default skin?== |
||
{{Moved to|Wikipedia:Requests for comment/Rollback of Vector 2022|2=[[User:InfiniteNexus|InfiniteNexus]] ([[User talk:InfiniteNexus|talk]]) 01:09, 21 January 2023 (UTC)}} |
|||
<!-- [[User:DoNotArchiveUntil]] 21:01, 23 February 2023 (UTC) -->{{User:ClueBot III/DoNotArchiveUntil|1677186079}} |
|||
{{rfc|style|prop|tech|rfcid=4A94D3E}} |
|||
{{not a vote}} |
|||
Should Wikipedia return to Vector 2010 as the default skin? ~ [[User:HAL333|<span style="background:red; color:white; padding:2px; border:1px solid red;">'''HAL'''</span>]][[User talk:HAL333|<span style="background:black; color:white; padding:2px; border:1px solid red;">'''333'''</span>]] 20:32, 19 January 2023 (UTC) |
|||
:Also see [[#Question_#2:_If_the_new_design_is_kept_as_the_default,_then_should_unlimited_text_width_be_the_default?|Question #2: If the new design is kept as the default, then should unlimited text width be the default?]] |
|||
---- |
|||
===Discussion=== |
|||
====Support==== |
|||
#'''Support as nom''' The WMF unilaterally forced the 2022 vector skin upon the community, despite a [[Wikipedia:Requests for comment/Deployment of Vector (2022)|community wide discussion]] that found there was no consensus for such a change. The [[WP:ONUS|ONUS]] was on the WMF to convince the community and they ''failed''. And the argument that we editors are but a small portion of Wikipedia users is dead on arrival: IP editors and readers are unable to use anything besides the 2022 skin. The WMF had decided that they have no choice, and no voice in this affair. The 2022 skin itself is inferior to its 2010 predecessor. It's indulgent, made by people with at most a modicum of editing experience, and poorly made, with excessive white space and spawning sandwiching and myriad other issues. Let's return to what worked. Let's return to what billions of readers of Wikipedia have been completely content with for over a decade. In brief, '''If it ain't broke, don't fix it.''' ~ [[User:HAL333|<span style="background:red; color:white; padding:2px; border:1px solid red;">'''HAL'''</span>]][[User talk:HAL333|<span style="background:black; color:white; padding:2px; border:1px solid red;">'''333'''</span>]] 20:32, 19 January 2023 (UTC) |
|||
#:So Wikipedia should never change, for all time? [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 20:43, 19 January 2023 (UTC) |
|||
#::I commend your straw man. ~ [[User:HAL333|<span style="background:red; color:white; padding:2px; border:1px solid red;">'''HAL'''</span>]][[User talk:HAL333|<span style="background:black; color:white; padding:2px; border:1px solid red;">'''333'''</span>]] 20:51, 19 January 2023 (UTC) |
|||
#:::Can you answer the question? Because that is what you are saying. That no change should ever be implemented because it doesn't please everyone- which is impossible. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 20:58, 19 January 2023 (UTC) |
|||
#::::That is not what he is saying. There is a significant difference between not pleasing everyone and displeasing a large part of your community. Your argument is empty. I logged in for the first time in ages just to revert this unnecessary change that no significant majority wanted. [[User:IronRook|IronRook]] ([[User talk:IronRook|talk]]) 23:54, 19 January 2023 (UTC) |
|||
#:::::Nothing on Wikipedia is determined by a majority vote, but by a consensus along with a weighing of arguments. I can't think of any potential change that wouldn't displease many people- that's a recipe for changing nothing. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 00:12, 20 January 2023 (UTC) |
|||
#::::::An such consensus to apply vector 2022 as default did not exist in any way. The community does '''not''' clearly support this. [[User:Tvx1|T]][[User Talk:Tvx1|v]][[Special:Contributions/Tvx1|x]]1 01:34, 20 January 2023 (UTC) |
|||
#::::::[[Wikipedia:Requests for comment/Deployment of Vector (2022)|The RfC to deploy]] had neither of those. No consensus, and as the closing editors noted, the weight of arguments went against the issue of fixed-width, ie. making editors and readers use limited width instead of allowing them to use full width if they prefer. {{tqq|If all the concerns outlined above are satisfactorily addressed[...]}}, the editors wrote. The WMF has not done this. Instead they added a button readers would need to push on every single page, every single time the readers follow a link or come in from Google or navigate to our site. This is comically inadequate, and it's hard for me to understand why readers would actually do so, instead of being frustrated into giving up and unhappily accepting what they find an inferior viewing experience. As 24.251.3.86 [https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements said on mediawiki], it's "far too burdensome to be useful or practical, and as such, basically may as well not exist for all the good it does." --[[User:Kizor|Kiz]][[Special:Contributions/Kizor|<span style="color:black;">o</span>]][[User_talk:Kizor|<span style="color:green;">r</span>]] 01:57, 20 January 2023 (UTC) |
|||
#:::::::{{tq|readers would need to push on every single page, every single time the readers follow a link or come in from Google or navigate to our site}} This is false. The toggle stays, at least for me. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 02:05, 20 January 2023 (UTC) |
|||
#::::::::Not for me. Going from [[2023 Antiguan general election]] to [[Bruno Rodríguez Parrilla]] to [[Felipe Pérez Roque]] to [[Communist Party of Cuba]] in an incognito window, I have to toggle full width each time. --[[User:Kizor|Kiz]][[Special:Contributions/Kizor|<span style="color:black;">o</span>]][[User_talk:Kizor|<span style="color:green;">r</span>]] 02:15, 20 January 2023 (UTC) |
|||
#:::::::::<s>{{tq|incognito}} is probably the issue, I assume this is implemented with cookies. I'm not sure whether or not this is a problem for the ethos goals though I'm more inclined towards "this is a problem". [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 02:18, 20 January 2023 (UTC)</s> The actual problem is that it doesn't save preferences for those who are logged-out. omg this is so simple why didn't i realize earlier [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 02:30, 20 January 2023 (UTC) |
|||
#::::::::It does not persist for me, and I have cookies enabled. I use Brave btw. Regardless, it is unsurprising to be behaving differently on different systems, something the developers would have to investigate. [[User:Jeremy Jeremus|Jeremy Jeremus]] ([[User talk:Jeremy Jeremus|talk]]) 02:21, 20 January 2023 (UTC) |
|||
#:::::::::@[[User:Jeremy Jeremus|Jeremy Jeremus]]@[[User:Kizor|Kizor]] I just realized the factor was whether or not you're signed in. This is obviously a massive problem that probably won't get fixed (save for defaulting to max width) by WMF because of the {{slink|mw:Reading/Web/Desktop Improvements/Frequently asked questions|Why are there no preferences for anonymous users?|nopage=y}} section in the faq. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 02:29, 20 January 2023 (UTC) |
|||
#::::::::::Reader here (I do not log in, and can't, for various reasons), I'm not enjoying the new design. I had to click that "max width" button 10 times already today. I would prefer the absolute minimum amount of whitespace, I don't get what the point of the padding is, I want to use my whole monitor to read articles. [[Special:Contributions/74.199.75.192|74.199.75.192]] ([[User talk:74.199.75.192|talk]]) 04:07, 20 January 2023 (UTC) |
|||
#:@[[User:HAL333|HAL333]], {{Tq|1= despite a community wide discussion that found there was no consensus for such a change. The ONUS was on the WMF to convince the community and they ''failed''.}} - from the closure of the community wide RfC: {{tq|we see community support to roll out the change}} (though it should be noted that is preceded by {{tq|[i]f all the concerns outlined above are satisfactorily addressed then}}).<span id="Qwerfjkl:1674161074214:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt">— [[User:Qwerfjkl|<span style="background:#1d9ffc; color:white; padding:5px; box-shadow:darkgray 2px 2px 2px;">Qwerfjkl</span>]][[User talk:Qwerfjkl|<span style="background:#79c0f2;color:white; padding:2px; box-shadow:darkgray 2px 2px 2px;">talk</span>]] 20:44, 19 January 2023 (UTC)</span> |
|||
#::@[[User:Qwerfjkl|Qwerfjkl]]: That's a pretty important '''if''' there, isn't it? Makes it a conditional consensus, with the condition being (paraphrased) "concerns in relation to the width, non-intuitive icons and the language selector need to be resolved in a satisfactory manner ''prior'' to roll-out". |
|||
#::Considering that the width, the non-intuitive icons/buttons and, to a lesser degree, the language selector behaviour are the three major returning themes of the many, many complaints across the various relevant noticeboards and talk pages, they clearly have '''not''', in fact, been resolved in a satisfactory manner. |
|||
#::Ergo the condition has not been fulfilled and therefore there is no community consensus ''for this specific roll-out'' of Vector 2022. [[User:AddWittyNameHere|<span style="background:#42024b; color:#fcf09c;">'''''AddWitty'''''</span>]][[User talk:AddWittyNameHere|<span style="background:#fcf09c; color:#42024b;">''NameHere''</span>]] 21:11, 19 January 2023 (UTC) |
|||
#:::@[[User:AddWittyNameHere|AddWittyNameHere]], the main issues noted in the closure were the width and the ToC. There were improvements to these (improvements that I don't have the time to find).<br/>This is hardly, in any case, a damning closure against V22, nor the WMF forcing it on editors. It may not be perfect, but it's hardly worth another huge RfC that is hardly going to be constructive.<span id="Qwerfjkl:1674163227895:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — [[User:Qwerfjkl|<span style="background:#1d9ffc; color:white; padding:5px; box-shadow:darkgray 2px 2px 2px;">Qwerfjkl</span>]][[User talk:Qwerfjkl|<span style="background:#79c0f2;color:white; padding:2px; box-shadow:darkgray 2px 2px 2px;">talk</span>]] 21:20, 19 January 2023 (UTC)</span> |
|||
#::::@[[User:Qwerfjkl|Qwerfjkl]]: You are right, I forgot to add the ToC as another major concern (which happens to also be another recurrent subject of complaints. Such a coincidence). Both the non-intuitive buttons and the language selector behaviour were also explicitly mentioned in the close though. And sure, I don't doubt there have been improvements. That does not make the issues satisfactorily resolved, at this point in time. |
|||
#::::I fully agree it's not a damning closure against V22 or '''eventual''' roll-out. It's a "most of the base concept works, but this, this and this needs to be fixed before it's ready to go live as default setting". |
|||
#::::Some complaints, especially from the daily en.wiki editors? Yeah, that's a given with any large change, and doesn't prove much of anything. But when large amounts of IPs and new accounts (read: Wikipedia's readers, rather than editors) go out of their way to find ''some'' page where they can register their dissatisfaction, and this dissatisfaction almost always is about the very issues that were highlighted as "fix these first, deploy after", that's a pretty clear clue that things were not, in spite of however many improvements may have been made, fixed in a satisfactory manner. |
|||
#::::Whether an RfC is, or is not, a good idea at this point is a second matter. I can see both good reasons for and against it, and which side wins out largely depends on whether or not the WMF can be expected to actually satisfactorily fix these issues now that the skin has been deployed; and on whether or not there is any chance of such fixes happening anytime soon. (Personally, I suspect "yes and soon" for issues that lean towards the 'it's a bug' side of things, but am not quite so sure when it comes to the rest of the issues, especially because communication from WMF employees so far does not seem to actually acknowledge that certain things ''are'' issues in the first place.) [[User:AddWittyNameHere|<span style="background:#42024b; color:#fcf09c;">'''''AddWitty'''''</span>]][[User talk:AddWittyNameHere|<span style="background:#fcf09c; color:#42024b;">''NameHere''</span>]] 22:01, 19 January 2023 (UTC) |
|||
#:::::@[[User:AddWittyNameHere|AddWittyNameHere]], I'm not entirely sure V22 was perfect when rolled out (in fact: it wasn't), but now that it's here, I guess we're stuck with it. Let's just hope that the bugs are resolved and we have a fully-functioning skin (not that V22 isn't functional, and I've never encountered any bugs, but others have).<br/>Ironically, the main complaint I have is that V22 is too wide. I've somehow enabled something that widens V22, but I prefer it narrow, and I catch glimpses of it when pages initially load.<span id="Qwerfjkl:1674166238283:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — [[User:Qwerfjkl|<span style="background:#1d9ffc; color:white; padding:5px; box-shadow:darkgray 2px 2px 2px;">Qwerfjkl</span>]][[User talk:Qwerfjkl|<span style="background:#79c0f2;color:white; padding:2px; box-shadow:darkgray 2px 2px 2px;">talk</span>]] 22:10, 19 January 2023 (UTC)</span> |
|||
#::::::Also, regarding the large number of complaints, that is probably inevitable, no matter what we do.<span id="Qwerfjkl:1674166862267:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — [[User:Qwerfjkl|<span style="background:#1d9ffc; color:white; padding:5px; box-shadow:darkgray 2px 2px 2px;">Qwerfjkl</span>]][[User talk:Qwerfjkl|<span style="background:#79c0f2;color:white; padding:2px; box-shadow:darkgray 2px 2px 2px;">talk</span>]] 22:21, 19 January 2023 (UTC)</span> |
|||
#:::::::{{U|Qwerfjkl}}, I think I can concur with a good portion of that at least from a practical perspective, and the parts I don't quite agree with probably aren't worth further arguing about here, so let's just agree to partially disagree? |
|||
#:::::::Re:your width issue, check your preferences, tab "Appearance". Is the box before "Enable limited width mode" checked? If not, check that to re-enable limited width. [[User:AddWittyNameHere|<span style="background:#42024b; color:#fcf09c;">'''''AddWitty'''''</span>]][[User talk:AddWittyNameHere|<span style="background:#fcf09c; color:#42024b;">''NameHere''</span>]] 23:01, 19 January 2023 (UTC) |
|||
#::::::::@[[User:AddWittyNameHere|AddWittyNameHere]], I agree. And no luck, I have limited width mode enabled.<span id="Qwerfjkl:1674241128199:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — [[User:Qwerfjkl|<span style="background:#1d9ffc; color:white; padding:5px; box-shadow:darkgray 2px 2px 2px;">Qwerfjkl</span>]][[User talk:Qwerfjkl|<span style="background:#79c0f2;color:white; padding:2px; box-shadow:darkgray 2px 2px 2px;">talk</span>]] 18:58, 20 January 2023 (UTC)</span> |
|||
#::::::[[WP:FAIT]] - just because it's been done does not inherently mean it cannot (or should not) be undone. [[User:WalnutBun|WalnutBun]] ([[User talk:WalnutBun|talk]]) 01:57, 20 January 2023 (UTC) |
|||
#::That closure does not accurately reflect community consensus. More people opposed than supported the proposal. There was no clear support at all, but rather strong division. A closure review is warrented here. [[User:Tvx1|T]][[User Talk:Tvx1|v]][[Special:Contributions/Tvx1|x]]1 01:37, 20 January 2023 (UTC) |
|||
#'''At least temporarily go back''' Get feedback from outside of the ivory tower. Fix any clearly identified shortcomings. Then maybe try again. <b style="color: #0000cc;">''North8000''</b> ([[User talk:North8000#top|talk]]) 21:06, 19 January 2023 (UTC) |
|||
#:{{u|North8000}} Community input was solicited and not just from an ivory tower, and there was an RFC that led to the deployment. Disagree with its conclusions if you wish, but it was done. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 21:08, 19 January 2023 (UTC) |
|||
#:::::I was referring to on the specifics. E.G. whether or not to bury and hide very heavily used choices, separating out the question of having all of that blank space etc. <b style="color: #0000cc;">''North8000''</b> ([[User talk:North8000#top|talk]]) 21:17, 19 January 2023 (UTC) |
|||
#::@[[User:331dot|331dot]] It's not like I care since my skin is set to Vector 2010 still, but RfCs that close with 154 supports and 165 opposes should not be considered a success. [[User:LilianaUwU|<span style="font-family:default;color:#00c6ff;">''Liliana''</span><span style="font-family:Comic Sans MS;color:#ff879a;">''UwU''</span>]] <sup>([[User talk:LilianaUwU|talk]] / [[Special:Contributions/LilianaUwU|contribs]])</sup> 21:18, 19 January 2023 (UTC) |
|||
#:::{{u|LilianaUwU}} Nothing on Wikipedia is done by a majority vote, but by consensus and a weighing of arguments. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 21:24, 19 January 2023 (UTC) |
|||
#::::And weighing the arguments you still do not get a consensus in favor in any way. [[User:Tvx1|T]][[User Talk:Tvx1|v]][[Special:Contributions/Tvx1|x]]1 01:38, 20 January 2023 (UTC) |
|||
#:::::You are, of course, entitled to your opinion and to disagree with how the arguments were weighed. But they were. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 01:53, 20 January 2023 (UTC) |
|||
# <del>'''Support with an asterisk''' - a solution that I believe would be of the most benefit would be a button on the sidebar to toggle Vector 2022 and Vector 2010, with the starting position being Vector 2022. I've found that Vector 2022 makes WP annoying to navigate on desktop in non-editing capacities, but I recognize that people do enjoy it. However, the freedom of choice for non-users is absolutely nonexistent, and should be rectified.</del> '''Very weak support.''' I dislike the change, but with the point made by [[User:Terasail|Terasail]] and the fact IPs are unable to choose skins, I can only give a weak support. This is a no-win situation, seemingly. [[User:Lucksash|Lucksash]] ([[User talk:Lucksash|talk]]) 22:30, 19 January 2023 (UTC) |
|||
#:Non users have the same choices users have. According to the information about the skin, there are privacy issues that prevent allowing IPs to choose a skin. Not everything in life can be a choice. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 22:56, 19 January 2023 (UTC) |
|||
#::My mistake - should have done some reading on the nitty gritty coding. [[User:Lucksash|Lucksash]] ([[User talk:Lucksash|talk]]) 23:10, 19 January 2023 (UTC) |
|||
#::What do you mean by privacy issues? I was on the Discord call today and was given to understand that the issue was related to ''caching'' - i.e., the site served to logged-out users has to be the same for everyone so that it can be cached. There's no mention of privacy on either the main [[Wikipedia:Vector 2022|Wikipedia]] page or the [[mw:Reading/Web/Desktop_Improvements|WikiMedia]] page. |
|||
#::(I note that it should be possible to have a persistent setting for at least the amount of whitespace (which seems like the main objection) implemented purely client-side, without significant effects on performance or privacy.) [[User:Bakkot|Bakkot]] ([[User talk:Bakkot|talk]]) 01:20, 20 January 2023 (UTC) |
|||
#::{{tq|1=there are privacy issues that prevent allowing IPs to choose a skin}}<br>But surely this is fixed by allowing IPs to default to Vector 2010 by choice? By cookie? In essence, opting in to be de-anonymized only insofar as which skin you use. The only argument against this that I've heard is that it uses more server juice. And I find that argument extremely weak. How much server juice will be used by more clicks, more accounts, and more protests from anons who hate this and accounts who default to the old skin? — [[User:Shibbolethink|<span style="color: black">Shibboleth</span><span style="color: maroon">ink</span>]] <sup>([[User talk:Shibbolethink|♔]]</sup> <sup>[[Special:Contributions/Shibbolethink|♕]])</sup> 18:12, 20 January 2023 (UTC) |
|||
#:::@[[User:Shibbolethink|Shibbolethink]], it's explained further below, but this require caching each page in both V22 and V10, which would be very expensive. It can't be stored as a cookie or similar to avoid a [[flash of unstyled content]].<span id="Qwerfjkl:1674252316275:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — [[User:Qwerfjkl|<span style="background:#1d9ffc; color:white; padding:5px; box-shadow:darkgray 2px 2px 2px;">Qwerfjkl</span>]][[User talk:Qwerfjkl|<span style="background:#79c0f2;color:white; padding:2px; box-shadow:darkgray 2px 2px 2px;">talk</span>]] 22:05, 20 January 2023 (UTC)</span> |
|||
#::::Now that I think about it, what's preventing the site from reading cookies first before serving pages?(Note that I"m only talking about max width mode here) [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 22:21, 20 January 2023 (UTC) |
|||
#'''Strong support''' – The new style is aesthetically bad and has far too much white space (in what appears to be an attempt to mobile-ify the desktop view); there was no proper consensus for rolling it out; and the old version was not broken and did not need replacing. [[User:CuriousCabbage|CuriousCabbage]] ([[User talk:CuriousCabbage|talk]]) 22:33, 19 January 2023 (UTC) |
|||
#::So nothing should be changed on Wikipedia ever, for all time? [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 22:49, 19 January 2023 (UTC) |
|||
#:::I say this with as much respect as I can - but do you realize how ridiculous that response is? I'll let you look through [[:Template:Fallacies]] to see where your comment falls. To help: Just because I may not like a particular new commercial for some product, doesn't mean they should stop making commercials or new products. But hey, to continue to follow your line of thought, maybe we should never have webpages; or computers; or electricity; or technology. All because some edit to some website that you like and someone else didn't was merely suggested to be reversed. - <b>[[User:Jc37|jc37]]</b> 23:02, 19 January 2023 (UTC) |
|||
#::::I find it interesting that people won't answer the question but are criticizing me for asking it. It's not a fallacy because that's what you are implying with "if it aint broke". Something doesn’t have to be broken for it to be changed. I have seen far more comments that Wikipedia looks like it was designed in the 1990s than comments it should stay the same. I am undecided on the skin, but I'm trying it out. There is no change that will please everyone. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 23:11, 19 January 2023 (UTC) |
|||
#:::::Not what I was implying at all. But to respond to someone else saying that they didn't think the style needed wholesale replacement with "So nothing should be changed on Wikipedia ever, for all time?" is very much ridiculous to the extreme. I don't believe anyone is saying that. This change is really a package of changes, and in this case, the package would appear to have issues. If I'm served a gourmet meal, but the bread has mold on it, it doesn't mean that I never want another gourmet meal. - <b>[[User:Jc37|jc37]]</b> 23:25, 19 January 2023 (UTC) |
|||
#::::::If you are saying changes should be made piecemeal, fair enough- but there is still the issue that no change will please everyone, and doing it piecemeal just draws out the process without making it better. Better to rip it off like a bandaid. The frustration I have here is those saying this was done without community input by dictators in an ivory tower- which is demonstratably false. Disagree with it all one wants, propose all the changes you want, propose ideas for better commuication, that's all great. But seeing the people who worked on this be attacked and insulted and cursed or told "they don't know as much as me with 30 years of experience" for doing their task is sad to see. I just want to see people be civil and have understanding. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 23:38, 19 January 2023 (UTC) |
|||
#:::::::Changes shouldn’t be made just for the sake of it either. Your reasoning is utterly fallacious.[[User:Tvx1|T]][[User Talk:Tvx1|v]][[Special:Contributions/Tvx1|x]]1 01:41, 20 January 2023 (UTC) |
|||
#::::::::They haven't changed it for the sake of changing it. There are reasons, if you'd care to read about them. Feel free to disagree, but this was not done without a reason. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 01:50, 20 January 2023 (UTC) |
|||
#:::::Every improvement implies a change. But not every change implies an improvement. Have in mind. [[Special:Contributions/37.134.90.176|37.134.90.176]] ([[User talk:37.134.90.176|talk]]) 08:55, 20 January 2023 (UTC) |
|||
#:::That's not what I said. But there is nothing wrong or incompatible or broken or outdated or aesthetically displeasing about the previous skin, and all this new skin changes is (i) to add more white space which makes pages harder to read; and (ii) to make the tools menu collapsible and thus more inaccessible and difficult to use. It may well be that in five, ten years time a restyle is needed to keep the pages looking fresh, or to incorporate some new technology or technical capability which becomes available. But Wikipedia at the moment still looks clean and is still easily usable. This ''specific'' re-skin only worsens things which were not broken. [[User:CuriousCabbage|CuriousCabbage]] ([[User talk:CuriousCabbage|talk]]) 00:31, 20 January 2023 (UTC) |
|||
#'''- Support''' I think this change was poorly made. I'm not against change, just not this one, it should still be worked on and a lot of things corrected. I'm French, I'm suffering this bad design for 2 (?) years now. Of all the thing I resent the WMF for is the total ignorance of negative comments, and a focus on the opinion of a carefully selected few editors. Up until V2022 landed in the French Wikipedia, I was a simple reader like any others, and I think the focus on editors is disheartening, us reader should have a voice in that too, in my point of view this has been decided behind closed doors. [[User:DerpFox|DerpFox]] ([[User talk:DerpFox|talk]]) 22:36, 19 January 2023 (UTC) |
|||
#::There is no content to read without editors. The process was an open process with years of comment and studies. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 22:53, 19 January 2023 (UTC) |
|||
#:::Yes? and? Does it make the editors more important than the readers? No, it doesn't. And now if you could please stop trying to silence any dissenting voice from official WMF official version of things, it would be nice, thank you. [[User:DerpFox|DerpFox]] ([[User talk:DerpFox|talk]]) 23:11, 19 January 2023 (UTC) |
|||
#::::I am not silencing anyone and I take offense at the suggestion. I am responding to comments in a civil manner as part of a discussion. I won't be silenced either. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 23:15, 19 January 2023 (UTC) |
|||
#'''Support''' for now. Major technical issues like mousewheel support and permanent IP settings should have been addressed prior to rollout, the "mystery meat" icons are untenable, and the language buttons are a tremendous step backwards. These issues need to be fixed behind the scenes, not live post-rollout, and this was clearly communicated to WMF in the previous RFC. [[User:VQuakr|VQuakr]] ([[User talk:VQuakr|talk]]) 23:34, 19 January 2023 (UTC) |
|||
#'''Support''' until the issues are worked out, especially the squished content. [[Wikipedia talk:Vector 2022#This was very predictable and very preventable|This was very predictable and very preventable]]. [[User:Thebiguglyalien|Thebiguglyalien]] ([[User talk:Thebiguglyalien|talk]]) 23:42, 19 January 2023 (UTC) |
|||
#'''Strong support'''. To say that the new skin is horrible is a very polite understatement, you know. Why on Earth they've even started designing this? — [[user:Mike Novikoff|Mike Novikoff]] 00:00, 20 January 2023 (UTC) |
|||
#:If you haven't already, please see [[WP:VECTOR2022]] for more information. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 00:14, 20 January 2023 (UTC) |
|||
#::It's not really interesting. The question was just rhetoric. I'm sure there's a lot of links and even shortcuts to justify the horror, but it's still one. A horror. That I've turned off ASAP. Thanks that we have a link to do so, at least. — [[user:Mike Novikoff|Mike Novikoff]] 04:49, 20 January 2023 (UTC) |
|||
#:::You know, I've just been robbed of Twinkle (for I can't support ES6), so I'm already ''laying back and thinking of England''. Now you want me to try a DP? BTW, it seems to be too much of 331dot around, please stop [[WP:BLUDGEON|bludgeoning]]. — [[user:Mike Novikoff|Mike Novikoff]] 05:27, 20 January 2023 (UTC) |
|||
#'''Support''' so long as it remains impossible for logged out users to revert persistently, which if I gather correctly seems to be the case for technical reasons. [[User:Jeremy Jeremus|Jeremy Jeremus]] ([[User talk:Jeremy Jeremus|talk]]) 00:21, 20 January 2023 (UTC) |
|||
#'''Strong support''' – Vector 2022 is an eyesore and much more difficult to navigate than Vector legacy. The skin also breaks many pages whose layout was not optimized for Vector 2022. The Web team failed to clearly communicate the change to all active users ahead of time, resulting in the flood of complaints at [[WT:VECTOR2022]] in the past two days. The fact that many editors were unaware of this change until the launch, and/or did not participate in the previous RfC, raises questions as to whether there was consensus to deploy Vector 2022 as the Web team suggests. [[User:InfiniteNexus|InfiniteNexus]] ([[User talk:InfiniteNexus|talk]]) 00:46, 20 January 2023 (UTC) |
|||
#'''Strong support''' [[User:Shinanoki|Shinanoki]] ([[User talk:Shinanoki|talk]]) 01:08, 20 January 2023 (UTC) |
|||
#'''Strong support''': I am not as active an editor as I was for a while, but I'm still known as 'the guy who edits Wikipedia' in a lot of places I hang out. The past day has been seeing just a ''massive tidal wave'' of opposition from a broad spectrum of readers acrosss...everyone I know, frankly. Absolute eruptions into "this is awful" well beyond what you get from most website layout changes. Readers who prefer desktop dislike the aesthetic of the mobile site (there's a reason you get those bots designed to remove m. from mobile links, given it's apparently beyond our capacities to do it on purpose), and they ''loathe'' a new skin that intends to copy the aesthetic of the mobile site. Opt-out stats poorly measure reader opinions on skins, because ''readers don't have accounts'' and can't be reasonably expected to make them for every context they read Wikipedia. I have not anywhere across thousands of readers from various walks of life heard a single positive word about the new skin, not even as pushback. I also retain all the many complaints I've personally had about this skin for the past two years; the language icons are terrible, the lack of genuine options in the sidebar are terrible, the image formatting is shot, the amount of whitespace is distracting, the community does not actually support the change, etc. (Every not-community-based one of these I've seen repeated vocally and angrily over the past day.)<p>If Wikipedia was a more typical website, it would be fairly trivial to solve the skin issue; we could simply add a dropdown menu for all readers to select their preferred skin. The problem is that Wikipedia cannot under its current ideological/philosophical framework do this, as the compromise would require cookie tracking to allow it to persist between sessions. This results in people who complain to info@ getting told to 'just make an account', which is not a scalable solution (and ignores the fact readers tend to be reading Wikipedia on things other than their home computers, where they still want to see their preferred layout). My ha-ha-only-serious solution is "automatically generate an account for each IP address". If this seems untenable to you, fair enough -- these changes being controversial and hard to individually reverse is precisely why it's bad to force them on literally billions of people! [[User:Vaticidalprophet|<b style="color:black">Vaticidal</b>]][[User talk:Vaticidalprophet|<b style="color:#66023C">prophet</b>]] 01:13, 20 January 2023 (UTC) |
|||
#:You have surveyed thousands of readers? I'd be interested in seeing the results of that. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 01:24, 20 January 2023 (UTC) |
|||
#::That's not how it should work. That should happen ''before'' not demanded after pushing it out... - <b>[[User:Jc37|jc37]]</b> 01:30, 20 January 2023 (UTC) |
|||
#:::The Foundation did do surveys and testing. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 01:31, 20 January 2023 (UTC) |
|||
#::::See [[mw:Reading/Web/Desktop Improvements/Repository/Sentiment Survey]] [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 01:33, 20 January 2023 (UTC) |
|||
#:::::It is interesting to see how polarized the Overall Satisfaction responses were, yet the Introduction section was written back in September anticipating Vector 2022 becoming default inevitably and irreversibly. [[User:Jeremy Jeremus|Jeremy Jeremus]] ([[User talk:Jeremy Jeremus|talk]]) 01:40, 20 January 2023 (UTC) |
|||
#:::::Their survey only polled 152 people, and of those only 24% told them "the new skin is easier to use than the old one". Not only is that nowhere ''near'' a representative sample, but they went ahead with this with just a 24% positive response? [[User:WalnutBun|WalnutBun]] ([[User talk:WalnutBun|talk]]) 01:43, 20 January 2023 (UTC) |
|||
#::::::What makes you think this discussion will be more representative? It's usually people that are dissatisfied with something that speak the loudest about it, more than people who don't have an issue. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 01:46, 20 January 2023 (UTC) |
|||
#:::::::You keep saying things like this, but when the complaint is "The process used to generate this action was bad," a response of "The next process may also be bad" is quite unconvincing. The right way to do this is with broad surveys of all types of users, not 152 people (apparently mostly editors?). [[Special:Contributions/72.49.221.183|72.49.221.183]] ([[User talk:72.49.221.183|talk]]) 04:03, 20 January 2023 (UTC) |
|||
#::::::This percentage is very large compared to the amount of people who voted that the original skin was easier. The plurality here voted neutral which is why this percentage is so small [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 04:22, 20 January 2023 (UTC) |
|||
#:::::One thing that immediately sticks out to me here is that responses with "foul language" were removed. Strong negative responses often use foul language; I am curious how many of the dropped comments were actually irrelevant and how many were "this design is fucking terrible". |
|||
#:::::{{u|OVasileva (WMF)}}, is the raw data from this available? [[User:3mi1y|<span style="display:inline-block;transform:scale(-1,1)rotate(-30deg);">ℰ</span>''mi1y'']]<sub style="color:#b766d2;">⧼[[User talk:3mi1y|T]]·[[Special:Contributions/3mi1y|C]]⧽</sub> 08:28, 20 January 2023 (UTC) |
|||
#:::I don't understand what you're saying over here. Before what? [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 01:32, 20 January 2023 (UTC) |
|||
#'''Strong support''' there was not actually consensus for rolling this out in the first place and the new skin is clearly worse than the old one. Since developers are unwilling to allow logged-out users to choose between the two skins, we should go back to the skin that people prefer and are used to. [[User:Elli|Elli]] ([[User_talk:Elli|talk]] | [[Special:Contributions/Elli|contribs]]) 01:13, 20 January 2023 (UTC) |
|||
#:It's not a matter of willingness, there are privacy issues with doing so; that information would have to be stored somewhere. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 01:18, 20 January 2023 (UTC) |
|||
#::There is absolutely no privacy issue with using a client-side cookie for a setting like that. [[User:Elli|Elli]] ([[User_talk:Elli|talk]] | [[Special:Contributions/Elli|contribs]]) 01:27, 20 January 2023 (UTC) |
|||
#:::See [[Wikipedia talk:Vector 2022#Do not force the creation of a user account]] which is where I read that claim. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 01:38, 20 January 2023 (UTC) |
|||
#::No, it has nothing to do with privacy. See {{slink|mw:Reading/Web/Desktop Improvements/Frequently asked questions|Why is the opt-out link not available for logged-out users?|Why are there no preferences for anonymous users?}}. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 01:30, 20 January 2023 (UTC) |
|||
#:I concur, this new skin primarily affects logged-out frequent readers and the least disruptive option should be default for those not logged in. [[User:Jeremy Jeremus|Jeremy Jeremus]] ([[User talk:Jeremy Jeremus|talk]]) 01:22, 20 January 2023 (UTC) |
|||
# '''Support''' at least temporarily, based primarily on the "public's" reaction. <small>I do personally prefer 2010 but personal preference isn't the point.</small> The existence of a well advertised RFC in the past does not preclude responding to negative feedback now. With that said, I hope to see the WMF/whoever to respond quickly with either changes to the skin based on feedback or a reversion while they tweak it. [[User:SpinningCeres|<b style="color:MediumBlue">Spinning</b>]][[User talk:SpinningCeres|<b style="DarkSlateGray">Ceres</b>]] 01:23, 20 January 2023 (UTC) |
|||
#'''Support'''. My biggest issue with this rollout is how it wasn't publicized at all - or, at the very least, not well. I use Wikipedia almost daily (both while logged-in and logged-out) and I can honestly say that I saw no sign of this change even being considered before it suddenly rolled out, and I'm not alone: [[Wikipedia_talk:Vector_2022]] is full of people (and at least one wiki administrator) that were also blindsided by this change. [[User:WalnutBun|WalnutBun]] ([[User talk:WalnutBun|talk]]) 01:37, 20 January 2023 (UTC) |
|||
#'''Support in the strongest possible way'''. This action is one of the worst I have seen by the WMF. A RFC was held to gauge support and was ignored completetely. The changed was forced through unilaterally and if the WMF has any remote respect for their community they roll that back asap.[[User:Tvx1|T]][[User Talk:Tvx1|v]][[Special:Contributions/Tvx1|x]]1 01:51, 20 January 2023 (UTC) |
|||
#:The RfC WASN'T ignored completely, in fact the problem was the community closers misguidedly decided that if the changes proposed by the opposing side were made then the rollout can be done without any new rfc. The foundation simply acted on this misguided closing that they trusted because it wasn't from the foundation. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 02:01, 20 January 2023 (UTC) |
|||
#::Then a closure review is warranted.[[User:Tvx1|T]][[User Talk:Tvx1|v]][[Special:Contributions/Tvx1|x]]1 02:04, 20 January 2023 (UTC) |
|||
#:::I'm newer to Wikipedia than you, is there some specialized closure review? Otherwise doesn't this rfc suffice as a closure review? [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 02:07, 20 January 2023 (UTC) |
|||
#::::RfC closure reviews are usually conducted at [[WP:AN]], but this RfC will do. [[User:InfiniteNexus|InfiniteNexus]] ([[User talk:InfiniteNexus|talk]]) 03:51, 20 January 2023 (UTC) |
|||
#:There's nothing wrong with WMF in this case, the RFC was closed too fast, which make this misunderstanding. [[User:Lemonaka|Lemonaka]] ([[User talk:Lemonaka|talk]]) 02:03, 20 January 2023 (UTC) |
|||
#::Sure the WMF are in the wrong. The closure clearly stated a follow-up RFC was warranted, WMF just ignored that and unilaterally forced the change. [[User:Tvx1|T]][[User Talk:Tvx1|v]][[Special:Contributions/Tvx1|x]]1 02:07, 20 January 2023 (UTC) |
|||
#:::That was exactly what the closure said against, '''t'''o '''q'''uote {{tq|and in our view no further RfC would be required}} [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 02:11, 20 January 2023 (UTC) |
|||
#::::BTW, even there is a consensus to change back, I believe WMF will not take that. If they really said {{quote|in our view no further RfC would be required}}, then everything is useless.@[[User:Aaron Liu|Aaron Liu]] [[User:Lemonaka|Lemonaka]] ([[User talk:Lemonaka|talk]]) 02:17, 20 January 2023 (UTC) |
|||
#:::::@[[User:Lemonaka|Lemonaka]] Again that was not from WMF, that was from two esteemed editors unrelated to WMF that closed the thing. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 02:22, 20 January 2023 (UTC) |
|||
#'''rollback to old version''' I know that nothing wrong from WMF, but previous RFC is clearly no consensus.<br>BTW, I believe if this case is getting hotter and hotter, Arbcom should be noticed. [[User:Lemonaka|Lemonaka]] ([[User talk:Lemonaka|talk]]) 01:57, 20 January 2023 (UTC) |
|||
#'''Support'''. As a casual user who's used wikipedia for over a decade myself, I've found the new UI to be aggressively frustrating. I feel like I've been forced to create an account for a website I never had to before to use regularly just to be able to revert the changes. If somehow this rollout could be performed without necessitating account creation to roll-back then It could've gone over a lot smoother with the entire community. As it stands, with no ability to revert without logging in, I find these changes as hostile towards casual users, which appears to be contrary to the entire point of the rollout of changes in the first place...<!-- Template:Unsigned IP --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/2601:600:9681:ffa0:7002:7aac:8a4b:b978|2601:600:9681:ffa0:7002:7aac:8a4b:b978]] ([[User talk:2601:600:9681:ffa0:7002:7aac:8a4b:b978#top|talk]]) 01:58, 20 January 2023 (UTC)</small> |
|||
#'''Support''' until there's an easy way to revert to the old interface without having to create an account. For example, [[Reddit]] still maintains old.reddit.com (the old interface which is imo better) alongside the (re-designed) reddit.com -[[User talk:Fastily|<span style="font-family:'Trebuchet MS';color:Indigo;font-weight:bold;"><span style="font-size:120%;">F</span><span style="font-size:90%;">ASTILY</span></span>]] 02:07, 20 January 2023 (UTC) |
|||
#:The easiest way is to use a redirector extension such as fastforward and redirect every /wiki link to https://en.wikipedia.org/w/index.php?title=Page_title_with_underscores&useskin=vector and redirect every /w link to a link with the &useskin=vector suffix. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 02:10, 20 January 2023 (UTC) |
|||
#::How disconnected and out of touch do you have to be to think that that's the "easiest" way? You're just another one {{RPA}} up in his ivory tower who thinks he knows best and that all the people who dislike the change are just backwards idiots who "don't like change." [[Special:Contributions/198.21.192.40|198.21.192.40]] ([[User talk:198.21.192.40|talk]]) 23:57, 20 January 2023 (UTC) |
|||
#'''Strongest possible support''' - mystery meat navigation, breaking things that don't need to be broken, taking control of text width away from the user, pointless whitespace, reduced information density motivated by dubious statistics in a typical runaway example of [[Goodhart's Law]] in which measures gradually gain perceived importance until the design is being made in service of the metrics instead of the metrics in service of the design... this redesign has no good features and many bad features. As an autodidact, independent research and amateur historian who views dozens of pages on here per day, and thus something of a power user despite the fact I don't edit the encyclopedia, if I didn't have the technical savvy to create an account to avoid this awful redesign I would have already started looking elsewhere for information as much as possible. [[User:IWantTheOldInterfaceBack|IWantTheOldInterfaceBack]] ([[User talk:IWantTheOldInterfaceBack|talk]]) 02:22, 20 January 2023 (UTC) |
|||
#'''Support''' until non-logged-in editors can opt out. Any website that I have to create an account ''just to read'' is '''dead to me'''. Accounts are for ''interaction''. I don't want to remember another fricking password. Now I happen to have an account here. I happen to interact here. This isn't about me, or most people who can find this page. It's about the person who just wants to read about French history or the Higgs boson, and just got this foisted on them, and is going give up on us ''forever'' as just another crappy unusable website. '''Give. Readers. A. Choice.''' This isn't impossible. If it's non-trivial then revert the change temporarily. [[User:Suffusion of Yellow|Suffusion of Yellow]] ([[User talk:Suffusion of Yellow|talk]]) 02:23, 20 January 2023 (UTC) |
|||
#'''Support''' Core issues I have with the change are the massive whitespace which serves no purpose and is an overly harsh color for high contrast monitors, the lack of persistence of core settings unlike other wikis with the limited width feature, the poor visibility of the expand button due to it's thin design and it's placement within the otherwise unutilized whitespace where it blends in, and the expanded view having less body visible than the 2010 version. Since there are warnings on the top, I had to find the original discussion on vector 22 on reddit of all places from there I found the solution was to make an account(had one, never really used), or to use third party scripts.[[User:Deadoon|Deadoon]] ([[User talk:Deadoon|talk]]) 03:08, 20 January 2023 (UTC) |
|||
#'''Support''' Viewing Wikipedia while logged out is painful because while an article used to take up 80% of my screen now it takes up about 50% or so. What a waste of screen real estate. [[User:RPI2026F1|RPI2026F1]] ([[User talk:RPI2026F1|talk]]) 03:17, 20 January 2023 (UTC) |
|||
#'''Conditional Support''' I am unable to find any of the cited papers that support the claims about whitespace being good in the FAQ for the redesign (Lin 2004 or the Wichita State lab study whose DOI number goes no where). I made an account after almost 18 years of daily use because I was displeased with the whitespace. I would be moved to change my opinion if someone could actually show the empirical studies that support having whitespace for the sake of reading comprehension without sacrificing reading speed. I can get that this is a design principle that many sites have occupied, but I do not see why Wikipedia must join in on such a trend. What is sleek today is aged tomorrow. Vector 2010 seems to me to be a timeless design. [[User:Guidethebored|Guidethebored]] ([[User talk:Guidethebored|talk]]) 03:25, 20 January 2023 (UTC) |
|||
#:I believe when I saw the WMF folks cite the sources they were saying the sources said that it slowed down reading speed in exchange for reading comprehension. I recall the WMF folks said they saw this as an acceptable tradeoff. Cost-free tradeoffs are very rare. I strongly disagree with them on this one. [[User:IWantTheOldInterfaceBack|IWantTheOldInterfaceBack]] ([[User talk:IWantTheOldInterfaceBack|talk]]) 04:22, 20 January 2023 (UTC) |
|||
#:Below, someone linked me to the two articles: [https://web.archive.org/web/20200523221337/https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.556.404&rep=rep1&type=pdf Wichita State] and [https://www.researchgate.net/publication/252707646_The_Effects_of_Line_Length_on_Children_and_Adults'_Online_Reading_Performance a different article about line length]. |
|||
#:I feel inclined now to change my '''Condition''' to '''Fully Support'''. The Wichita State study does not apply to Wikipedia; it compares no margins or margins. Wikipedia already had a margin which of course assisted in readability. The other article suggests no correlation between line length and adult reading comprehension. Its Full, Medium, and Narrow paragraphs were variably rated by the metrics of perceived ease of scrolling, concentration, and presentation, with no clear winner at all there. I personally would need to see more to be convinced. [[User:Guidethebored|Guidethebored]] ([[User talk:Guidethebored|talk]]) 15:52, 20 January 2023 (UTC) |
|||
#'''Strong support'''. A total step backwards in terms of readability. A majority in the last RfC were opposed to it and only 24 percent of those polled thought the new skin was easier to use. <span style="font-weight:bold;text-shadow:1px 1px 40px black">[[User:Tkbrett|<b><span style="color: #000000;">Tkbrett</span></b>]][[User talk:Tkbrett|<span style="color: #FF0000;"> (✉)</span>]]</span> 04:11, 20 January 2023 (UTC) |
|||
#'''Support''' – I just can't get around the fact that the October/November RfC ended with 154 support and 165 oppose and they went forward anyway. I realize 'not a vote', but I read those comments and I don't see how the closers came to those conclusions. And when I read that closure [[Wikipedia:Requests for comment/Deployment of Vector (2022)#Discussion]] I thought it at least meant some things would be fixed before roll out. Well, none of the issues ''I'' mentioned in that RfC were fixed. [[User:DB1729|<span style="font-family:Times New Roman;color:#4B0082;">'''''DB'''''</span><span style="color:DeepSkyBlue"><small>'''''1729'''''</small></span>]]<sup>[[User talk:DB1729|<span style="color:#4B0082;">'''''talk'''''</span>]]</sup> 05:05, 20 January 2023 (UTC) |
|||
#'''Support''' on desktop, the whole thing now looks like a cheap mobile site. Very difficult to navigate and unrewarding UX. [[User:Juno|Juno]] ([[User talk:Juno|talk]]) 05:10, 20 January 2023 (UTC) |
|||
#'''Strong support'''. Frequently used tools (even by the casual, no account user) are now hidden in dropdowns and menus. This not only wastes time by requiring that the user open the menu and ''then'' scroll to his selection, but makes it less likely that such features will be discovered at all. It would be one thing if the saved space were used efficiently, but instead we get trendy white space. At the very least, input should be sought from casual and non account users with page banners seeking feedback. [[User:Kilometers to Verona|Kilometers to Verona]] ([[User talk:Kilometers to Verona|talk]]) 05:26, 20 January 2023 (UTC) |
|||
#'''Support''' Employing this mobile version for everyone is just a scam for desktop readers to create accounts. [[User:Алхимик Темногорск|Алхимик Темногорск]] ([[User talk:Алхимик Темногорск|talk]]) 05:52, 20 January 2023 (UTC) |
|||
#'''Strong support'''. Thank you for opening this RFC, which has saved me the trouble either of finding a query I posed a couple of years ago after this change was imposed on some non-English WPs or of raising a new one. I have immediately reverted to Vector2010. I detest Vector2022 for two main reasons. (1) It makes switching between languages difficult and tedious. I cannot emphasise this strongly enough. I want the list displayed alphabetically on the page, not in some sort of thematic drop-down menu; so that I can immediately see whether or not there is an equivalent. This isn't an issue of simply switching between favoured languages, but of multilingual searching, which I do more than most or possibly anyone; see my UserPage. (2) I want a properly usable ToC on long pages such as [[WP:ANI]], not a difficult-to-navigate floating list. |
|||
#:I only noticed the change because I bought a new PC three days ago, and my preference was not carried over onto it. Thank you again; you have saved me a lot of frustration. |
|||
#:I am by no means against change, but am strongly in favour of easy-to-find options; and ''this isn't one''. [[User:Narky Blert|Narky Blert]] ([[User talk:Narky Blert|talk]]) 06:08, 20 January 2023 (UTC) |
|||
#'''Strong support''' The primary audience of Wikipedia is unregistered or logged-out users, who are the ones unable to change the appearance of the website. I logged in today for the sole purpose of reverting this visual change, and there is likely a spike in logged-in users since this change was implemented. Reddit has their "old.reddit.com" domain that allows logged-out users to use the older appearance, and I see no reason why Wikipedia cannot use a similar method aside from complete dissociation of the website from its community. The ability for the majority of users of Wikipedia to be able to revert the appearance should have been a ''bare minimum'' for the implementation of Vector 2022 as the default. This ''should not'' be the default appearance until Wikipedia can give unregistered site viewers a simple method of reverting the visual changes that does not constitute logging in or creating an account. [[User:GalacticRuler456|GalacticRuler456]] ([[User talk:GalacticRuler456|talk]]) 06:15, 20 January 2023 (UTC) |
|||
#'''Strong support''' There was never a consensus for Vector 2022 anyway. Vector 2022 looks god awful for readers and has worse usability for editors (frequently used links now hidden in dropdown menus). And WMF will tell us that sudden spike in new registrations (because really a lot of people hate the redesign and there is no different option to change it back) would be a success of the new skin, lol. --[[User:Icodense99|Icodense]] ([[User talk:Icodense99|talk]]) 06:34, 20 January 2023 (UTC) |
|||
#'''Support''' At lease please put the expanded, inline, contents section back. For example: https://imgur.com/a/TULEHvp. --[[User:LDF092|LDF092]] ([[User talk:LDF092|talk]]) 06:48, 20 January 2023 (UTC) |
|||
#'''Support''' I'm a random user who was sufficiently annoyed at a previous poorly implemented feature change to make an account to complain, and here I am again to yet another ill considered design choice. The design is a mistake. Clearly it is the mobile version of the site erroneously being shown to web users. Why else have tiny text in a narrow strip and vast areas of empty space on either side? Either create a proper web version of the site or revert it back. [[User:Ikaruseijin|Ikaruseijin]] ([[User talk:Ikaruseijin|talk]]) 07:22, 20 January 2023 (UTC) |
|||
#'''Support unless Question 2 is adopted''' Taking on one of the primary concerns of the original RFC as an opt in toggle is ridiculous. 'You can turn the horrific amounts of whitespace off!' should never be the response to feedback. They should be gone by default. Make a toggle that says "Research supported way to read!!!!" that reintroduces them. [[User:Parabolist|Parabolist]] ([[User talk:Parabolist|talk]]) 07:25, 20 January 2023 (UTC) |
|||
#'''Strongly support:''' I spent a couple of hours trying without success to revert to something I could navigate easily (e.g. Watchlist on the page rather through an opaque drop-down menu). But you have to understand more than I did to do so, e.g. knowing what CSS, Monobook and original Vector meant. Some of the new features are in fact welcome (for example, putting contents in the sidebar rather than below the lead), but overall, the new design is vexing, frustrating and hard to navigate. If technically possible (in an easier and less-confusing way) let editors choose what's useful or preferable for them. [[User:Shakescene|—— Shakescene]] ([[User talk:Shakescene|talk]]) 07:41, 20 January 2023 (UTC) |
|||
#:@[[User:Shakescene|Shakescene]] While it isn't clear at first glance, the watchlist is already at the top, it's represented by a button with three lines and a star to the left or the user dropdown. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 12:43, 20 January 2023 (UTC) |
|||
#::This is one of my gripes about the new version: why use icons when words will work much better. Why add some of the clear links at the top of the page into a dropdown box (I use the Sandbox a lot and I now have to go through two clicks when one used to do. If I want to go to my watchlist, I have to look at the unclear icons and try and decipher them. - [[User:SchroCat|SchroCat]] ([[User talk:SchroCat|talk]]) 14:39, 20 January 2023 (UTC) |
|||
#:::Similarly, I often use "Contributions" to continue working on articles I recently edited, and Vector 2022 places that two clicks away instead of the 2010's skin one click. ~ [[User:HAL333|<span style="background:red; color:white; padding:2px; border:1px solid red;">'''HAL'''</span>]][[User talk:HAL333|<span style="background:black; color:white; padding:2px; border:1px solid red;">'''333'''</span>]] 22:32, 20 January 2023 (UTC) |
|||
#::::Same for me. [[User:Æo|Æo]] ([[User talk:Æo|talk]]) 22:35, 20 January 2023 (UTC) |
|||
#'''Strong Support''' I'm a user who uses Wikipedia several times a day for professional, personal, and casual purposes. I usually stay logged out, as I have no reason to log in unless I would want to participate on a talk page or edit a protected page, which is a rare occasion. I have two major things to say about this. FIRSTLY: the first time I heard about this new skin was today, when it happened, but apparently discussion has been going on about this for months? This discussion obviously excluded the vast swaths (likely the vast majority?) of users like me - people who use Wikipedia constantly but don't ever log in and keep up with the community. This, to me, is evidence that whatever conversations were had were failures - how can daily users to this site have been unaware that this was in the works for months if the conversations had were adequate? SECONDLY: Why is this layout leaning so hard into a mobile-oriented layout? Doesn't the mobile site already exist for people who wanted this layout? My first reaction to this update was to assume I had wandered on the mobile site by accident. If an article has a lot of pictures (like most articles about topics that are even sort of noteworthy), you can barely read a full sentence that isn't split in half by a line break. The last few minor things I have to say: 1) At least the custom-preference option gives me a reason to stay logged in now. 2) I will not, in the future, be donating to the WMF whenever they ask if decisions like this are going to be made with no meaningful (once again, I'm on this site every day and had no clue about this) notice or feedback beforehand. 3) Even Monospace is a better skin than this new one. To conclude, please just revert the default skin back to Vector 2010. People who actually wanted this new one can change their own preferences to reflect it. [[User:Teddybearearth|Teddybearearth]] ([[User talk:Teddybearearth|talk]]) 07:46, 20 January 2023 (UTC) |
|||
#'''Support''' Regardless of the merits of the skin itself, this was forced through with an extremely shaky interpretation of consensus, and should be reverted until there is actual consensus. [[User:3mi1y|<span style="display:inline-block;transform:scale(-1,1)rotate(-30deg);">ℰ</span>''mi1y'']]<sub style="color:#b766d2;">⧼[[User talk:3mi1y|T]]·[[Special:Contributions/3mi1y|C]]⧽</sub> 08:56, 20 January 2023 (UTC) |
|||
#'''Support''' for all the support reasons given above, because opposes and badgering like "the devs know better" are not convincing (certainly considering the track record of the WMF devs), and because the new design is a poorer, unintuitive experience, with issues like rarely used options prominently displayed (in text mode even, not as an icon) hile much more common tools are hidden behind obscure icons; all the issues with the "language" dropdown (too many to enumerate here); and the basi, extremely poor design choice to have an extra band of menu items between the article title and the body of the article, creating a "top menu - underlined title - underlined second menu - text" order which makes absolutely no sense. [[User:Fram|Fram]] ([[User talk:Fram|talk]]) 09:19, 20 January 2023 (UTC) |
|||
#:Personally I think moving the second menu below the article title makes sense. It's the article container. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 12:51, 20 January 2023 (UTC) |
|||
#::It's mixing contents and menus in an unnecessary and distracting way (I have just switched back to Vector22 to check my reply, and it is even worse than I remembered, with a menu on top, one on the same line ("languages"), ''and'' one below the title! I also again checked the "languages" dropdown, and oh boy, what a total mess (test on [[Prix-lès-Mézières]]). "Worldwide", I get Spanish, Portuguese, and French. Then a subsection "America", where I get the same languages, plus things like "Veneto" (in America?). Then a subsection "Europe", which suddenly goes in two colums, with a gap in the left side column for no discernible reason. In the section "Africa", French is missing. And so on... testing on [[Barack Obama]]: the "Worldwide" subheader means that instead of a neutral, alphabetical order, you now get an order decided on by some developer (I know, they know better, we should shut up) which means that very small constructed languages come near the top (in the "Worldwide" section), while major languages like Japanese are near the bottom. On articlees with few languages, like [[Miguel Escalona (Chilean footballer)]], you get a shortened search in the languages, with the text "search for a". Yep, clearly tested, works as expected. [[User:Fram|Fram]] ([[User talk:Fram|talk]]) 13:32, 20 January 2023 (UTC) |
|||
#:::I still don't see how it's distracting, it's alright for me. I don't get the shortened "search for a" bug and I like to idea of it but WTF is this sorting? [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 13:39, 20 January 2023 (UTC) |
|||
#::::Good for you if 4 instead of 2 places to find menu items isn't distracting, nor the "underline the title, then underline the menu below it as well", nor the "hey, we have text menu items, and icon menu items, but we didn't have a text + icon yet, let's use that for "languages"!" anomaly. The infallible developers seem to have mistaken the old "tab" design of the "article / talk / ..." menu line for aun underlined one, and when putting it below the title, have somewhat recreated that look which no longer has any meaning here, and only distracts (the old menu had "article" and "read" in white as active "tabs", and things like "talk" and "edit" in gray as inactive tabs: the new vector tries to achieves this by bolder underlining vs. less bold underlining, which just looks amateuristic. The more I use it, the more I see small issues indicating that this product isn't finished at all; e.g. in the old design, if I open Twinkle (the "TW" drop down) and then "More" (the "Move" dropdown), these stand next to each other: in the new layout, the Twinkle one partially obscures the Move one. Another issue: in preview, you get no TOC??? That's seriously annoying. [[User:Fram|Fram]] ([[User talk:Fram|talk]]) 14:41, 20 January 2023 (UTC) |
|||
#'''Support''' The way the change was approved in the first place looks dubious to me. This was a big enough change to justify posting to everyone's talk page asking for an opinion. But it was hidden away on some noticeboard, frequented by some, but not enough to justify the change. Even then, there were many in opposition, with a suspicious concensus. Wikipedia may not be a democracy, but it is a community project and the community was not sufficiently consulted on the change- simply because most people weren't aware. [[User:JohnmgKing|JohnmgKing]] ([[User talk:JohnmgKing|talk]]) 09:36, 20 January 2023 (UTC) |
|||
#'''Strong Support'''. I did not create this account to change Wikipedia's skin back to the good one from this horrid pseudo-mobile "New Reddit" one - if you'd make me do that, you clearly don't want me here, so I'm not even going to bother - I created this account to let you know that this entire debacle demonstrates that you have great contempt for your users, laundered through hokey pseudo-science of the worst sort, and if you're really going to force this nonsense on everyone, ruining what remains of the good that people have created through this institution - something legendary in the whole history of humanity, like a modern day Library of Alexandria, as a particularly shining subset of the internet as a whole - then you are all deep, deep in an unrecoverable stage of collapse. I dearly hope you reconsider. Make me feel like a curious young researcher gathering information on all the most fascinating topics in the world, not like a bored dying man with dementia in a nursing home reading insultingly ugly large print magazines about nothing. Good night. [[User:Your Design Is Bad|Your Design Is Bad]] ([[User talk:Your Design Is Bad|talk]]) 09:49, 20 January 2023 (UTC) |
|||
#:Moved this comment up from the [[Wikipedia:Village_pump_(proposals)#Vector 2022 Post-Deployment Update from WMF Team]] section. --[[User:Kizor|Kiz]][[Special:Contributions/Kizor|<span style="color:black;">o</span>]][[User_talk:Kizor|<span style="color:green;">r</span>]] 10:14, 20 January 2023 (UTC) |
|||
#'''Support''' reversion. The many responses I see, from editors and readers, range from "What happened?" to "Please revert" to the unprintable. I see very little praise for the change. Many developers have obviously worked long and hard on Vector 2022, and I thank them for producing an alternative skin which some people will prefer. However, it is very far from being the popular choice and should not be the default. [[User:Certes|Certes]] ([[User talk:Certes|talk]]) 10:43, 20 January 2023 (UTC) |
|||
#'''Strong support''' The new layout is a complete joke. Extremely bad, utterly useless. If you do not bring back the old layout, wikipedia is going down for sure. I will stop contributing and using wikipedia from now onwards if the old layout is not brought back.[[Special:Contributions/130.88.16.130|130.88.16.130]] ([[User talk:130.88.16.130|talk]]) 10:42, 20 January 2023 (UTC) |
|||
#'''Support in the strongest possible way'''. I do not like a bit of the new skin. I do think vast majority of users and editors feel the same as I. I edit both with and without login. How do I permanently go back to the old skin without login? I am simply unable and uncomfortable to edit in the new skin.[[User:Sunlitsky|Sunlitsky]] ([[User talk:Sunlitsky|talk]]) 10:56, 20 January 2023 (UTC) |
|||
#'''Support'''. Not even sure if my IP status allows me to comment, but the new requirement for needing JavaScript to view the Table of Contents is bad. For safety and security I don't have JavaScript enabled on any site, so I can't currently see any ToC, nor can I widen the view with the box icon. Thus diminishing the utility of Wikipedia. Plus having useful links hidden behind unnamed icons that require extra clicks just to see what is there is annoying and time wasting. [[Special:Contributions/113.211.110.53|113.211.110.53]] ([[User talk:113.211.110.53|talk]]) 11:17, 20 January 2023 (UTC) |
|||
#'''Support''' The new version has too many problems, especially with regards to inflexibly-wasted screen space. Cosmetic and usability changes are fine, but this one is measurably less useful in many ways than the existing skin. --[[User:Jayron32|<span style="color:#009">Jayron</span>]][[User talk:Jayron32|<b style="color:#090">''32''</b>]] 12:04, 20 January 2023 (UTC) |
|||
#'''Strong support'''. I reverted to Vector 2010 immediately. The old Vector provides for much easier work regarding languages (without having to open a menu to see whether a language version is available), has much less whitespace, and is supported by the developed tools. In addition, I find the mixing of various grays on the same page (sidebar vs the article) a poor design choice. Vector 2022 can remain available to opt in, but it is definitely less usable and less aesthetic than the legacy skin. The only thing that I like about the new skin is the availability of the TOC when scrolling. It is sad that the Foundation has unilaterally imposed its decision on the community without a proper consensus but has not supported it where it really matters (for example regarding tech for Commons). If there is a demise of Wikipedia, it will stem from the ever-increasing gap between the Foundation and the community. --[[User:TadejM|TadejM]] <sup>[[User talk:TadejM|my talk]]</sup> 12:14, 20 January 2023 (UTC) |
|||
#'''Support''' As I said in the previous RfC on the matter, Vector 2022 has far too much whitespace and no clear reason for it, particularly when viewing the skin on a large desktop monitor. The toggle to enlarge the page to fill the width of the screen is entirely too small and virtually impossible to notice until you are told that it's there (I know because I tested this, and spent several minutes looking for it). Hiding the languages menu behind an English language dropdown is also of little help to users. In general, there is too much hidden behind icons that, while they may be plainly conspicuous on a mobile display, need to be hunted down on a normal wide display computer screen. Vector 2022, in my humble opinion, should be recalled (at least for desktop users), at least until the Foundation figures out a way to make it possible for unregistered users to select their preferences and have those preferences persist across sessions. The majority of unregisted users do not want to create accounts simply to change how Wikipedia looks; if they wanted an account, they wouldn't be unregistered users. If we want new people to create accounts, it should be done via improving Wikipedia (in all the many ways we might do that), not by telling people to register in order to fix what they perceive as a failure to improve Wikipedia. {{Pinging|HumanBodyPiloter5}}. [[User:BlankpopsiclesilviaASHs4|'''<small style="font-size:80%;">silvia</small>''' '''<small style="font-size:65%;">(BlankpopsiclesilviaASHs4)</small>''']] '''''<small style="font-size:75%;">([[User talk:BlankpopsiclesilviaASHs4|inquire within]])</small>''''' 12:19, 20 January 2023 (UTC) |
|||
#'''Support'''. The new design is worse just because of the major waste of screen space. [[User:Endianer|Endianer]] ([[User talk:Endianer|talk]]) 12:27, 20 January 2023 (UTC) |
|||
#'''Support''' on behalf of all the people who don't edit here who have expressed their loathing of it. [[User:XOR'easter|XOR'easter]] ([[User talk:XOR'easter|talk]]) 13:29, 20 January 2023 (UTC) |
|||
#'''Strong support'''. What a waist of space on the screen. If you want to change to a different language only 10 out of 100 are shown. For the other languages you have to scroll inside a tiny mini window. --[[User:Boehm|Boehm]] ([[User talk:Boehm|talk]]) 13:37, 20 January 2023 (UTC) |
|||
#:Note: After switching languages a few time it will recommend you the languages you like and there is a search bar. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 13:40, 20 January 2023 (UTC) |
|||
#:: No, nothing will be recommended, because I usually clear cookies after closing the browser. And by the way, I do not have a prefferd language. I just want to select myself. Everything was fine before the change. --[[User:Boehm|Boehm]] ([[User talk:Boehm|talk]]) 14:22, 20 January 2023 (UTC) |
|||
#'''Strong support''': There has been a strong negative backlash against Vector 2022 from both registered and unregistered users (e.g. [[Wikipedia talk:Vector 2022|here]] and [https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1134763003#Vector_2022_deployment_update here]). The new interface has many problems: the width, the lateral TOC, the general impression that it is designed for mobile, amongst many others. Ultimately, the community does not seem to like and approve the new interface.--[[User:Æo|Æo]] ([[User talk:Æo|talk]]) 14:19, 20 January 2023 (UTC) |
|||
#'''Support''': This shouldn't have been pushed out as the default skin for unregistered readers without the accessibility issues being properly addressed. [[User:Hey man im josh|Hey man im josh]] ([[User talk:Hey man im josh|talk]]) 14:20, 20 January 2023 (UTC) |
|||
#'''Strong support''' - Every single response I've seen to this change from unregistered non-editors has been overwhelmingly negative, which throws any of the suggestions that this was a change for the sake of readers and that the editors participating in the discussion were a biased sample out of the window. [[User:HumanBodyPiloter5|HumanBodyPiloter5]] ([[User talk:HumanBodyPiloter5|talk]]) 14:23, 20 January 2023 (UTC) |
|||
#:For everything, comments will be biased towards negative, since if a reader looks and thinks there is no problem or there’s an improvement they won’t bother leaving a comment unless it’s exceptionally good. There were also reader surveys that indicated more readers liked the new skin. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 14:43, 20 January 2023 (UTC) |
|||
#'''support''' – I find the new version interesting but ultimately inferior. – '''[[User:Zmbro|zmbro]]''' <sub>([[User talk:Zmbro|talk]]) ([[Special:Contributions/Zmbro|cont]])</sub> 14:41, 20 January 2023 (UTC) |
|||
#:Or at least make an .old.wikipedia handle with the old skin (it is not perfect either, but much better than this mobile device oriented, hard to read, wasteful, eyeburning white design for a desktop users), this push of new skin onto users looks realy forced and not needed. [[User:IJustCreatedAccountBecauseOfThis1diocy|IJustCreatedAccountBecauseOfThis1diocy]] ([[User talk:IJustCreatedAccountBecauseOfThis1diocy|talk]]) 14:02, 20 January 2023 (UTC) |
|||
#:As said in the [[Wikipedia talk:Vector 2022/FAQ|FAQ]] this is very hard for the resources. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 14:50, 20 January 2023 (UTC) |
|||
#'''Support while question #2 not being addressed'''. As an IP reader and editor, aside create an account or programming tweaks, the only way I've found to use the old good UI is to append «'''?useskin=vector'''» to every requested URL. [[Special:Contributions/37.134.90.176|37.134.90.176]] ([[User talk:37.134.90.176|talk]]) 15:01, 20 January 2023 (UTC) |
|||
#'''Support''' the old 2010 skin as the default. At minimum there needs to be a way to one-click revert (session lasting) to the 2010 skin, and this needs to be available to all users. Not just logged in users. Most users never log in. Wikipedia is dramatically degraded on desktop browsers currently. This really does need to be fixed. [[Special:Contributions/2600:1700:1471:2550:4102:7C99:2804:8FC3|2600:1700:1471:2550:4102:7C99:2804:8FC3]] ([[User talk:2600:1700:1471:2550:4102:7C99:2804:8FC3|talk]]) 15:19, 20 January 2023 (UTC) |
|||
#'''Support''' - The new skin, Vector2022, inferior to Vector2010. The new version may be better for readers, but it is awful for those of us who edit regularly. My tools which were previously visible above the page content are buried now in drop down menus with silly icons that don't make sense to me, I am wasting time looking for things that are now in illogical places. The left hand side bar is definitely NOT an improvement, it's just bad design, and those tools have also disappeared, replaced in some instances with the TOC. The TOC should remain in the article content. I tried it out several times before the offical roll out, and have been testing it since it became the default, and I am convinced that the new skin is NOT an improvement. Vector2010 was not broken, so why "fix" it? Please restore Vector 2010 as the default skin, and call it something else. [[User:Netherzone|Netherzone]] ([[User talk:Netherzone|talk]]) 15:46, 20 January 2023 (UTC) |
|||
#'''Support''', I guess... but nothing stopped WMF from deploying the skin regardless of the previous RfC. So I don't expect anything else than this one being chucked away with the usual "resistance to change" argument. At this point I oppose the misguided design goals more than anything else. — <small> [[user:Hellknowz|<span style="color: #B00;">HELL</span>KNOWZ]] <b>∣</b> [[User talk:Hellknowz|TALK]]</small> 16:07, 20 January 2023 (UTC) |
|||
#:Again, WMF deployed it according to the misguided closing consensus of the rfc, not against it [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 16:20, 20 January 2023 (UTC) |
|||
#::I didn't say anything about deploying ''according to'' or ''against'' RfC. I specifically said "regardless of .. RfC". — <small> [[user:Hellknowz|<span style="color: #B00;">HELL</span>KNOWZ]] <b>∣</b> [[User talk:Hellknowz|TALK]]</small> 17:03, 20 January 2023 (UTC) |
|||
#:::I am confused, doesn’t regardless of… mean they ignored it? [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 17:06, 20 January 2023 (UTC) |
|||
#'''Support''' in principle, even though it will never happen. The real solution is to create extensions for Scalar that will restore the core fratures of Vector.[[User:SmallJarsWithGreenLabels|small jars]] <small><code>[[User talk:SmallJarsWithGreenLabels|<b style="color:#270">t</b>]][[special:contributions/SmallJarsWithGreenLabels|<b style="color:#270">c</b>]]</code></small> 16:17, 20 January 2023 (UTC) |
|||
# '''Support'''. Tastes do differ, I personally dislike the new layout although believe there are many who accept it. But the way the changes are enforced is plainly insulting. For a long-time editor like me this has been immensely frustrating and I imagine how it feels for unregistered users. The changes must be rolled back. The communication did not happen. The visible and clear notification (not a banner) must be placed in the header, on the main page, everywhere, with an explanation: what is going to happen and what to do. The toggle to switch on or off must be accessible for every user. No dark patterns. A simple form must be proposed to all users: Do you prefer this one or that one. No bad-faith interpretation of metrics. The way it was done it is humiliating. — [[User:2dk|2dk]] ([[User talk:2dk|talk]]) 16:19, 20 January 2023 (UTC) |
|||
#'''Support''' - WMF has fundamentally failed to to bring the community on board with this change. The skin has many well discussed issues: limiting width of content area is absolute nonsense, hiding tools and buttons behind additional clicks makes the experience worse, hiding optout in preferences and then claiming that the optout rate is not high is deceptive, the TOC is worse than before, there are notable bugs, to name just a few. This is all compounded by the fact that logged-out users are not left with any means of using the old skin, and that the width button is non-persistent for logged in users. |
|||
#:Further to this, WMF has show that it has no interest in consensus building or engaging with the community, as is very evident by the fact that when they had an RFC go against them, they ignored it, and decided that no further RFC is necessary since it obviously would not result in the correct answer. |
|||
#:This design is the very definition of form over function. The rollout could have been done much better, by progressively rolling the theme to more and more users and carefully listening to the feedback and monitoring the optout rates. Given that this is a product by paid designers working full time for years, it shouldn't have resulted in such poor reception. WMF should revert this change and try again later when their design is approved of by the community. [[User talk:Melmann|<strong><span style="font-family:Segoe UI Semilight ; background-color: #ffd166; padding: 1px;"><span style="color: #ef476f;">Mel</span><span style="color: #8c8757;">ma</span><span style="color: #118ab2;">nn</span></span></strong>]] 16:23, 20 January 2023 (UTC) |
|||
#'''Support''' - It has been said that this skin is better for readers, however the needs of readers depend on the device and its screen. It is obvious that the skin is something of a port of the mobile interface to a desktop one, an unfortunate but increasingly common trend in today's user-facing interfaces. This is a disservice to desktop users. The driver is not usability, rational design or aesthetics but unified software development, an efficiency (cost-cutting) prerogative. The underlying thinking is that most users read most output on mobile/small/haptic-optimized screens, and they are not going to be bothered much by the change to desktop interfaces. This may not be the case with Wikipedia articles which may be longer and more complex with added media that can be visually and logically better accessed with a larger screen, so that one gets the full impact of the article rather than constantly scrolling (apparent) fragments. This new mobile-to-desktop trend is also ill-suited to interactive sites with anything more than very simple user input. For highly interactive, user-input-intensive functions such as writing prose, adding media, logically arranging an article etc. it is supremely unsuitable. Not all change is good, or even neutral, and one person's progress may be another person's regression. [[Special:Contributions/208.253.152.74|208.253.152.74]] ([[User talk:208.253.152.74|talk]]) 16:51, 20 January 2023 (UTC) |
|||
#:The new skin was not designed with mobile in mind, see the FAQ [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 16:56, 20 January 2023 (UTC) |
|||
#::Ok. But this RfC is an example of my previous comment. Anyone who can follow this discussion on a 6-inch screen with the same comfort and comprehension as in a 26-inch screen is a better person than I am. [[Special:Contributions/208.253.152.74|208.253.152.74]] ([[User talk:208.253.152.74|talk]]) 18:29, 20 January 2023 (UTC) |
|||
#::That's a blatant lie, and they know it. This entire new skin was designed with two things in mind: ad space and mobile users. [[Special:Contributions/198.21.192.40|198.21.192.40]] ([[User talk:198.21.192.40|talk]]) 23:47, 20 January 2023 (UTC) |
|||
#'''Strongest possible support''' - What actual advantages does this skin provide that cannot be implemented in a hybrid of Vector 2010? Color blind friendly purple clicked links? TOC on the left sidebar? Images in search? These things are absolutely possible to put into Vector 2010 (and I have the first two via plugins already). A restricted reading width could be a toggled option in such a hybrid. I'm not interested in throwing out the baby with the bathwater, but I see zero reason to keep Vector 2022 as default to maintain these ''marginal'' improvements for our end reader at the expense of many extremely plausible downsides. I would also echo Red-tailed Hawk's A/B testing proposal as actual ''evidence'' rather than the supposition that has been provided to us. — [[User:Shibbolethink|<span style="color: black">Shibboleth</span><span style="color: maroon">ink</span>]] <sup>([[User talk:Shibbolethink|♔]]</sup> <sup>[[Special:Contributions/Shibbolethink|♕]])</sup> 17:57, 20 January 2023 (UTC) |
|||
#'''Support''' I don't hate Vector 2022, though I do like it less than 2010. I do, though, think it's borderline unacceptable that you have to log in to change between styles. I think that, for as big a change as this is, broader and firmer support should've been built up before WMF pushed the change. I think that trying to enact the change on the basis of very shaky results solicited from ~300 active editors is bordering on the negligent- readers have as much of a stake in Wikipedia's usability as do editors- maybe more, as they're likely to be less experienced at using and navigating the site- and that's a tiny fraction of editors, anyway. For myself, I saw or heard nothing of the coming change that I can recall, and I use Wikipedia every day, and I see multiple comments above to the same effect. I guess that getting a good indication of reader preferences might be hard, but Vector 2022 should not be mandatory or default without a clear mandate from Wikipedia users as a whole. [[User:Yspaddadenpenkawr|Yspaddadenpenkawr]] ([[User talk:Yspaddadenpenkawr|talk]]) 18:44, 20 January 2023 (UTC) |
|||
#'''Support''' While not against a redesign in general, the crazy amount of white space is distracting every-time it loads I think I'm on the mobile version. [[User:chiffre01|chiffre01]] ([[User talk:chiffre01|talk]]) 15:30, 20 January 2023 (UTC) |
|||
#'''Support''' The previous RFC did not establish community consensus to change the default style. Yet another example of the WMF pretending to care about volunteer concerns, but ultimately doing what they had intended from the start regardless. [[User:MrsSnoozyTurtle|''MrsSnoozyTurtle'']] 21:23, 20 January 2023 (UTC) |
|||
#'''Support''' I have had an account for going on 15 years, rarely edit anymore but I was so abhorred by the design change I had to make my voice heard, please change it back. --[[User:Flappychappy|Flappychappy]] ([[User talk:Flappychappy|talk]]) 21:50, 20 January 2023 (UTC) |
|||
#'''Support''' I appreciate the people who did their best and put in effort into doing what they felt would improve reading and editing for everyone on Wikipedia, but it is clear that the design was not truly approved of beforehand by the majority of users. This coupled with the issues that have arrisen makes me feel that going back to the 2010 version as standard is for the best.[[User:StarTrekker|★Trekker]] ([[User talk:StarTrekker|talk]]) 21:57, 20 January 2023 (UTC) |
|||
#'''Support''' My main concern is for text width, but more broadly it seems based on what I have read so far is that a consensus does not appear to have been reached prior to implementation, which ought to be done first. [[User:Nl4real|Nl4real]] ([[User talk:Nl4real|talk]]) 22:08, 20 January 2023 (UTC) <small>— [[User:Nl4real|Nl4real]] ([[User talk:Nl4real|talk]] • [[Special:Contributions/Nl4real|contribs]]) has made [[Wikipedia:Single-purpose account|few or no other edits]] outside this topic. The preceding [[Wikipedia:Signatures|unsigned]] comment was added at 22:08, 20 January 2023 (UTC) (UTC).</small> [[User:MarnetteD|MarnetteD]]|[[User talk:MarnetteD|Talk]] 22:18, 20 January 2023 (UTC) |
|||
#'''Support per nom'''. I never even heard of the new skin before it suddenly showed up with the horrible whitespace and janky layout. A change this huge, and this controversial, should have had an actual consensus before being forced on all readers. --[[User:HappyWithWhatYouHaveToBeHappyWith|HappyWith]] ([[User talk:HappyWithWhatYouHaveToBeHappyWith|talk]]) 22:32, 20 January 2023 (UTC) |
|||
#'''Strong support:''' At least as long as logged-out users have to use this as the default layout, I am against it. Requiring the creation of an account just to use the arguably better skin is no different than what Fandom/Wikia does. I have no problem with it being an ''option'', just not the ''default''. [[User:GangplankGalleon|gangplank galleon]] ([[User talk:GangplankGalleon|talk]]) 23:10, 20 January 2023 (UTC) |
|||
#'''Support''' I've thought over this for awhile now, and I land in the Support column for a variety of reasons. First, in my view the original RFC didn't have a consensus to implement Vector 2022 and the closing statement of the RFC has always kinda baffled me, but that's neither here nor there at this point. Second, I love the width toggle, but the fact that it doesn't persist should've been fixed before the rollout took place. Third, I really feel like the Page Tools and customizable user menu should've been in the skin before the rollout took place too. I think that would've at least calmed down the whitespace complaints somewhat. Also won't belabor the point since it's apparently going to be easier to develop one with Vector 2022, but having a dark mode would've helped this complaint too. Fourth, I will take the WMF's word that Vector 2022 wasn't designed for mobile, but it does have some of the hallmarks of moble web design (text in the middle, hamburger button, etc). I know it's only two people, but here's two of my friends reactions to seeing Vector 2022 for the first time (warning: language): https://cdn.discordapp.com/attachments/499649691714060299/1066137406576787506/image.png. I don't know how the developers of Vector 2022 could make it look less mobile-y, but there you go. Fifth, the mystery meat navigation issue that was brought up in the original RFC and again here hasn't been fixed. Finally, I feel like Vector 2022 is still not ready for primetime. It feels like a version 0.7 or 0.8 in that it's getting there, but is not fully ready. These are my thoughts anyway. <span>♠[[User:JCW555|<span style="color:purple">JCW555</span>]] [[User talk:JCW555|<span style="color: black">(talk)</span>]]</span>♠ 23:39, 20 January 2023 (UTC) |
|||
#Strong support on returning to Vector 2010. I think that my main gripe is the TOC. I understand that there's configuration option however the default view is pretty bad and I think increases the number of clicks to get to the information I want. For example on a page with a lot of sub categories, I often find it useful to scan the ENTIRE list to jump directly to the section I'm interested in. Now, again unless customizes, things are collapsed by default AND formatted in a way that makes it difficult to read long titles. So if I'm not logged in, or for any of the HUGE amount of ip only users and editors, it's now multiple clicks to get to relevant information. In the past this was literally the one click to open the page, and the one click on the section desired. Now we're up to potentially 4/5 clicks ''after getting to the page'' for what just last week was a single click action.{{pb}}I'm also going to put in here similar text from my post on the Talk page on Reading/Web/Desktop Improvements:{{pb}}Now that this change has launched why not put this up to ALL users? Put a banner on the top of articles similar to the donation banner and see how desktop users actually respond. If the attitude of "we know change is scary, you'll get used to it, we've done research!" shown in [[Wikipedia:Interface changes|this condescending article]] must be forced I'm sure a developer would love to make sure that banner shows up only on devices that have had the new layout for "long enough". You could even randomize that, see what a user thinks on day 3 vs day 15.{{pb}}If the Wikimedia foundation actually cares about user feedback I don't see why this can't be done. I think it's fairly obvious that a tiny fraction of Wikipedia users actually create an account and basing this change on what has amounted to ~170 users feedback is disingenuous. Show us you care, show us you want to see your research actually validated, it might be, but it's also ok to get it wrong too. I understand the value in continually looking forward and not settling where we are, but if you're going to use "research" as your backing, see if the hypothesis is correct. [[User:Zdwagz|Zdwagz]] ([[User talk:Zdwagz|talk]]) 23:27, 20 January 2023 (UTC) |
|||
#:This is the opinion of a brand new user. Its their first edit. Its great not to have to scroll all the way up of a long article or talk page but just be able to scroll quickly through the sections in the sidebar. [[User:Paradise Chronicle|Paradise Chronicle]] ([[User talk:Paradise Chronicle|talk]]) 00:29, 21 January 2023 (UTC) |
|||
#YES Definitely return to the vector skin! [[Special:Contributions/2601:644:401:39D0:79D9:58C3:3B6D:651E|2601:644:401:39D0:79D9:58C3:3B6D:651E]] ([[User talk:2601:644:401:39D0:79D9:58C3:3B6D:651E|talk]]) 00:33, 21 January 2023 (UTC) |
|||
==== Oppose ==== |
|||
#'''Oppose''' as too soon but also as I find the new skin a substantial improvement over the legacy skin. I don't think the {{tq|ivory tower}} comment above is representative of the rollout process. I endorse [[User:331dot|331dot]]'s comment as well. <span style="color:green">[[User:ThadeusOfNazereth|ThadeusOfNazereth]](he/him)<sup>[[User talk:ThadeusOfNazereth|Talk to Me!]]</sup></span> 21:09, 19 January 2023 (UTC) |
|||
#'''Oppose''' Although there are some tweaks I would like to see (better line/color use for separation of the UI sections and less whitespace between the TOC and the article) reverting the whole thing is not a solution. If that is our first instinct, there will never be progress. Besides, the proven benefits of shorter lines and the convenience of the sticky TOC are categorically better for most readers out there. [[User:Toadspike|<span style="font-family:'Rubik', sans-serif; color:#21a81e; text-shadow:#999b9e 0.2em 0.2em 0.4em;">'''Toadspike'''</span>]] ([[User talk:Toadspike|talk]]) 21:47, 19 January 2023 (UTC) |
|||
#'''Oppose''' - Any decision about this, now or in the future, should be based on a rigorous ''reader'' survey, not an insider straw poll. The pool of people who will fathomably even see this page is a tiny fraction of the number of people who this would affect. Contrary to some claims here and elsewhere, this wasn't some bombshell dropped out of nowhere with no community input; it seems like I've seen several attempts to draw my attention to various feedback processes. Those of us who will actually see this are also the ones who can most easily ''just change it in our preferences''. PS: [[WP:ONUS]], part of our policy on verifying claims in our encyclopedia articles, has nothing to do with this. Live with it a while, provide feedback about any issues or areas that can be improved, and lobby for a good reader survey about it in, say, 6 months (if one isn't planned already). <small>PS: Monobook4everzzz</small> — <samp>[[User:Rhododendrites|<span style="font-size:90%;letter-spacing:1px;text-shadow:0px -1px 0px Indigo;">Rhododendrites</span>]] <sup style="font-size:80%;">[[User_talk:Rhododendrites|talk]]</sup></samp> \\ 21:50, 19 January 2023 (UTC) |
|||
#:<small>I've been trying out Monobook just to see what all the fuss was about, but I really don't think I can live without the sidebar ToC anymore. V22 4 lyfe!! [[User:Shells-shells|Shells-shells]] ([[User talk:Shells-shells|talk]]) 22:00, 19 January 2023 (UTC)</small> |
|||
#:I agree, but the issue is that this should have been done ''before'' the rollout - not after. [[User:WalnutBun|WalnutBun]] ([[User talk:WalnutBun|talk]]) 01:52, 20 January 2023 (UTC) |
|||
#:[[mw:Reading/Web/Desktop Improvements/Repository/Sentiment Survey]] [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 01:59, 20 January 2023 (UTC) |
|||
#:I agree with every word of this. (except the post scriptum). Also, an RFC on a somewhat obscure page like this one, can't possibly override consensus formed on a highly-prominent page, which was advertised in a prominent watchlist notice. [[User:DFlhb|DFlhb]] ([[User talk:DFlhb|talk]]) 09:09, 20 January 2023 (UTC) |
|||
#'''Oppose''' - As I supported the original RfC to add V22, I clearly don't want legacy back as the default. But beyond that, this is a waste of everyones time because the switch has been flipped, the press release has been sent and no RfC anywhere with less than 100% support will get this switch unflipped. A dark mode is more likley to be released tomorrow than this becoming a reality... [[User:Terasail|<span style="color:#088; font-weight:800;">Terasail</span>]][[User talk:Terasail|<sup><span style="color:#000;">'''[✉️]'''</span></sup>]] 21:56, 19 January 2023 (UTC) |
|||
#:: (ec) - And here I thought [[Wikipedia:Fait accompli|Fait accompli]] was frowned upon on Wikipedia. - <b>[[User:Jc37|jc37]]</b> 22:04, 19 January 2023 (UTC) |
|||
#:::Realistically this change was coming if the original RfC had 0% support. It just happens I like the change, but some people just need to accept some changes sometimes. ''I was watching clips from BBC Archive and people had similar "outrage" over indoor smoking bans and seatbelt enforcement (People don't like change even if it is good for them).'' This change isn't a deep issue at the end of the day but you would think that the world is ending if you were reading VPT and some other threads.. [[User:Terasail|<span style="color:#088; font-weight:800;">Terasail</span>]][[User talk:Terasail|<sup><span style="color:#000;">'''[✉️]'''</span></sup>]] 22:08, 19 January 2023 (UTC) |
|||
#::::''"Realistically this change was coming if the original RfC had 0% support."'' - and therein lies a major problem. You tell me, anytime the WMF has pushed something through without '''''actual''''' community consensus and buy-in - how has that turned out? |
|||
#::::That aside, I agree with you - I expect this to be fait accompli, and we're all just going to be like [[Kermit the frog]] waving our arms helplessly in the air. But sitting quiet and saying nothing would be wrong. - <b>[[User:Jc37|jc37]]</b> 22:23, 19 January 2023 (UTC) |
|||
#:Don't get me wrong, if there is data provided a few months from now that the new skin is worse (Unlikley considering these results would have probably appeared from other wikis with it as the default for ~2 years) then I think the change should be made back to legacy vector but the day after the change just isn't the time. [[User:Terasail|<span style="color:#088; font-weight:800;">Terasail</span>]][[User talk:Terasail|<sup><span style="color:#000;">'''[✉️]'''</span></sup>]] 22:01, 19 January 2023 (UTC) |
|||
#'''Oppose'''. The new design is fine, you'll get used to it. People complain about every website redesign no matter how well thought out it is. – [[user talk:Anne drew Andrew and Drew|<span style="color:#074">Anne drew</span>]] 22:42, 19 January 2023 (UTC) |
|||
#:Why does that make me think of ''[[wikt:lie back and think of England|lie back and think of England]]''? - <b>[[User:Jc37|jc37]]</b> 22:52, 19 January 2023 (UTC) |
|||
#'''Oppose'''. The sticky TOC is very useful and my eyes have started adjusting in a good way. [[User:Nirzardp|Nirzardp]] ([[User talk:Nirzardp|talk]]) 23:25, 19 January 2023 (UTC) |
|||
#'''Oppose''' not based on the merits of this discussion but for the fact that there is nothing to suggest this discussion will be more representative than any other. People should express their concerns and suggestions on the Vector 2022 talk page. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 23:52, 19 January 2023 (UTC) |
|||
#:You are welcome to your opinion, of course. But buried on some page away from the VP at this point is unlikely to get response from the WMF, in my opinion. YMMV, of course. - <b>[[User:Jc37|jc37]]</b> 23:55, 19 January 2023 (UTC) |
|||
#::I'm fairly sure that WMF accounts have been posting at the talk page of [[WP:VECTOR2022]]; I haven't seen one here. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 00:13, 20 January 2023 (UTC) |
|||
# Personally, I '''oppose''' undoing the improvements that the new skin brought. On behalf of users sans accounts, a reversion shouldn't take place without seeing analysis of all anonymous users versus those who've edited to voice objection to the change. — '''[[user:fourthords|<span style="color:#CC0000">Fourthords</span>]] | [[user talk:fourthords|=Λ=]] |''' 01:00, 20 January 2023 (UTC) |
|||
#'''Strong Oppose''': WMF has been responsive and painstakingly taking feedback on the designs and using data-driven arguments/research for what would benefit our readers. Thoughtful feedback by editors have been incorporated, for example the option to include/exclude margin space. Ultimately experienced editors always have the option to opt out/switch vector skins, but it is our main users, the readers who are not actively in these discussions whom we must have in sight. For what the vector skin does, it is barely a change and I would encourage WMF to be even more aggressive and bold in future. The fact mobile editing/navigation/talk page headers is still broken for so many users bothers me far more than this petty quibble about CSS. ~ 🦝 [[User:Shushugah|Shushugah]] (he/him • [[User talk:Shushugah|talk]]) 01:02, 20 January 2023 (UTC) |
|||
# '''Oppose'''. I really don't think this is something editors should decide; leave it to developers and more importantly ask the readers. And it is truly, IMO, too late now. Besides: I'll keep using old Vector, but is this change so horrible? '''[[User talk:J947|<span style="color:#137412;">J947</span>]]''' † <sup>[[Special:Contributions/J947|edits]]</sup> 01:05, 20 January 2023 (UTC) |
|||
#:If they have the power to roll it out, then they have the power to un-roll it out, at least technically. The only reason they couldn't is because it is easier to ask forgiveness than permission. [[User:Jeremy Jeremus|Jeremy Jeremus]] ([[User talk:Jeremy Jeremus|talk]]) 01:10, 20 January 2023 (UTC) |
|||
#::Well yes. But imagine the shitstorm which would arise if the change was reverted. If it's truly a massive problem, then wait a month or two and then – fill the dreaded whitespace with a reader poll on whether to keep the change or not. '''[[User talk:J947|<span style="color:#137412;">J947</span>]]''' † <sup>[[Special:Contributions/J947|edits]]</sup> 01:18, 20 January 2023 (UTC) |
|||
#:::How would that cause a shitstorm? If anything, waiting a few months to roll it back would cause a shitstorm - reverting the change now is the right move, not waiting and giving people the time to get somewhat used to the change before ripping it out from under them. [[User:WalnutBun|WalnutBun]] ([[User talk:WalnutBun|talk]]) 01:44, 20 January 2023 (UTC) |
|||
#:Unfortunately I have seen many comments similar to what Donald Trump said, "I know more than the generals do"- people who think they know better than the developers. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 01:21, 20 January 2023 (UTC) |
|||
#::The real problem here is developpers who think they know better than their community members what these members want and just refuse to listen to their complaints! [[User:Tvx1|T]][[User Talk:Tvx1|v]][[Special:Contributions/Tvx1|x]]1 01:45, 20 January 2023 (UTC) |
|||
#:::That is demonstratably false. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 01:47, 20 January 2023 (UTC) |
|||
#::The developers may know more about the technical details of the implementation, but they certainly don't know more about the summation of individual preferences and aims than the collective whole. This is analogous to the classic problem of centrally planned economies. Pure appeals to authority can only go so far. Sure, perhaps the dev team has a whole bunch of data about how decreased information density has xyz benefit and abc tradeoffs, and they also believe the benefits outweigh the costs (one-sided tradeoffs are extremely rare). But, if we disagree on the respective importance of those benefits and costs, then all the statistics in the world have no authority. [[User:IWantTheOldInterfaceBack|IWantTheOldInterfaceBack]] ([[User talk:IWantTheOldInterfaceBack|talk]]) 06:30, 20 January 2023 (UTC) |
|||
# '''Strong Oppose''': The new skin IS better, even though there is excess whitespace. Polls from both editors and readers have shown that less prefer the old one. I also fail to see the argument against limiting the text width and the new ToC. Additionally, though this did not contribute to my !vote, this RfC was way too preemptive. It was started less than a day after deployment, which means that a lot of people ''could'' simply need to be accustomed. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 01:20, 20 January 2023 (UTC) |
|||
#'''Oppose''' I had some issues with the new skin, and they have been fixed. I like being able to know what the readers are seeing. Tired of the wingers and the knockers. [[User:Hawkeye7|<span style="color:#800082">Hawkeye7</span>]] [[User_talk:Hawkeye7|<span style="font-size:80%">(discuss)</span>]] 01:27, 20 January 2023 (UTC) |
|||
#'''Oppose''' The "Enable limited width mode" should be disabled as the default for all readers, logged in or not. I think that'll get rid of most of the complaints about the new skin. [[User:Some1|Some1]] ([[User talk:Some1|talk]]) 01:29, 20 January 2023 (UTC) |
|||
#:This is my primary issue with the skin itself, but it won't fix the lack of communication that preceded the rollout. WMF claims they put up banners for almost a year before the change - I never saw anything of the sort, and I know I'm not alone - check [[Wikipedia_talk:Vector_2022]]. [[User:WalnutBun|WalnutBun]] ([[User talk:WalnutBun|talk]]) 01:40, 20 January 2023 (UTC) |
|||
#:I agree with this. '''[[User:Andrevan|Andre]]'''<span style="border:2px solid #073642;background:rgb(255,156,0);background:linear-gradient(90deg, rgba(255,156,0,1) 0%, rgba(147,0,255,1) 45%, rgba(4,123,134,1) 87%);">[[User_talk:Andrevan|🚐]]</span> 04:15, 20 January 2023 (UTC) |
|||
#'''Oppose''' The people who know enough to vote here know how to change their skin. The design team has a ''lot'' of incentives to get things right for unregistered accounts and so even if it's not there yet - and I suspect it's not - they'll get there. I wanted to like this change, I found it broke some things I can't live without, I've gone back but that doesn't mean I should impose my preference on a much larger set of people. And I say all this despite the fact that I think the WMF team has made it clear, despite statements to the contrary, that our feedback doesn't matter. Bad form on them for sure. But that's not a reason to rever the change either. Best, [[User:Barkeep49|Barkeep49]] ([[User_talk:Barkeep49|talk]]) 02:14, 20 January 2023 (UTC) |
|||
#:Could you please clarify? I've read your comments a couple times now, and they seem to say: "The WMF did this badly on several fronts and this change is causing me issues personally, but that's ok, let the change stand simply because it's already done, and they aren't listening to us anyway." |
|||
#:What am I missing? - <b>[[User:Jc37|jc37]]</b> 03:17, 20 January 2023 (UTC) |
|||
#'''Oppose'''. It's a fine, reader-friendly, long overdue change. [[User:Enterprisey|Enterprisey]] ([[User talk:Enterprisey|talk!]]) 02:42, 20 January 2023 (UTC) |
|||
#'''Oppose''' as I find it a much welcome improvement over the old skin. [[User:Lightoil|Lightoil]] ([[User talk:Lightoil|talk]]) 03:04, 20 January 2023 (UTC) |
|||
#I think the best path forward is to keep the Vector 2022 skin in place as the default skin and work on improving it. The design team owns the default site appearance and thus can set the guiding principles it wishes to follow. The community can continue to give feedback on the metrics that should be gathered through user testing (to supplement the user testing that has already been done) to evaluate the efficacy of the default skin. [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 03:05, 20 January 2023 (UTC) |
|||
#'''Oppose''' It is a fine skin with some important improvements. --[[User:Enos733|Enos733]] ([[User talk:Enos733|talk]]) 03:18, 20 January 2023 (UTC) |
|||
#'''Oppose'''. Wikipedia has been due for a refresh in its design for a while now, as standards in web design have shifted since 2010. In order for me to support a reversal, I would like to see compelling evidence that the new design is truly detrimental to readers, rather than just procedural arguments (e.g. WMF should have started a new RfC first) or personal preference (e.g. preferring the old design simply because you're more used to it). Two independent media commentators have written that the redesign is "barely noticeable" and "doesn't rock the boat", see [https://slate.com/technology/2023/01/wikipedia-redesign-vector-2022-skin.html][https://www.engadget.com/wikipedia-desktop-web-redesign-211000932.html]. Sure, it would have been ideal for the WMF to start a second RfC and get affirmative backing from this community before turning it on, but I do not believe the new skin is so severely bad that we need to roll it back, rather than fix it forward (i.e. fixing issues with the new skin in place). [[User:Mz7|Mz7]] ([[User talk:Mz7|talk]]) 03:27, 20 January 2023 (UTC) |
|||
#:Didn't catch the irory behind the cited comentators? [[Special:Contributions/37.134.90.176|37.134.90.176]] ([[User talk:37.134.90.176|talk]]) 13:56, 20 January 2023 (UTC) |
|||
#::There is none, unless you show me how the heck this is ironic. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 14:11, 20 January 2023 (UTC) |
|||
#'''Oppose'''. Not necessary. Just configure a different skin in your preferences. I was using Monobook for a long time and I still might go back to it, tho I'm giving Vector 22 a try right now. '''[[User:Andrevan|Andre]]'''<span style="border:2px solid #073642;background:rgb(255,156,0);background:linear-gradient(90deg, rgba(255,156,0,1) 0%, rgba(147,0,255,1) 45%, rgba(4,123,134,1) 87%);">[[User_talk:Andrevan|🚐]]</span> 03:58, 20 January 2023 (UTC) |
|||
#:To use preferences, one must make an account and use it wherever you might read wikipedia from. If people are making "single purpose" accounts to fix this and complain about it, that should be an indicator of a bad design. Otherwise you are stuck having to use third party scripts, addons or otherwise, as have been suggested in other discussions. The bookmarklet and url modification methods are stopgaps at best, and are among the worst "solutions" provided for ip users. [[User:Deadoon|Deadoon]] ([[User talk:Deadoon|talk]]) 04:24, 20 January 2023 (UTC) |
|||
#'''Oppose'''. I have chosen to return to the legacy Vector skin until a few of my personal efficiency bugbears have been sorted but I recognize that the new skin has substantial improvements. People have howled at website redesigns with objective improvements since the dawn of the internet. Change is scary, but it's also life. [[User:Axem Titanium|Axem Titanium]] ([[User talk:Axem Titanium|talk]]) 04:24, 20 January 2023 (UTC) |
|||
#'''Oppose''' - not sure what everyone else is reading, but when I Google "new Wikipedia layout" and read literally anything written about this today, the universal opinion appears to be that it is a barely noticeable but welcome change. I reverted back to the old one, but it seems clear to me the general public likes this. If anything, they think it's not ''enough'' of an update. [[User:Levivich|Levivich]] ([[User talk:Levivich|talk]]) 05:19, 20 January 2023 (UTC) |
|||
#:This recalls to me the idiom: "eat shit, four billion flies cannot be wrong"... Sorry, I can't resist... [[Special:Contributions/37.134.90.176|37.134.90.176]] ([[User talk:37.134.90.176|talk]]) 14:01, 20 January 2023 (UTC) |
|||
#'''Oppose'''. Wikipedia was long overdue a design update. People [[Wikipedia:User experience feedback/Archive 1|were complaining]] when we switched from monobook to vector, the cycle is repeating now. his is just knee-jerk reaction against any change, give it some time and people will get used to it. Personally I will continue using legacy vector until it is broken to the point of being unusable, but the way active editors like me use Wikipedia is very different from that of an average reader. I think this change is an improvement for readers, something which people in real life has agreed with me. There is room for improving vector-2022 of course, but rolling it back is not useful. [[User:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ]] ([[User talk:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|talk]]) 06:10, 20 January 2023 (UTC) |
|||
#'''Strong Oppose''' (aka '''No, Just No''') - (TLDR: Vector is old/broken, the newer skin looks better and is more usable to casual users, and the team behind it is responsive, just saying I don't like it isn't the way to go) I think the community here has a very strong false assumption that everyone likes seeing Wikipedia the way wikipedia editors (i.e. mostly power users) like to see it. As primarily a Wikipedia reader, this skin is a much better than normal Vector since it has a familiar layout similar to the myriads of technical blog sites, tech news websites, documentation etc. It allows you to consume content without actually having to turn ones head on a widescreen display. Additionally, the ability to choose ones layout even as a IP basically gives you the ability to customize the style you want for reading even without having to log in.<br><br>Also, from a purely technical standpoint, rejecting this skin will be a big blow to our ability to modernize our interface with newer technologies and providing a better experiences by eliminating technical debt. If you personally don't like please shift to a different skin/old Vector, don't block what is arguably better both for users and the technical growth for the project.<br><br>Additionally, based on my personal experiences, the team rolling out this change has been extremely receptive to feedback and has helped immensely in integrating older tools and has made extensive changes to accomodate the same (c.f Wikisource ProofreadPage integration). I think we made a concerted effort of reporting bugs and issues (via phabricator/vpt etc) instead of doing whatever this is, we would be able to reach a equilibrium much faster. -- 07:59, 20 January 2023 (UTC) |
|||
#:{{small|(note that I am involved in the technical side of the project and have interacted with engineers as well as written multiple patches for ProofreadPage and associated Wikisource related technical issues) -- [[User:Sohom data|Sohom Datta]] ([[User talk:Sohom data|talk]]) 07:59, 20 January 2023 (UTC)}} |
|||
#'''Oppose''' - what's done is done. It would be a better use of our time to try to improve Vector 2022 with bug reports and suggestions. The dev team have made it clear they're not going to just abandon this new skin, and they've also already responded to various concerns, such as through the addition of a width button. [[User:Anarchyte|<span style="color:#202122;font-family:Trebuchet MS">Anarchyte</span>]] ([[User talk:Anarchyte|<span style="color:#202122">talk</span>]]) 08:07, 20 January 2023 (UTC) |
|||
#: A width button that may as well not be there for all the good it does, since if you're not logged in, you have to toggle it for every single page you read every single time you open the site. That's not a solution, it's a way to frustrate people into giving up viewing Wikipedia the way they want to view it. --[[User:Kizor|Kiz]][[Special:Contributions/Kizor|<span style="color:black;">o</span>]][[User_talk:Kizor|<span style="color:green;">r</span>]] 09:48, 20 January 2023 (UTC) |
|||
#'''Strongest oppose possible''' – See [[Wikipedia:Vector]] for [[déjà vu]]. Changes will invariably break things, and if we don't want to break things we might as well don't try anything new in the first place. If you hate this new skin, you can switch to the old skin. Here are a few more reasons why: |
|||
## The developers do listen to feedback and is really responsive, they've learned from [[WP:VisualEditor]] deployments and has made a [[mw:Reading/Web/Desktop Improvements|concrete plan on how to redesign the skin]] |
|||
## The new skin reduces friction for readers to digest information |
|||
## It's ergonomic for editing Wikipedia once you've gotten used to it |
|||
#:A lot of the support comments are made by people who are [[Technology adoption life cycle|behind the technology adoption life cycle]] and may need more time to adjust to the changes. I, myself, used to dislike Vector 2022, but I've gotten used to it since then and like the changes. [[User:CactiStaccingCrane|CactiStaccingCrane]] 08:35, 20 January 2023 (UTC) |
|||
#:Evidence to support my claims: |
|||
#:* [https://slate.com/technology/2023/01/wikipedia-redesign-vector-2022-skin.html Slate – Wikipedia’s Redesign Is Barely Noticeable. That’s the Point.] |
|||
#:* [https://www.engadget.com/wikipedia-desktop-web-redesign-211000932.html Engadget - Wikipedia's first desktop design update in a decade doesn't rock the boat (updated)] |
|||
#:[[User:CactiStaccingCrane|CactiStaccingCrane]] 08:43, 20 January 2023 (UTC) |
|||
#::I am a professional software engineer. Don't presume anything about others that you don't know. I am very familiar with technology. I also think the trend in the past decade of reducing information density at the expense of everything else is terrible. Clearly, many agree with me. |
|||
#::And no, contrary to your comment on my page, I will not stop voicing my opinion on the redesign. [[User:IWantTheOldInterfaceBack|IWantTheOldInterfaceBack]] ([[User talk:IWantTheOldInterfaceBack|talk]]) 09:03, 20 January 2023 (UTC) |
|||
#'''Oppose'''. This is pointless grumbling. The English Wikipedia community has the final say on the content of the English Wikipedia. It [[WP:CONEXCEPT|doesn't have the final say]] on the software it runs on. Nobody likes [[design by committee]] and design by community is even worse. The WMF web team have been extraordinarily patient in soliciting and acting on our feedback up until now, so let's give them the benefit of the doubt and let them do their job. – [[User:Joe Roe|Joe]] <small>([[User talk:Joe Roe|talk]])</small> 09:33, 20 January 2023 (UTC) |
|||
#:[[WP:V22RFC|It does]], and since WMF didn't dismiss swwwiki's appeal to revert the change(WMF said they'll "discuss it") this is clearly possible. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 12:53, 20 January 2023 (UTC) |
|||
#::Tha that WMF (rightly) asked us what we think about a change does not mean that they're ceding the decision on it to us. I don't think there's much harm in the RfC (except hammering the wedge between enwiki and the WMF even further in) but I guarantee you it won't get Vector 2022 scrapped. – [[User:Joe Roe|Joe]] <small>([[User talk:Joe Roe|talk]])</small> 13:07, 20 January 2023 (UTC) |
|||
#:::Nobody is suggesting that Vector 2022 be scrapped, and suggesting that we are is arguing in bad faith. We are requesting that the default UI be reverted back to Vector legacy, and that people be given the option to continue using Vector 2022 if they so desire. [[User:WalnutBun|WalnutBun]] ([[User talk:WalnutBun|talk]]) 00:46, 21 January 2023 (UTC) |
|||
#'''Strongest oppose possible'''. This RFC is balderdash. The idea of "voting" on redesigns is as nonsensical as voting on [[Fountain (Duchamp)|Duchamp's ''Fountain'']]. UI design is based on objective principles, not on what a loud minority thinks. Objective feedback can only be obtained through [[revealed preference]]s, i.e. by measuring opt-outs. This pushback is caused by resistance to change, not by any objective attributes of the new design. Logged-in users also have no basis to complain on behalf of hypothetical logged-out users; just switch it in your preferences. And no matter the outcome, this can't possibly override the close of the previous, far more prominent RFC. [[User:DFlhb|DFlhb]] ([[User talk:DFlhb|talk]]) 09:46, 20 January 2023 (UTC) |
|||
#'''Strongest oppose possible''' This is a terrible idea. Revert to a technically backwards skin? Really? I switched to Vector 2022 some time ago and have never regretted it. I'm a long time editor with 249564 edits so I have a lot of experience with different skins, and this is by far the best one I've had. Maybe there are some things that can still be improved, eg people complain about a width issue (which I don't have), but the developers have been responsive and I'm sure will continue to be. And this RfC should have at least waited a few weeks for obvious reasons - a lot of people are uncomfortable with change but ever a little while see it as ok or good. [[User:Doug Weller|<span style="color:#070">Doug Weller</span>]] [[User talk:Doug Weller|talk]] 09:48, 20 January 2023 (UTC) |
|||
#'''Strongest oppose possible''' Supporting a revert is what keeps us humanity from evolving and making progress. [[User:Coldbolt|Coldbolt]] ([[User talk:Coldbolt|talk]]) 10:03, 20 January 2023 (UTC) |
|||
#:This change wasn’t progression in any way.[[User:Tvx1|T]][[User Talk:Tvx1|v]][[Special:Contributions/Tvx1|x]]1 14:29, 20 January 2023 (UTC) |
|||
#::How not? Pioneering the change to mustache, adopting newer design guidelines, floating a bar and toc for easy navigation, images in search… [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 14:48, 20 January 2023 (UTC) |
|||
#:Not all software change is progress. Reverting it's redesign could have saved [[Quora]] from decline, but it's management refused to listen to the wishes of it's volunteer community.–[[User:SmallJarsWithGreenLabels|small jars]] <small><code>[[User talk:SmallJarsWithGreenLabels|<b style="color:#270">t</b>]][[special:contributions/SmallJarsWithGreenLabels|<b style="color:#270">c</b>]]</code></small> 17:20, 20 January 2023 (UTC) |
|||
#'''Strong oppose''' - Everyone hates change at first, but i, for one, quite like the new design; it’s just a few sensible updates to bring Wikipedia into its third decade and account for ever-widening screens. (I do agree with some that it would be nice to give IP users a way to toggle the theme!) [[User:MarijnFlorence|MarijnFlorence]] ([[User talk:MarijnFlorence|talk]]) 11:34, 20 January 2023 (UTC) |
|||
#'''Oppose''' (for the moment). There are a few things not to like at the moment (the default to a narrow view, for example, although that can be altered) and it's taking a bit of time to get used to, but change is normally difficult to accept at the start. One fix I would like to be implemented is to deal with the lack of user links in the top right - having talk, sandbox and contributions hidden in a dropdown is a backwards step for ''editors'' (although readers won't worry about it too much) If there is an option for users to decide what links can appear in the top right (and what to consign to a drop down), that would be a step forward. - [[User:SchroCat|SchroCat]] ([[User talk:SchroCat|talk]]) 11:37, 20 January 2023 (UTC) |
|||
#'''Oppose''' for now —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 12:03, 20 January 2023 (UTC) |
|||
#'''Oppose'''. I voted against rollout, but am now fairly neutral on the redesign as my main single complaint (the limited width) was addressed. I think the majority of end users will, once they find the toggle, choose unlimited width (hence my contribution below), but I think Vector 2022 is an improvement. I am opposing for now so we can collect more information. [[User:JackWilfred|JackWilfred]] ([[User talk:JackWilfred|talk]]) 12:48, 20 January 2023 (UTC) |
|||
#'''Oppose'''. If you want to revert, set your preferences. [[User:Cabayi|Cabayi]] ([[User talk:Cabayi|talk]]) 13:48, 20 January 2023 (UTC) |
|||
#:As many said, no preferences for non-logged users. Must every reader or editor have an account here, against their own desires? [[Special:Contributions/37.134.90.176|37.134.90.176]] ([[User talk:37.134.90.176|talk]]) 14:41, 20 January 2023 (UTC) |
|||
#'''Oppose'''. But this highlights issues with the rollout, and why ~50/50 rfc's make for fragile consensus at best. <span style="color:#666">– [[User:Sj|SJ]][[User Talk:Sj|<span style="color:#f90;"> +</span>]]</span> 14:00, 20 January 2023 (UTC) |
|||
#'''Inhumanly strong oppose'''. Every change is going to be met with discomfort at first. But as with all UX/UI changes, we eventually adapt.--'''[[User:WaltCip|🌈<span style="color: white; font-weight: bold; background: linear-gradient(red, orange, green, blue, indigo, violet)">WaltCip</span>]]'''-''<small>([[User talk:WaltCip|talk]])</small>'' 14:06, 20 January 2023 (UTC) |
|||
#'''Strong oppose''' - My views align with those expressed above by {{noping|Shushugah}}. In this case, the new design aligns with internet accessibility principles and modern design guidelines which I think sit above crowd wisdom. — [[User:Ixtal|Ixtal]] <sup>( [[User talk:Ixtal|T]] / [[Special:Contributions/Ixtal|C]] ) </sup> ⁂ <small> [[Non nobis solum]]. </small> 14:33, 20 January 2023 (UTC) |
|||
#'''Strong Oppose''': So the proposal is to force Vector 2010 upon all users because "WMF is forcing Vector 2022 upon all users" (just like they forced Vector 2010 and all other skins before that). I say: unless you can measurably prove that V2010 was so much better switch back to old Vector for yourself and get over it. Imagine cars, sky scrapers, ships and airplanes were designed by popular vote... [[User:Ponor|Ponor]] ([[User talk:Ponor|talk]]) 14:49, 20 January 2023 (UTC) |
|||
#:I don't think this situation is comparable to designing a car or an airplane. It's more akin to deciding what is built in your neighborhood, e.g. whether to build a community garden or a parking space. Which is usually decided by some sort of democratic(ish) approach between actual people living in the neighborhood. Not ''how'' to build it, that's the job of engineers. [[User:RoadTrain|RoadTrain]] ([[User talk:RoadTrain|talk]]) 16:27, 20 January 2023 (UTC) |
|||
#::I think it’s more like whether to use sprawling parking or compact parking with multiple floors [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 16:33, 20 January 2023 (UTC) |
|||
#::From day one it was Jimbo or WMF or whoever deciding what our "cars" would/should look like. And they left us with some choices: if you like Lada, you choose Lada, if you like Mazda better, you choose Mazda, and if you want to stick with your old Ford, they give you the option to stay with Ford, it's all here [[Special:Preferences]]. If we're about to impose the look on other users, are we any different than WMF? What do we base our decision on, the votes of a few loud ones on this page? [[User:Ponor|Ponor]] ([[User talk:Ponor|talk]]) 17:07, 20 January 2023 (UTC) |
|||
#'''Oppose''' per WaltCip above. I don't care for the new skin either. But lots of time has gone into hearing and implementing community feedback. Let's give this six months and see how many of us get used to it. [[User:Ajpolino|Ajpolino]] ([[User talk:Ajpolino|talk]]) 15:38, 20 January 2023 (UTC) |
|||
#'''Oppose'''. I believe we should focus on resolving potential problems with Vector 2022 instead of arguing which skin should be the default, because the latter mostly depends on personal preference. <span style="font-family:Iosevka,monospace">0x[[User:0xDeadbeef|<span style="text-transform:uppercase;color:black">'''Deadbeef'''</span>]]</span>→∞ ([[User talk:0xDeadbeef|talk to me]]) 16:12, 20 January 2023 (UTC) |
|||
#'''Oppose''' – I've been using Vector (2022) on the Mediawiki project since it was changed to default there and made no attempt to change it back to Vector (2010), and have just switched to it on our private wiki but left the system-wide default alone. I want to use it on Wikipedia too, but I cannot just yet. I switched it back to Vector (2010) and use a browser bookmark for the enwiki login using the old skin. Easy-peasy! There are many things I LIKE about the new skin and I can appreciate all the work and long hours that went into its development. I see room (literally) for improvement, and I know that this will come in due time. Although I understand the passion, I DON'T LIKE some of the behaviour towards others. Perhaps they feel it's needed just to be heard. I also noticed that some who participated in the RfC feel like they too were ignored. There may be a need to look at that more closely. Finally, for IP users, giving them a “switch to old look” hyperlink might be worth considering. — '''[[User:WildStar|<span style="color:#000000">W<small>ILD</small>S<small>TAR</small></span>]]'''<sup>''[[User talk:WildStar|<span style="color:#808080"><small>TALK</small></span>]]''</sup> 16:54, 20 January 2023 (UTC) |
|||
#I am !voting '''Oppose''': if the limited width is changed to opt-in, per Question 2 below, everything else in this beta skin can be tweaked and worked on. I have been able to use custom CSS to make my Vector 2022 interface look better; some of that can get incorporated into the skin, and some can become shared scripts and CSS for power users. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 17:15, 20 January 2023 (UTC) |
|||
#'''Oppose''' – Vector 2022 is not perfect, but I think its flaws have been blown significantly out of proportion. Switching back and forth is more likely to cause confusion among casual readers than any benefit it might deliver. [[User:RunningTiger123|RunningTiger123]] ([[User talk:RunningTiger123|talk]]) 17:36, 20 January 2023 (UTC) |
|||
# '''Weak oppose''' – I do actually think the fixed width is a significant improvement in reading experience on wide monitors at least, and something worth exploring further. It's the other things about the new skin that I don't like, namely the "simplification" of the UI due to the lack of visual contrast between the article body, TOC, header and everything else. –'''[[User:Sonicwave32|<span style="color:green;">Sonicwave</span>]] <small><sup>[[User talk:Sonicwave32|<span style="color:#008FB2">talk</span>]]</sup></small>''' 18:41, 20 January 2023 (UTC) |
|||
#'''Oppose''' for two main reasons: |
|||
#*This has been in the works for quite some time and has been successfully in use in other wikis; given that, had I voted in the previous discussion, I would have said "yes, go ahead and make the changes for the sake of the common reader, even if I will keep using legacy Vector". If anything, I'm more bugged that logged out users will see two different skins depending on which wiki they're on, though by all indication, this won't be a problem in the long term. |
|||
#*There are some things that I like better about Vector 2022 - the search bar showing images and short descriptions, the left-hand sidebar being collapsible, and the sticky header and table of contents. The look and feel is something I'll have to get used to, as are the new link colors (which I know were altered with color-blindness in mind); this is a given. It just goes to show that [[WP:ILIKEIT]] and [[WP:IDONTLIKEIT]] are both opposing forces grounded in subjectivity. |
|||
#:I can tell there was a lot of thought put into this new design, and while some aspects are understandably controversial, I am at least happy improvements have been made; I remember the logo placement/spacing being awkward in older versions, but that is happily no longer a problem. I doubt the WMF would reverse this regardless of this RfC's outcome, and I imagine the complaints will die down after some time, but people have voiced their concerns, and if this goes through, [[The Way It Is (song)|that's just the way it is]]. -'''''[[User:Brainulator9|B<small>RAINULATOR</small>9]] ([[User talk:Brainulator9|TALK]])''''' 18:49, 20 January 2023 (UTC) |
|||
#::About Vector 2022 being "successfully in use in other wikis", there have been witnesses from the [https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1134803309#Opinion_of_a_reader_on_this_design_change French Wikipedia] (the first on which it was implemented) and the [https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Vector_2022&oldid=1134802204#All_critizism_will_be_ignored Swedish Wikipedia] testifying that it caused strong grassroots opposition from the respective communities, which were largely ignored. [[User:Æo|Æo]] ([[User talk:Æo|talk]]) 19:30, 20 January 2023 (UTC) |
|||
#'''Oppose'''. There are some things I like about the new UI, some things I don't, but everyone should give it some time to get more used to it. [[User:Wasted Time R|Wasted Time R]] ([[User talk:Wasted Time R|talk]]) 19:52, 20 January 2023 (UTC) |
|||
#'''Oppose''' - the new layout is better than previously, and will improve when changes already underway (esp. around page width) have been addressed. I agree with others about change being scary - lots of the above comments reminds me of the hullabaloo about the [[Facebook]] redesign back in the day! [[User:Turini2|Turini2]] ([[User talk:Turini2|talk]]) 20:58, 20 January 2023 (UTC) |
|||
#:No it isn’t even remotely. It’s far worse in every possible way. [[User:Tvx1|T]][[User Talk:Tvx1|v]][[Special:Contributions/Tvx1|x]]1 22:41, 20 January 2023 (UTC) |
|||
#'''Oppose''' per wasted time r. [[User:Schierbecker|Schierbecker]] ([[User talk:Schierbecker|talk]]) 23:14, 20 January 2023 (UTC) |
|||
# Per my original comments which were curiously moved to the bottom of this discussion when it was refactored to place only supports at the top. <span style="white-space: nowrap;">— [[User:Wugapodes|Wug·]][[User talk:Wugapodes|a·po·des]]</span> 23:39, 20 January 2023 (UTC) |
|||
#'''Oppose'''—I have a confession to make: I have never liked Vector 2010. Ever. I thought the hue of pale white it used was drab, depressing, and off-putting. When Vector was set as the default skin for Wikipedia, I immediately set my preferences to "Monobook" (the default pre-2010) and never looked back. I tried out a few other skins in the past, but I found that Monobook remained my favorite, and so it stayed. I'm not inherently averse to change if it involves genuine improvements; by that same token, I'm also not swayed by arguments in favor of new designs or systems that essentially boil down to, "change is a part of life, get used to it." Change isn't always a good thing, especially not if it leaves us worse off than before. With that in mind, I decided to check out the new design myself, using an incognito window on my Chromebook.<p>My opinion? Vector 22 is an improvement from 2010. I like that the table of contents section has been moved to the left panel when browsing a page—makes it so that you can navigate between subsections much more easily. <s>I also like how hovering your mouse over a link doesn't just show the name of the page, but a pop-up window with the first few sentences of text accompanied by the infobox image (assuming there is one).</s> Do I think the new design is perfect? Definitely not—there are certainly some improvements to be made that I would deem necessary. For instance, when you click the "hide" button to remove the table of contents from the screen, the "unhide" option (i.e. the jot notes icon beside the article's title) isn't immediately obvious, which I think is problematic. I'd also support making the side panel a different color so as to distinguish it from the page's text. But on the whole, I like Vector 2022, and I'm even thinking about switching from Monobook to the new design.<p>In short, I feel that Vector 2022 is more user-friendly, more inviting, and an all-around step up from what came before it. It's not without some shortcomings, but as a default skin for readers, it's probably the best we've got. I say we keep it. [[User:Kurtis|Kurtis]] [[User talk:Kurtis|<sup>(talk)</sup>]] 23:47, 20 January 2023 (UTC) |
|||
#:<small>{{re|Kurtis}} just FYI, the pop-up window with the lead sentence and lead image has also been part of legacy Vector for a few years now. <span style="text-shadow:#000 0em 0em 1em">☿ [[User:Apaugasma|<span style="color:#6a0dad">Apaugasma</span>]] ([[User talk:Apaugasma|<span style="color:#000">talk</span>]] [[Special:Contributions/Apaugasma|☉]])</span> 00:08, 21 January 2023 (UTC)</small> |
|||
#:As {{np|Apaugasma}} pointed out, {{tq|1=a pop-up window with the first few sentences of text accompanied by the infobox image (assuming there is one)}} is actually from a different feature which users can toggle at {{myprefs|Appearance|Reading preferences|Enable page previews}}. I believe it is enabled for unregistered users by default. —[[User:Tenryuu|<span style="color:#556B2F">Tenryuu 🐲</span>]] ( [[User talk:Tenryuu|💬]] • [[Special:Contributions/Tenryuu|📝]] ) 00:12, 21 January 2023 (UTC) |
|||
#::Thanks for the heads-up—will strike that part shortly. [[User:Kurtis|Kurtis]] [[User talk:Kurtis|<sup>(talk)</sup>]] 00:13, 21 January 2023 (UTC) |
|||
#'''Oppose''' Ok...at first I hated it. To be honest, though, I would've hated ANY interface change for the next year, 10 years, 100 years... Vector 2010 is old. We've needed something new for a while. And of course, we'll adapt. [[User:DecrepitlyOnward|DecrepitlyOnward]] ([[User talk:DecrepitlyOnward|talk]]) 00:26, 21 January 2023 (UTC) |
|||
#'''Oppose''' I don't think the issues are big enough to warrant reversion of this, even if the community here could do such a thing. [[User:Dreamy Jazz|Dreamy <i style="color:#d00">'''Jazz'''</i>]] <sup>''[[User talk:Dreamy Jazz|talk to me]]'' | ''[[Special:Contribs/Dreamy Jazz|my contributions]]''</sup> 00:51, 21 January 2023 (UTC) |
|||
#'''Oppose''' - what is done is done. I am just as disappointed in how the skin was rolled out as everyone else who saw the switch to Vector 2022. Feedback for the future: Rather than completely revamping the site, what would be better are incremental changes. Also I think of Vector 2022 as reinventing the wheel; Timeless is a much more polished skin that has responsive support, a decent-sized font, and good use of space on the left and right. As a community, we have bigger fish to fry in terms of managing content. I hated Vector 2010 because of its lack of responsive design and its lack of features. From this point forward, I think WMF's design team should focus its resources on continuously expanding the ability of the new Vector skin, so they are fit for the modern web. [[User:Awesome Aasim|Aasim]] - [[User_talk:Awesome Aasim|Herrscher of Wikis]] ❄️ 01:03, 21 January 2023 (UTC) |
|||
==== Neutral ==== |
|||
#'''Neutral'''. As a (younger and more tech-savvy?) user who's been using the skin for more than half a year, I've gotten used to it at this point. The whitespace margin issues that are plaguing many others I've solved for myself by enlarging text for the domain, and the only real gripe that I have at this point is not having a persistent hidden table of contents across pages, which is being tracked on Phabricator. —[[User:Tenryuu|<span style="color:#556B2F">Tenryuu 🐲</span>]] ( [[User talk:Tenryuu|💬]] • [[Special:Contributions/Tenryuu|📝]] ) 01:19, 20 January 2023 (UTC) |
|||
#:Enlarging text size was the solution I also implemented. Personally I've always been a fan of the skin. <span style="font-weight:bold;color:darkblue">[[User:Moxy|Moxy]]</span>-[[File:Maple Leaf (Pantone).svg|15px|link=User talk:Moxy]] 02:12, 20 January 2023 (UTC) |
|||
#::There's a checkbox in the prefs that really fixes it. '''[[User:Andrevan|Andre]]'''<span style="border:2px solid #073642;background:rgb(255,156,0);background:linear-gradient(90deg, rgba(255,156,0,1) 0%, rgba(147,0,255,1) 45%, rgba(4,123,134,1) 87%);">[[User_talk:Andrevan|🚐]]</span> 04:15, 20 January 2023 (UTC) |
|||
#:::I was made aware of it a while back, though at a much later date than my own fix. —[[User:Tenryuu|<span style="color:#556B2F">Tenryuu 🐲</span>]] ( [[User talk:Tenryuu|💬]] • [[Special:Contributions/Tenryuu|📝]] ) 04:29, 20 January 2023 (UTC) |
|||
#'''Neutral'''. As much as I don't like the new skin, it's not like I can't change back to Vector 2010 (and I did just that). However, I'll echo other people who say that if [[WP:SPA|single-purpose accounts]] are created for the sole purpose of changing back to an older skin, then the design might be to reconsider. [[User:LilianaUwU|<span style="font-family:default;color:#00c6ff;">''Liliana''</span><span style="font-family:Comic Sans MS;color:#ff879a;">''UwU''</span>]] <sup>([[User talk:LilianaUwU|talk]] / [[Special:Contributions/LilianaUwU|contribs]])</sup> 05:13, 20 January 2023 (UTC) |
|||
#'''Neutral''' I changed to Vector2022 few days ago and it is somewhat mixed experience. There are things I like (table of contents on the left), things I don't like (watchlist etc. buried behind icons) and things I don't care (whitespace - I prefer smaller paragraph width anyway). That is on 2560x1440 display with 150 % UI scaling. My other devices use lower screen resolution (1366x768 on notebook and 1280x1024 on Pegasos 2) and my intention is to thoroughly test Vector2022 with these computers during weekend. [[User:Pavlor|Pavlor]] ([[User talk:Pavlor|talk]]) 06:30, 20 January 2023 (UTC) |
|||
#'''Conflicted/Neutral''' I don't know how I feel about this in all honesty. On the one hand, I got used to Vector 2022 after a bit and didn't really mind it. However on the other hand there appears to be major backlash to this change (yes it might take a bit for people to get used to it but we don't know that) and a general opposition from the community. So I'm not entirely sure. Wikipedia is supposed to be sort of community based, however if the community doesn't like it then should we ignore them because statistics say the new skin is better or should we listen to them? I might add to this !vote later on as I compose my thoughts more on this matter, but for now this is how I feel. ― [[User:Blaze Wolf|<b style="background:#0d1125;color:#51aeff;padding:1q;border-radius:5q;">Blaze Wolf</b>]][[User talk:Blaze Wolf|<sup>Talk</sup>]]<sub title="Discord Username" style="margin-left:-22q;">Blaze Wolf#6545</sub> 15:30, 20 January 2023 (UTC) |
|||
#'''Neutral''' — I agree with users arguing that changes to user interfaces are most often badly received yet absolutely necessary, and I do think that some of the changes are improvements and that asking for further upgrades to Vector 2022 is the way to go.{{pb}}However, I also believe that limiting the line width and thus text density would be detrimental for an ''encyclopedia'' (as opposed to others text types in which limited line width is commonly used, to which the [[mw:Reading/Web/Desktop Improvements/Features/Limiting content width#Research|research cited]] seems to be confined), because it makes 'looking up things' much harder (and 'looking up' benefits from being able to see more text and structural elements at once; more on that in my !vote on [[Wikipedia:Village_pump_(proposals)#Question_#2:_If_Vector_2022_is_kept_as_default,_should_unlimited_text_width_be_the_default?|Question 2]] below).{{pb}}If unlimited line width would be the default for unregistered users (about whom anything !voted for or against in this RfC should be) in Vector 2022, I would strongly oppose rolling back to legacy Vector. However, if the limited line width must be a part of Vector 2022's default configuration, I think unregistered readers would be better served by legacy Vector, however outdated it may be. <span style="text-shadow:#000 0em 0em 1em">☿ [[User:Apaugasma|<span style="color:#6a0dad">Apaugasma</span>]] ([[User talk:Apaugasma|<span style="color:#000">talk</span>]] [[Special:Contributions/Apaugasma|☉]])</span> 23:57, 20 January 2023 (UTC) |
|||
==== RfC discussion ==== |
|||
*'''Comment'''. I don't yet know what I think about the new skin yet; I'm actually trying it out instead of insulting the developers or thinking I'm smarter than them or cursing at them or any of this other unreasonable hostility. But what makes you think that this RFC will be more representative than the one they already did? Especially since people are more likely to complain than praise. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 20:51, 19 January 2023 (UTC) |
|||
*'''Revert to MonoBook, my favorite skin''' Why stop at 2010 vector? I use MonoBook which was the default before 2010 Vector, so let's go back to ''my'' favorite skin. It's also still the default on [[bulba:Bulbapedia:Editor's_Hub|BulbaPedia]], one of the largest Pokemon wikis, so at least one other large community agrees with me that Vector 2010 was inferior to MonoBook. This is all tongue-in-cheek, of course, because none of this affects me as a MonoBook user. I didn't like Vector 2010, so I changed the settings to use a skin I did like; I don't see how that's not a solution if the complaints are mostly aesthetic. <span style="white-space: nowrap;">— [[User:Wugapodes|Wug·]][[User talk:Wugapodes|a·po·des]]</span> 21:15, 19 January 2023 (UTC) |
|||
::{{u|Wugapodes}} A big complaint I see is that IPs or users who rarely edit don't want to(for some reason) have to log in to use their preferred skin. I have to log in to my bank website every day to see how much of my money they have, I don't see how this is different. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 21:19, 19 January 2023 (UTC) |
|||
:::I'm a strong proponent of unregistered editing, but if a reader feels so strongly about the aesthetics of a website, creating an account to save their preferences seems like a reasonably common trade-off all things considered. Unregistered editing comes with many, more serious trade-offs that those editors must accept---disclosure of IP info, unstable attribution, susceptibility to range blocks, limited participation in project governance---so I don't think adding "susceptible to decennial skin changes" is something I find too onerous to put on unregistered editors. <span style="white-space: nowrap;">— [[User:Wugapodes|Wug·]][[User talk:Wugapodes|a·po·des]]</span> 21:44, 19 January 2023 (UTC) |
|||
::Corporate policy at work is 'no personal accounts on corporate computers' - and getting a corporate account is very nearly impossible. This isn't a case of 'do not want'; it's a case of 'not allowed by policy'. [[Special:Contributions/192.157.110.190|192.157.110.190]] ([[User talk:192.157.110.190|talk]]) 02:15, 20 January 2023 (UTC) |
|||
:::That's a thin reasoning. You can always use "Bill from Corporation ACME" as your username. I don't think the community will find fault in this username scheme unless you are [[WP:COI]]. [[User:Robertsky|– robertsky]] ([[User talk:Robertsky|talk]]) 03:16, 20 January 2023 (UTC) |
|||
:::: Corporation might not like that though. "Only authorized people are allowed to represent the company" sort of thing. [[User:Anomie|Anomie]][[User talk:Anomie|⚔]] 15:36, 20 January 2023 (UTC) |
|||
*'''Comment''': I think the RFC asks the wrong question. As I said in the previous RFC, if the WMF would just make "wide mode" the default instead of opt-in, there would be much wider acceptance of Vector 2022. As it stands, if IP readers want "wide mode", they have to click the toggle (if it appears for them; it does not appear in some wide browser windows) on every page. There is no persistent "wide mode" for logged-out readers. If "wide mode" becomes the default, an IP reader who wants a persistent narrower mode will only have to shrink their browser window. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 21:18, 19 January 2023 (UTC) |
|||
::....which kinda goes to the root of the problem here in that there is no single change that every user will approve of. Improvements can always be made. Suggestions offered. This isn't the end, it's the beginning. People could at least try it out, the WMF says most of its testing showed that people got used to it after a few days. People use it for five minutes and see a single change they don't like and then curse the developers or say they are stupid. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 21:22, 19 January 2023 (UTC) |
|||
:::They needed/need to seek more and more specific feedback and integrate that into the design process. Nothing about curse or stupid. Some people might be quicker to get angry due to past history of WMF ivory tower and high-handedness incidents and that such seems to becoming systemic. <b style="color: #0000cc;">''North8000''</b> ([[User talk:North8000#top|talk]]) 21:35, 19 January 2023 (UTC) |
|||
::::Fair enough- and I thank you for your civility- but asking for broad community input on every minor change is a recipe for disaster and obstruction to changes. I saw far more complaints that Wikipedia appears like it was designed in the 1990s than calls to keep it the same. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 21:39, 19 January 2023 (UTC) |
|||
:::::The absurd amount of white space in Vector 2022 is, and always has been, the primary objection to it. I haven't done a full count, but the [[Wikipedia:Requests_for_comment/Deployment_of_Vector_(2022)#Oppose|first ten out of ten Oppose comments]] in the RFC mentioned the width problems, and they have not been fixed adequately. Many of us have tried to advise the WMF that making the white-space version opt-in rather than (sometimes) opt-out would greatly improve acceptance of the new skin, but our words fell on stubborn ears, unfortunately. As a result, we get lots of drama instead of a few fun, geeky conversations about how to tweak tools and menus to make them compatible with the new skin. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 01:11, 20 January 2023 (UTC) |
|||
:::::Yes, asking for input for every minor change would be needlessly bothersome - but changing the default skin for the entire site is not a minor change. [[User:WalnutBun|WalnutBun]] ([[User talk:WalnutBun|talk]]) 01:54, 20 January 2023 (UTC) |
|||
*'''Comment''': The complaints about the new Vector are in some ways strikingly similar to [[Wikipedia:User experience feedback/Archive 1|the complaints about the new Vector]]. [[User:Shells-shells|Shells-shells]] ([[User talk:Shells-shells|talk]]) 21:29, 19 January 2023 (UTC) |
|||
**[[Plus ça change]]...<span id="Qwerfjkl:1674164699591:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — [[User:Qwerfjkl|<span style="background:#1d9ffc; color:white; padding:5px; box-shadow:darkgray 2px 2px 2px;">Qwerfjkl</span>]][[User talk:Qwerfjkl|<span style="background:#79c0f2;color:white; padding:2px; box-shadow:darkgray 2px 2px 2px;">talk</span>]] 21:44, 19 January 2023 (UTC)</span> |
|||
** <small>Thanks for the link, that's a fascinating read. A lot of those comments about Vector 2010 are indeed strikingly familiar: "This is a new-Coke Wikipedia"; "the new style is just plain ugly"; "I think there is too much white space"; "WP has made the mistake of starting to follow website fashions"; "I'm exceptionally unhappy at being forced to log in"; "I will no longer be using Wikipedia"; "Will consider boycotting Wikipedia from now on"; "NEW FORMAT IS TERRIBLE. I'LL QUIT WIKIPEDIA!!" I have to wonder how many of the same people are complaining this time around. [[User:Sojourner in the earth|Sojourner in the earth]] ([[User talk:Sojourner in the earth|talk]]) 23:23, 19 January 2023 (UTC)</small> |
|||
*:{{U|Shells-shells}}, it's like being a 17-year-old high school student again, accidentally sent <s>30</s> 13 years into the past in [[Doc Brown Saves the World|Doc Brown's]] time-traveling DeLorean. Thanks for the link. — '''[[User:WildStar|<span style="color:#000000">W<small>ILD</small>S<small>TAR</small></span>]]'''<sup>''[[User talk:WildStar|<span style="color:#808080"><small>TALK</small></span>]]''</sup> 04:36, 20 January 2023 (UTC) |
|||
*:❤️🔥 <span style="color:#666">– [[User:Sj|SJ]][[User Talk:Sj|<span style="color:#f90;"> +</span>]]</span> 05:35, 20 January 2023 (UTC) |
|||
*:@[[User:Shells-shells|Shells-shells]]I got confused by this for a moment, pretty sure you mean {{tq|the complaints about Vector in 2010}}. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 12:31, 20 January 2023 (UTC) |
|||
*::<small>@[[User:Aaron Liu|Aaron Liu]] I intended to be deliberately ambiguous for rhetorical effect. In both cases the "new Vector" is being complained about, but in 2010 that phrase had a meaning slightly different from what it means now. [[User:Shells-shells|Shells-shells]] ([[User talk:Shells-shells|talk]]) 16:46, 20 January 2023 (UTC)</small> |
|||
*:::Ah, nice [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 16:48, 20 January 2023 (UTC) |
|||
*:Thanks for this link for those of us who weren't around so long ago. The similarities are fascinating and I can't help but think that, much like how all the complaints on those pages seemed to start fizzling out after about a month, [[this too shall pass]]. <span style="color:green">[[User:ThadeusOfNazereth|ThadeusOfNazereth]](he/him)<sup>[[User talk:ThadeusOfNazereth|Talk to Me!]]</sup></span> 20:34, 20 January 2023 (UTC) |
|||
*'''Comment''' Are there statistics available about the number of reverts to the legacy version? <span style="border:1px solid green; padding:0 2px">[[User:The Banner|<span style="color:green">The Banner</span>]] [[User talk:The Banner|<i style="color:maroon">talk</i>]]</span> 21:36, 19 January 2023 (UTC) |
|||
**@[[User:The Banner|The Banner]], 20% in the beta tests (I think).<span id="Qwerfjkl:1674164741303:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — [[User:Qwerfjkl|<span style="background:#1d9ffc; color:white; padding:5px; box-shadow:darkgray 2px 2px 2px;">Qwerfjkl</span>]][[User talk:Qwerfjkl|<span style="background:#79c0f2;color:white; padding:2px; box-shadow:darkgray 2px 2px 2px;">talk</span>]] 21:45, 19 January 2023 (UTC)</span> |
|||
**At [[WP:V22RFC]] we find the statistic: {{tq|On average, 87% of active editors across our pilot wikis (incl. French and Portuguese Wikipedias) continue to use the new skin once they try it.}} This appears roughly in line with the statistics on Vector 2010 when it was first deployed to enwiki: {{tq|The opt-out rate is estimated from [https://diff.wikimedia.org/2010/06/03/new-wikipedia-interface-to-nine-more-languages/ 13% to 22%]}}. [[User:Shells-shells|Shells-shells]] ([[User talk:Shells-shells|talk]]) 21:49, 19 January 2023 (UTC) |
|||
**:Is this stats for editors, or users in general? In particular: does that include accounts created by people who formerly browsed Wikipedia anonymously, and created an account solely to opt-out? [[Special:Contributions/192.157.110.190|192.157.110.190]] ([[User talk:192.157.110.190|talk]]) 02:16, 20 January 2023 (UTC) |
|||
**::I believe it includes all user accounts. There is also a poll for IPs that visited specific pages on this wikipedia at [[mw:Reading/Web/Desktop Improvements/Repository/Sentiment Survey]] [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 02:20, 20 January 2023 (UTC) |
|||
**:Good find, [[User:Shells-shells|Shells-shells]]! However, if I remember correctly, Vector had some button or other way to go back to monobook which made things easier than having to find the option in [[Special:Preferences]]. I remember that years later some WMF staff wondered whether the sizable group of people still using monobook was influenced by this early feature. So the same figure 13 % may have different meaning in the two situations. Other discussions of numbers are at [[Special:Permalink/1134727836#Why_was_the_sentiment_survey_gamed?|Why was the sentiment survey gamed?]], [[mw:Talk:Reading/Web/Desktop_Improvements/Archive4#Impact|Impact]], [[mw:Special:Permalink/5724459#Re:_The_iterative_design_of_the_Vector_interface:_the_case_of_moving_interlingual_links|Re: The iterative design of the Vector interface: the case of moving interlingual links]]. [[User:Nemo_bis|Nemo]] 07:51, 20 January 2023 (UTC) |
|||
:*What about the inverse? Was their ever a period where WMF recorded what percent of editors opted in for the 2022 vector prior to the switch? I would think there's probably a great deal of inertia, in which editors just swing with the default. ~ [[User:HAL333|<span style="background:red; color:white; padding:2px; border:1px solid red;">'''HAL'''</span>]][[User talk:HAL333|<span style="background:black; color:white; padding:2px; border:1px solid red;">'''333'''</span>]] 22:35, 20 January 2023 (UTC) |
|||
*This isn't a minor change at all. Nothing close to previous changes in usability in my opinion. So to sit up and spout platitudes isn't helpful at all. Sorry. |
|||
*:I find several style choices make the new version nigh un-usable, or at the least un-helpful and counter-intuitive. And I'd like to consider myself fairly computer saavy enough to navigate a webpage. I really dislike the moving of the table of contents ('''especially''' for talk pages). I never thought I'd see the day where the focus of a change to Wikipedia was to '''''reduce''''' navigation ability. - <b>[[User:Jc37|jc37]]</b> 21:55, 19 January 2023 (UTC) |
|||
*::@[[User:Jc37|Jc37]], but the point of moving the ToC is to '''''aid''''' navigation ability (as I'm sure is mentioned in the RfC).<span id="Qwerfjkl:1674165670203:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — [[User:Qwerfjkl|<span style="background:#1d9ffc; color:white; padding:5px; box-shadow:darkgray 2px 2px 2px;">Qwerfjkl</span>]][[User talk:Qwerfjkl|<span style="background:#79c0f2;color:white; padding:2px; box-shadow:darkgray 2px 2px 2px;">talk</span>]] 22:01, 19 January 2023 (UTC)</span> |
|||
*:::I am happy to believe that was the intent. But's it's a pretty decent fail in my opinion, if that was the intent. So many of the changes seem to be to hide useability from the user. extra clicks, extra motion. This is not how to encourage people to engage in your website. - <b>[[User:Jc37|jc37]]</b> 22:08, 19 January 2023 (UTC) |
|||
* [[WP:CONEXCEPT]] remains pertinent reading from the first RFC, even if you happen to believe that RFC displayed no consensus for a rollout. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 22:17, 19 January 2023 (UTC) |
|||
*:Yes, but one would hope they would use CONEXCEPT sparingly. I'm not sure that's been the case in the last 2 years. As they say, [https://www.washingtonpost.com/news/volokh-conspiracy/wp/2016/01/27/why-real-world-governments-dont-have-the-consent-of-the-governed-and-why-it-matters/ ultimate power only exists so long as you rarely use it]. — [[User:Shibbolethink|<span style="color: black">Shibboleth</span><span style="color: maroon">ink</span>]] <sup>([[User talk:Shibbolethink|♔]]</sup> <sup>[[Special:Contributions/Shibbolethink|♕]])</sup> 18:07, 20 January 2023 (UTC) |
|||
*'''Comment''' – I'm frustrated that [[WT:VECTOR2022]] was not notified of this RfC. An RfC was already being drafted at [[WT:VECTOR2022#Requests for comment/Reverse deployment of Vector (2022)]] before HAL333 jumped the gun and started the RfC themselves. [[User:InfiniteNexus|InfiniteNexus]] ([[User talk:InfiniteNexus|talk]]) 00:46, 20 January 2023 (UTC) |
|||
*'''Notice''' a post from a WMF account, [[Wikipedia:Village Pump (technical)#Vector 2022 Post-Deployment Update from WMF team]]. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 01:32, 20 January 2023 (UTC) |
|||
*This is a clear case of [[WP:CONEXCEPT]] per [[meta:Limits_to_configuration_changes]]. Anyways, Timeless or bust. [[User:Legoktm|Legoktm]] ([[User talk:Legoktm|talk]]) 07:49, 20 January 2023 (UTC) |
|||
*:@[[User:Legoktm|Legoktm]] The swahili wikipedia already did this. They successfully passed an rfc to revert this because they didn't have the manpower to update help images. And WMF's response was not to immediately deny per your link, their response was to "discuss it". So I think this is an exception to that since the default skin IS being changed. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 12:46, 20 January 2023 (UTC) |
|||
*::@[[User:Aaron Liu|Aaron Liu]]: to clarify, I think this should fall under CONEXCEPT. The WMF has recently decided to hypocritically switch its longstanding stance on this position after most recently using it to deny switching to a volunteer-driven skin, for reasons I've [https://blog.legoktm.com/2023/01/18/wikipedias-new-skin-is-a-sad-opportunity-to-reminisce-what-we-couldve-had-instead.html elaborated elsewhere]. [[User:Legoktm|Legoktm]] ([[User talk:Legoktm|talk]]) 18:48, 20 January 2023 (UTC) |
|||
* Here's what I'd suggest: at least temporarily bring back the old one, and have for a time on the main page at the top (like those "please donate" messages) a message saying "do you think wikipedia should use the new or old skin" (and include a link to the new/old versions). If the majority is new, change to the new version; if the majority want the old version, go with the old version. [[User:BeanieFan11|BeanieFan11]] ([[User talk:BeanieFan11|talk]]) 16:30, 20 January 2023 (UTC) |
|||
*'''Do an A/B test'''. We can simply A/B test Wikipedia with the new skin vs the old skin, and specifically ask readers which skin they prefer in an up-or-down manner. If the answer is the new skin, then it would not make sense to switch back from the new skin. If the answer is the old skin, then it ''would'' make sense to switch back to the old skin. An A/B test should not be challenging to implement whatsoever (just randomly assign 20 of the top-viewed pages of the past week and you should get a good enough sample), so I hope that this information would be clarifying. — <span style="background: linear-gradient(#990000,#660000)">[[User:Red-tailed hawk|<span style="color: white">Red-tailed hawk</span>]] <sub>[[User talk:Red-tailed hawk|<span style="color: white">(nest)</span>]]</sub></span> 17:05, 20 January 2023 (UTC) |
|||
*:There was some sort of survey at [[mw:Reading/Web/Desktop Improvements/Repository/Sentiment Survey]] but the results seem to have been obfuscated by WMF. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 17:07, 20 January 2023 (UTC) |
|||
*::I'm aware of that, which is why I'm asking for a straight up-down A/B test and survey. — <span style="background: linear-gradient(#990000,#660000)">[[User:Red-tailed hawk|<span style="color: white">Red-tailed hawk</span>]] <sub>[[User talk:Red-tailed hawk|<span style="color: white">(nest)</span>]]</sub></span> 18:04, 20 January 2023 (UTC) |
|||
==== Question #2: If Vector 2022 is kept as default, should unlimited text width be the default? ==== |
|||
{{anchor|Question #2: If the new design is kept as the default, then should unlimited text width be the default?}} |
|||
*'''Support''', although I prefer option 1: reverting to the old design. [[User:IWantTheOldInterfaceBack|IWantTheOldInterfaceBack]] ([[User talk:IWantTheOldInterfaceBack|talk]]) 04:25, 20 January 2023 (UTC) |
|||
*'''Support'''. This seems by far the most complained about feature and switching it would make it more similar to how it was before. [[User:Jeremy Jeremus|Jeremy Jeremus]] ([[User talk:Jeremy Jeremus|talk]]) 05:01, 20 January 2023 (UTC) |
|||
*'''Support'''. It seems to be one of the chief complaints about the new skin. —[[User:Tenryuu|<span style="color:#556B2F">Tenryuu 🐲</span>]] ( [[User talk:Tenryuu|💬]] • [[Special:Contributions/Tenryuu|📝]] ) 05:43, 20 January 2023 (UTC) |
|||
*'''Support''' Limited text width looks horrendous in wider screens and distracts from the reading experience. It should be opt-in, not opt-out. [[User:Carpimaps|Carpimaps]] ([[User talk:Carpimaps|talk]]) 06:00, 20 January 2023 (UTC) |
|||
*'''Support''' ~ [[User:HAL333|<span style="background:red; color:white; padding:2px; border:1px solid red;">'''HAL'''</span>]][[User talk:HAL333|<span style="background:black; color:white; padding:2px; border:1px solid red;">'''333'''</span>]] 06:11, 20 January 2023 (UTC) |
|||
*'''Support''', as the excess of white space is the main concern with V22. —''[[User:Facu-el Millo|El Millo]]'' ([[User talk:Facu-el Millo|talk]]) 06:13, 20 January 2023 (UTC) |
|||
*'''Support''', though I would be upset if the other problems with Vector 2022 go unaddressed, particularly the difficulty in navigation and the all-white design. [[User:InfiniteNexus|InfiniteNexus]] ([[User talk:InfiniteNexus|talk]]) 07:00, 20 January 2023 (UTC) |
|||
*'''Support''' main complaint of the readers, though I'd prefer finding a solution for the newly created navigation issues as well. --[[User:Icodense99|Icodense]] ([[User talk:Icodense99|talk]]) 07:04, 20 January 2023 (UTC) |
|||
*'''Very strongly support''' — I designed and composed many tables, over many years, to the then-existing page-width. Some of them still look OK, but others (see [[List of pre-World Series baseball champions]] and [[Demographics of South Africa]]) are impossible to read completely without endless left-to-right scrolling or shrinking the page to 75% of normal. [[User:Shakescene|—— Shakescene]] ([[User talk:Shakescene|talk]]) 07:16, 20 January 2023 (UTC) |
|||
*'''Oppose''', [[WP:ILIKEIT|ILIKEIT]] and it's better for reading according to the research mentioned in the RfC.<span id="Qwerfjkl:1674199154616:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — [[User:Qwerfjkl|<span style="background:#1d9ffc; color:white; padding:5px; box-shadow:darkgray 2px 2px 2px;">Qwerfjkl</span>]][[User talk:Qwerfjkl|<span style="background:#79c0f2;color:white; padding:2px; box-shadow:darkgray 2px 2px 2px;">talk</span>]] 07:19, 20 January 2023 (UTC)</span> |
|||
:*[[WP:ILIKEIT|ILIKEIT]] very much describes the pro-2022 crowd, and on the topic of that "research": [[Lies, damned lies, and statistics]]. ~ [[User:HAL333|<span style="background:red; color:white; padding:2px; border:1px solid red;">'''HAL'''</span>]][[User talk:HAL333|<span style="background:black; color:white; padding:2px; border:1px solid red;">'''333'''</span>]] 07:21, 20 January 2023 (UTC) |
|||
:**@[[User:HAL333|HAL333]], and [[WP:IDONTLIKEIT|IDONTLIKEIT]] describes the anti-V22 crowd.<span id="Qwerfjkl:1674199871309:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — [[User:Qwerfjkl|<span style="background:#1d9ffc; color:white; padding:5px; box-shadow:darkgray 2px 2px 2px;">Qwerfjkl</span>]][[User talk:Qwerfjkl|<span style="background:#79c0f2;color:white; padding:2px; box-shadow:darkgray 2px 2px 2px;">talk</span>]] 07:31, 20 January 2023 (UTC)</span> |
|||
:::*Touché. ~ [[User:HAL333|<span style="background:red; color:white; padding:2px; border:1px solid red;">'''HAL'''</span>]][[User talk:HAL333|<span style="background:black; color:white; padding:2px; border:1px solid red;">'''333'''</span>]] 14:09, 20 January 2023 (UTC) |
|||
:::**You can prove anything with statistics except the truth.<span id="Qwerfjkl:1674250833363:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — [[User:Qwerfjkl|<span style="background:#1d9ffc; color:white; padding:5px; box-shadow:darkgray 2px 2px 2px;">Qwerfjkl</span>]][[User talk:Qwerfjkl|<span style="background:#79c0f2;color:white; padding:2px; box-shadow:darkgray 2px 2px 2px;">talk</span>]] 21:40, 20 January 2023 (UTC)</span> |
|||
*'''Support''' Unbelievable that this wasn't the default to begin with. It's practically unusable without it. [[User:Parabolist|Parabolist]] ([[User talk:Parabolist|talk]]) 07:23, 20 January 2023 (UTC) |
|||
*'''Support''' Clearly the new design has to be reverted but the most egregious design flaw is displaying everything in a thin strip down the middle of the page. The text should... by default... fill the majority of the page. Fixed width blocks of text is so 1990's when screens were only 80 characters wide. [[User:Ikaruseijin|Ikaruseijin]] ([[User talk:Ikaruseijin|talk]]) 07:43, 20 January 2023 (UTC) |
|||
*'''Strong Support''' This new design clearly must be default-reverted, but if it isn't, the massive whitespace drowning out every article is by far the biggest design flaw in this new one. It's hard enough to read the thin strip of text as it is; if the article has pictures (as most articles about notable topics do), it's nearly impossible to coherently follow the flow of the text. |
|||
*'''Strong Oppose''' - There's a button to make it fullscreen if you want (even for IP's) and the width actually makes sense on a widescreen. -- [[User:Sohom data|Sohom Datta]] ([[User talk:Sohom data|talk]]) 08:03, 20 January 2023 (UTC) |
|||
*:No, that button doesn't work for IPs. I just logged out and tested it out. You have to re-click it every single time you load a new page. And it seems that the dev team has no interest in fixing this, even though all it would require is a cookie and a few lines of JavaScript. Furthermore, the button is an instance of [[mystery meat navigation]], and it is small and hidden in a very inconvenient location all the way at the footer of the page, below the bottom of the article. On a wide screen monitor, like on any other monitor, if you want narrower text you can resize your window. The redesign hides that ability for all but patient (have to re-select on every new page load) and competent (find mystery meat button hiding in weird corner) IP users. [[User:IWantTheOldInterfaceBack|IWantTheOldInterfaceBack]] ([[User talk:IWantTheOldInterfaceBack|talk]]) 08:06, 20 January 2023 (UTC) |
|||
*::@[[User:IWantTheOldInterfaceBack|IWantTheOldInterfaceBack]] Is there a phabricator task for the bug that your describing here ? [[User:Sohom data|Sohom Datta]] ([[User talk:Sohom data|talk]]) 08:11, 20 January 2023 (UTC) |
|||
*:::I have no idea what phabricator is. I created this account yesterday to get the old look back. And from what I can tell this is perceived as a "feature", not a bug, since it is allegedly impossible to store a simple cookie and ten lines of javascript for IP users due to "caching issues" or something. [[User:IWantTheOldInterfaceBack|IWantTheOldInterfaceBack]] ([[User talk:IWantTheOldInterfaceBack|talk]]) 08:13, 20 January 2023 (UTC) |
|||
*::::Right, sorry about that, but phabricator is where you report to developers if you have a issue with the Wikipedia interface ([https://phabricator.wikimedia.org/maniphest/task/edit/form/43/ link to bug reporting teplate]). Once it's on Phabricator, engineers can follow up and solve the issue at hand (much like issues of Github etc). |
|||
*::::Also, whatever you mentioned about "caching issues" is unfortunately probably a fairly valid explanation, since the solution using ten lines of Javascript is going cause a FOUC (flash of unstyled content) where the layout changes after it has been rendered (leading people to believe that the site is slow/sluggish etc). To do this properly, you need some kind of server-side mechanism to figure out which layout the user wants before each and every page is rendered, which imo is slightly difficult when your having to do for one of the world's most popular sites :( [[User:Sohom data|Sohom Datta]] ([[User talk:Sohom data|talk]]) 08:26, 20 January 2023 (UTC) |
|||
*:::::For context, currently we just have one version of a page which are cached in [https://wikitech.wikimedia.org/wiki/Varnish Varnish servers] which is then served to everyone (with the cache being refreshed periodically), which is a lot less server intensive. -- [[User:Sohom data|Sohom Datta]] ([[User talk:Sohom data|talk]]) 08:30, 20 January 2023 (UTC) |
|||
*:As a wide screen user I would say the width actually makes no sense on a widescreen. As any other widescreen user, anyone, who wants to keep less info on the screen can use multi-window layout or narrow their window. There is no reason to force users. This is wikipedian, not facebook. [[Special:Contributions/193.239.57.118|193.239.57.118]] ([[User talk:193.239.57.118|talk]]) 16:31, 20 January 2023 (UTC) |
|||
*'''Support''' I've just spend 15 minutes to use an account I've almost never used to try to understand why this limited width is enforced. On a 16:10, 32 inch screen, wikipedia is two mini columns barely readable embedded in a white page. The full screen button is a joke, as soon as you change from a page to a new one, it resets to the limited width. Only after login in and setting my preferences to full width, it becomes usable. You cannot seriously think that all wikipedia users will create an account and login in right? You may have another kind of problems if we would all do so. For the rest about vector 2, I am not well enough into editing to complain. But clearly, the designers knew the problem of the limited width and of the folded left menu, otherwise they would not have added a button to unfold the menu and another one to extend the width. The major bug is that the status of these buttons are not cached and are reset at each clicks. Please, fixed that urgently. It is pretty clear that most of the complains are only due to this, mine included. What an oversight!!! <!-- Template:Unsigned --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Eatdirt|Eatdirt]] ([[User talk:Eatdirt#top|talk]] • [[Special:Contributions/Eatdirt|contribs]]) </small> |
|||
*'''Agree'''. I think this is a good compromise, especially for such a drastic change. I think there should be a button that allows the user to enable "reading mode", which removes the clutters and present content in a fixed width. [[User:CactiStaccingCrane|CactiStaccingCrane]] 08:38, 20 January 2023 (UTC) |
|||
*:Most browsers have that built in these days. Nobody has to bother reimplementing it. [[User:3mi1y|<span style="display:inline-block;transform:scale(-1,1)rotate(-30deg);">ℰ</span>''mi1y'']]<sub style="color:#b766d2;">⧼[[User talk:3mi1y|T]]·[[Special:Contributions/3mi1y|C]]⧽</sub> 08:45, 20 January 2023 (UTC) |
|||
*::...and the ability to reduce window width has been built in since the dawn of graphical operating systems.–[[User:SmallJarsWithGreenLabels|small jars]] <small><code>[[User talk:SmallJarsWithGreenLabels|<b style="color:#270">t</b>]][[special:contributions/SmallJarsWithGreenLabels|<b style="color:#270">c</b>]]</code></small> 17:38, 20 January 2023 (UTC) |
|||
*'''Strong Support''' I switched my vote in the original RFC from oppose to neutral because it sounded like the width thing was going to be solved. It sounds like it was solved poorly. [[User:3mi1y|<span style="display:inline-block;transform:scale(-1,1)rotate(-30deg);">ℰ</span>''mi1y'']]<sub style="color:#b766d2;">⧼[[User talk:3mi1y|T]]·[[Special:Contributions/3mi1y|C]]⧽</sub> 08:42, 20 January 2023 (UTC) |
|||
*{{edit conflict}} '''Oppose'''. Fixed-width layout is a pretty common way of formatting articles on the Internet these days. For example, almost all common news websites use it to format their articles, e.g. [https://www.nytimes.com/ ''The New York Times''], [https://www.wsj.com/ ''The Wall Street Journal'']. Think about how much whitespace there is looking at a Google search result page on a large monitor—theoretically Google could fill up the entire page with text, but the fixed-width layout centralizes things and makes it more readable. A similar concept is applicable to Wikipedia. I'm sure it looks a bit wonky for us editors who have been using the old style for decades, but in reality, the fixed-width layout is not the unambiguously detrimental feature that others are making it out to be. [[User:Mz7|Mz7]] ([[User talk:Mz7|talk]]) 08:46, 20 January 2023 (UTC) |
|||
*'''Oppose'''. Crowd-sourcing encyclopaedia articles is a fantastic idea. Crowd-sourcing web design... not so much. Leave it to the professionals. – [[User:Joe Roe|Joe]] <small>([[User talk:Joe Roe|talk]])</small> 09:25, 20 January 2023 (UTC) |
|||
*'''Support''' Limited-width ''text'' is good, but this should be limited to ''text''. Instead, the new skin limits the width of everything, putting infoboxes, images, tables and other non-text items into the same narrow strip of content, with white all around. Either we redesign the website to put non-text items on the empty sides, or limited-width doesn't make any sense. By the way, I would support a '''real''' redesign which would move infoboxes, images etc. on the sides and limit the ''text'' width. --[[User:Ita140188|Ita140188]] ([[User talk:Ita140188|talk]]) 09:46, 20 January 2023 (UTC) |
|||
*'''Strong oppose'''. Regarless of vocal pushback, ''limited content width'' has been widely upheld as a fundamentally good design principle across the entire field of UI design for more than a decade. It's great for accessibility among other reasons. Practically every website has a width limit. Apple.com does. NYTimes.com does. WashingtonPost.com does. Google.com does! Only UI designers are qualified to objectively evaluate the merits of this; the rest of us are just expressing resistance to change. I used to hate the limited width too, but now I like it. |
|||
:The idea that the limited width breaks tables, or that these tables now require scrolling, is also simply false. The tables are not affected by the limited width, and will take up the whole width of the user's web browser. |
|||
:As is, I don't believe this question could lead to a binding consensus; <s>this needs to be based on surveys of non-logged in users, which the WMF should go out of its way to conduct, in order to reassure detractors.</s> edit: Nope, I'm satisfied with the surveys which were already conducted. [[User:DFlhb|DFlhb]] ([[User talk:DFlhb|talk]]) 10:00, 20 January 2023 (UTC) |
|||
::{{tq|Only UI designers are qualified to objectively evaluate the merits of this}} Only artists can critique art, only game developers can critique games, movie directors can critique movies, writers can critique books, and so on. The general user who has to experience that has no say at all? Apple is only limited width for a section, google uses full width at 1080p when you search(and their email is always full width), nyt and wapo uses much more as well. Wikipedia is the most constricted version of any I have encountered, and has no mechanisms for using that extra space either, even fandom will fill the voids at the edges with wiki-art and ads. At ratios higher than 16:9 1080p, it becomes a tiny island in a sea of blindingly bright whitespace, with a practically invisible toggle that doesn't even work when logged out nestled in the corner of all that whitespace. [[User:Deadoon|Deadoon]] ([[User talk:Deadoon|talk]]) 11:45, 20 January 2023 (UTC) |
|||
:::Contrary to what you say, every page I list rigidly limits page width for ''contents'' (not other page elements). And yes, non-designers can claim to speak objectively ("this is worse!"), but what they always mean is simply "I don't like it". Interface design is objective, and has nothing to do with personal tastes, yet the entirety of the opposition to the redesign rests on personal taste and preference. [[User:DFlhb|DFlhb]] ([[User talk:DFlhb|talk]]) 14:44, 20 January 2023 (UTC) |
|||
::::The enjoyment of the design is subjective, claiming objectivity in matters of opinion and subjective matters is the most disingenuous thing you can do. In your opinion the design should only be evaluated by people with a some nebulous qualifications and everyone else should be thrown in the trash and ignored because apparently the general public doesn't matter. Great "opinion" you have there. I guess third part developers will love all the new traffic they get to their [https://chrome.google.com/webstore/detail/revert-wikipedia-layout/jpnfgjjnmghhkgffigedilglfkpcjlda?hl=en addons], [https://gist.github.com/Vusys/a9451ee719e27a4eb1fc05dcb2e60588 scripts], and [https://www.reddit.com/r/wikipedia/comments/10fgb35/how_do_you_get_the_old_layout_back/ other] [[Wikipedia talk:Vector 2022#Use 2010 Vector as an IP|tutorials]] on how fix this problem, afterall that is what is leading many people here, [[phab:T327440#8542723|a near doubling of user accounts created]], looking for solutions to a problem that didn't exist a few days ago. [[User:Deadoon|Deadoon]] ([[User talk:Deadoon|talk]]) 15:03, 20 January 2023 (UTC) |
|||
::Wrong. Users can limit the width at the browser level if they are some weirdo who doesn't want their widescreen monitor to actually output widescreen content. There is zero justification for this enforced low-information default. It's terrible design. My desktop is not a phone. Stop treating it like one [[Special:Contributions/2600:1700:1471:2550:4102:7C99:2804:8FC3|2600:1700:1471:2550:4102:7C99:2804:8FC3]] ([[User talk:2600:1700:1471:2550:4102:7C99:2804:8FC3|talk]]) 15:26, 20 January 2023 (UTC) |
|||
:::For reference, WMF's response to that argument in the FAQ is {{tq|Most users don't resize their browser windows or use browser plugins to improve the design of the websites they view. Wikis should be good-looking immediately, in their basic form.}} [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 15:31, 20 January 2023 (UTC) |
|||
:*In most cases, limited content width is used, not to improve reader experience, but to fill the periphery with commercials. I fear that with Wikipedia—one of the last bastions of uncommercialized space on the web—adopting this format, they will soon follow suit and cram it with ads. ~ [[User:HAL333|<span style="background:red; color:white; padding:2px; border:1px solid red;">'''HAL'''</span>]][[User talk:HAL333|<span style="background:black; color:white; padding:2px; border:1px solid red;">'''333'''</span>]] 16:04, 20 January 2023 (UTC) |
|||
:**@[[User:HAL333|HAL333]], I think one result of [[Wikipedia:Fundraising/2022 banners]] was that there won't be ads in the foreseeable future.<span id="Qwerfjkl:1674251420044:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — [[User:Qwerfjkl|<span style="background:#1d9ffc; color:white; padding:5px; box-shadow:darkgray 2px 2px 2px;">Qwerfjkl</span>]][[User talk:Qwerfjkl|<span style="background:#79c0f2;color:white; padding:2px; box-shadow:darkgray 2px 2px 2px;">talk</span>]] 21:50, 20 January 2023 (UTC)</span> |
|||
:::*Good. That's comforting. ~ [[User:HAL333|<span style="background:red; color:white; padding:2px; border:1px solid red;">'''HAL'''</span>]][[User talk:HAL333|<span style="background:black; color:white; padding:2px; border:1px solid red;">'''333'''</span>]] 22:36, 20 January 2023 (UTC) |
|||
*'''Strong oppose''' — It’s easily the best part of the new design, and just good design sense. [[User:MarijnFlorence|MarijnFlorence]] ([[User talk:MarijnFlorence|talk]]) 11:32, 20 January 2023 (UTC) |
|||
*'''Support''' The whitespace problem is a distraction. Narrow content space is fine on vertical-oriented phones, where the phone doesn't have whitespace on the sides. In a horizontally oriented monitor, it's fundamentally a waste of resources to leave so much of the screen unusable. By leaving the width to float to the maximum width of the device, it conforms naturally to the user's own setup in a way that is most useful. If users wish to increase their own whitespace for their own preferences, let them... The default should be to fit each device best, not force a one-size-fits-all design onto a multitude of devices for which it is not well suited. It's also my only real complaint about the new Vector skin. I actually like many of the design and functionality choices, and would return to using it if the screen width problem was fixed.--[[User:Jayron32|<span style="color:#009">Jayron</span>]][[User talk:Jayron32|<b style="color:#090">''32''</b>]] 12:11, 20 January 2023 (UTC) |
|||
*'''Support''' Would solve a few of the primary issues I have with the design. The whitespace replaced with functional content, and the toggle between no longer being extremely isolated giving it some semblance of contrast. Even with the black on white design, text alone is more than enough to break up the blinding nature of the background and make it less painful to look at on high contrast displays, compared to the extremely pale gray of the standard whitespace. Although it would be less able to utilize the space provided, considering the toggle takes up it's own unique margin, and itself doesn't compress when expanded.[[User:Deadoon|Deadoon]] ([[User talk:Deadoon|talk]]) 12:19, 20 January 2023 (UTC) |
|||
*'''Strong support'''. The excessive white space is literally the only problem I have with the new skin. [[User:Endianer|Endianer]] ([[User talk:Endianer|talk]]) 12:32, 20 January 2023 (UTC) |
|||
*'''Support, at least temporarily''' Though I personally dislike the new aesthetic, and agree with the sentiment of not fixing what isn't broken, I recognise that part of why I may feel that way is likely influenced by me just being used to Vector 2010. But there are some aspects of the redesign that really bug me outside of the aesthetic and the big white space. For example: why is '''create account''' always visible on logged out screens but '''log in''' is hidden behind a menu? My issues with this redesign include the aesthetic, but also the functional. I don't think it works the way it is.[[User:Xx78900|Xx78900]] ([[User talk:Xx78900|talk]]) 12:38, 20 January 2023 (UTC) |
|||
*'''Support''' This is the basis of almost all complaints I've seen from end users about Vector 2022, and the reason I opposed it in the initial RfC. We sort of accepted that we as editors weren't the intended audience for the limited width and that this was something that would work for end users, but that does not appear to be the case. [[User:JackWilfred|JackWilfred]] ([[User talk:JackWilfred|talk]]) 12:39, 20 January 2023 (UTC) |
|||
*'''Support''' Definitely. The excess white space is one of the biggest (if not the biggest) problems with the new design. The toggle button isn't consistent, and casual readers shouldn't have to be forced to create an account just to disable the option in the Preferences. Limited width should be opt-in, not opt-out IMO. [[User:Some1|Some1]] ([[User talk:Some1|talk]]) 12:59, 20 January 2023 (UTC) |
|||
<strike>*'''Support''' I think the foundation have their approach entirely backward. They've made the change and are waiting to see how many people hate it enough to revert back to the previous skin; this is an incredibly low bar for classing the change as a 'good idea.' I propose that they revert the default to the previous design, advertise the new skin, and measure what proportion of people like it enough to change to the 'new' skin voluntarily [[User talk:JeffUK|Jeff<span style="border-style:dashed;border-color:blue; border-width:1px">'''UK'''</span>]] 13:46, 20 January 2023 (UTC)</strike> |
|||
*:@[[User:JeffUK|JeffUK]]: Notice that this Question #2 is specifically about the width problem. Was your vote/comment intended for the general RfC (above) about the restoration of Vector 2010 as the default interface? [[User:Æo|Æo]] ([[User talk:Æo|talk]]) 14:38, 20 January 2023 (UTC) |
|||
*::Ack, it was. I blame the new layout! Thanks. [[User talk:JeffUK|Jeff<span style="border-style:dashed;border-color:blue; border-width:1px">'''UK'''</span>]] 15:08, 20 January 2023 (UTC) |
|||
*'''Support'''.--[[User:Æo|Æo]] ([[User talk:Æo|talk]]) 14:24, 20 January 2023 (UTC) |
|||
*'''Support''' Too much white space, too hard to navigate, the previous 2010 design was simpler, more manageable on a wider variety of displays, rather than this newer version which looks like a poor mobile-display conversion. Also, so many people have written about it in the Teahouse, unsurprisingly, but only actual users with accounts can opt-out, that's clearly a bad idea. My first instinct upon seeing the new design was to turn it off. [[User:ButterCashier|ButterCashier]] ([[User talk:ButterCashier|talk]]) 14:35, 20 January 2023 (UTC) |
|||
*'''Sub-rfc void''' - Considering the low participation I expect this sub-rfc to get, I don't see how any consensus here should or could affect the site-wide skin features. While I see how the community can vote on if the skin becomes the default or not, I remain unconvinced that the community should or could vote on specific features like this, especially (IIRC) the option to ''toggle'' the particular feature is possible. — [[User:Ixtal|Ixtal]] <sup>( [[User talk:Ixtal|T]] / [[Special:Contributions/Ixtal|C]] ) </sup> ⁂ <small> [[Non nobis solum]]. </small> 14:39, 20 January 2023 (UTC) |
|||
*:Also notice that this sub-RfC seems to be creating confusion in some users, who are voting here thinking that it is the main RfC. [[User:Æo|Æo]] ([[User talk:Æo|talk]]) 14:43, 20 January 2023 (UTC) |
|||
*:Correction: {{tq|could vote}} -> could vote in a way that is binding. And if it is not, as that is the de facto state of the large rfc, there is no reason for this to 'double up' a previous, wider consensus. — [[User:Ixtal|Ixtal]] <sup>( [[User talk:Ixtal|T]] / [[Special:Contributions/Ixtal|C]] ) </sup> ⁂ <small> [[Non nobis solum]]. </small> 14:44, 20 January 2023 (UTC) |
|||
*:If you're not logged in, the toggle must be pressed on every single page, every single time you come here. For the vast majority who read Wikipedia without registering an account, it may as well not be there for all the good it does. --[[User:Kizor|Kiz]][[Special:Contributions/Kizor|<span style="color:black;">o</span>]][[User_talk:Kizor|<span style="color:green;">r</span>]] 15:12, 20 January 2023 (UTC) |
|||
*::{{u|Kizor}}, I understand, but how does that affect the relationship between this RfC and the previous one? — [[User:Ixtal|Ixtal]] <sup>( [[User talk:Ixtal|T]] / [[Special:Contributions/Ixtal|C]] ) </sup> ⁂ <small> [[Non nobis solum]]. </small> 16:05, 20 January 2023 (UTC) |
|||
*:This is a [[WP:CENT]]-listed request for Comment. This question is neutral and brief, and I see no reason why the RfC is anything other than valid. — <span style="background: linear-gradient(#990000,#660000)">[[User:Red-tailed hawk|<span style="color: white">Red-tailed hawk</span>]] <sub>[[User talk:Red-tailed hawk|<span style="color: white">(nest)</span>]]</sub></span> 18:05, 20 January 2023 (UTC) |
|||
*:Ixtal: Please don't poison the well by declaring the RFC "low participation" when it's only a few hours old. I will note that at my count, in less than a day, we've had over 50 comments. Don't know if the rates are going to decrease or not over the next few days, but even accounting for gradual slowdowns in participation, we're still likely to hit [[WP:200]] or [[WP:300]] levels in a week or so; that's pretty much the definition of a "High participation" RFC. I mean, vote how you want to vote, but don't tell everyone who hasn't voted yet "Don't bother, your vote doesn't matter". That's rude and uncalled for. Let people make up their own minds what they think, and don't try to nullify their opinions before they even give them. --[[User:Jayron32|<span style="color:#009">Jayron</span>]][[User talk:Jayron32|<b style="color:#090">''32''</b>]] 19:40, 20 January 2023 (UTC) |
|||
*'''Oppose'''. First of all I don't think this RfC can or should be binding since this change overwhelmingly affects non-editors who will not participate here. That being said there's a lot of evidence that limiting the line length improves readability. If you prefer full width, there's a button to toggle that. My only complaint is that the full-width preference doesn't persist between pages and on reload for IP users. Surely that preference should be stored in a cookie or something. – [[user talk:Anne drew Andrew and Drew|<span style="color:#074">Anne drew</span>]] 14:41, 20 January 2023 (UTC) |
|||
*:I'm echoing my comments in question one above. I've seen a lot of references to the evidence that limited line length improves readability, but I can't actually find any of the papers being cited in the documentation for the new design (Lin 2004 and a Wichita State lab study were both cited by outbound links). Do you happen to have that evidence or can point me toward it? [[User:Guidethebored|Guidethebored]] ([[User talk:Guidethebored|talk]]) 15:15, 20 January 2023 (UTC) |
|||
*::[https://web.archive.org/web/20200523221337/https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.556.404&rep=rep1&type=pdf Reading Online text 2004] [https://www.researchgate.net/publication/252707646_The_Effects_of_Line_Length_on_Children_and_Adults'_Online_Reading_Performance Wichita State] [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 15:30, 20 January 2023 (UTC) |
|||
*:::Thank you very much! [[User:Guidethebored|Guidethebored]] ([[User talk:Guidethebored|talk]]) 15:39, 20 January 2023 (UTC) |
|||
*:Hi @[[User:Anne drew Andrew and Drew|Anne drew Andrew and Drew]] - we're working showing the toggle at lower widths right now (expected to roll out next width) and investigating what progress we can make on persistence, see our [[Wikipedia:Village pump (proposals)#Vector 2022 Post-Deployment Update from WMF Team|update below]] for more info. [[User:OVasileva (WMF)|OVasileva (WMF)]] ([[User talk:OVasileva (WMF)|talk]]) 16:44, 20 January 2023 (UTC) |
|||
*:{{tq|1=If you prefer full width, there's a button to toggle that.}}<br>Why not have a toggle for restricted width? — [[User:Shibbolethink|<span style="color: black">Shibboleth</span><span style="color: maroon">ink</span>]] <sup>([[User talk:Shibbolethink|♔]]</sup> <sup>[[Special:Contributions/Shibbolethink|♕]])</sup> 17:58, 20 January 2023 (UTC) |
|||
*'''Oppose''', line length has been limited for centuries. Data&science based decisions, anyone? [[User:Ponor|Ponor]] ([[User talk:Ponor|talk]]) 14:56, 20 January 2023 (UTC) |
|||
*'''Support''' as an IP reader and editor, while no better solution found and implemented. [[Special:Contributions/37.134.90.176|37.134.90.176]] ([[User talk:37.134.90.176|talk]]) 15:05, 20 January 2023 (UTC) |
|||
*'''Unsure''' on one hand this is the biggest complaint and the button doesn't persist, on the other hand this is the entire point of including this as the default and as a fact it is better looking. I'm not sure what to say on this. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 15:34, 20 January 2023 (UTC) |
|||
*'''Strong support''', because the line width shows a fundamental misunderstanding of how I (and, I believe, many others) use Wikipedia. I am usually an early adopter of new interfaces. The sidebar TOC here is an improvement, in my opinion (even though it's still buggy). The width is not. I'm a lawyer in my day job, and lawyers (especially appellate lawyers) are heavily invested in making their briefs easier to read and understand. (Have you ever been on #AppellateTwitter? It's a trip.) I am intimately familiar with white space. My briefs use low-density fonts, are left-aligned rather than fully justified, don't use blockquotes or ALLCAPS headings or unnecessary defined terms or acronyms, and so on. These have been daily considerations for me in my professional life. What I've come to realize over the last few days, though, is that I don't read Wikipedia in the same way or for the same purpose that I read a legal brief or judicial opinion (or a novel). I almost exclusively *scan* Wikipedia. High information density is very important to me here; it's a feature, not a bug. I want the maximum possible amount of information on my screen when I am doing the kind of reading I am doing on Wikipedia. I want to be able to see the nearby headings for context (which, again, is a mark in favor of the sidebar TOC). The width works against all of that *for the type of reading I come to Wikipedia to do*. Here's a simile that may help illustrate the issue. Reading is like eating. There are lots of different reasons I eat. Sometimes I eat to fill my belly; sometimes I eat to fuel myself for a hike or river paddle; sometimes I eat for pleasure. I eat differently in all those situations (respectively: more high-calorie-density and protein-rich foods to fuel a hike; mainly low-calorie-density, high-fiber foods like vegetables for everyday living; sugary sweets and confections for pleasure). I read for different reasons too, and *why* I'm reading matters to *what* and *how* I'm reading. The change in width is like forcing me to eat celery when I need to be carbo loading. So while I absolutely understand "giving the reader a break" and "slowing down the firehose of information" from most documents, I'm understanding now that it just doesn't make sense for this site. [[User:Jeffreynye|Jeffreynye]] ([[User talk:Jeffreynye|talk]]) 15:37, 20 January 2023 (UTC) |
|||
*:Hear, hear! I come here specifically FOR the "firehose of information". If I want a break, I close the browser. I really don't appreciate having these self-appointed efficiency experts hobble the reading experience because they believe they know what I'm looking for better than I do myself. It's analogous to the information problem of top-down economies in a different form. [[User:IWantTheOldInterfaceBack|IWantTheOldInterfaceBack]] ([[User talk:IWantTheOldInterfaceBack|talk]]) 15:42, 20 January 2023 (UTC) |
|||
* '''Support''' - The white space problem is significantly disruptive to my editing experience. [[User:Netherzone|Netherzone]] ([[User talk:Netherzone|talk]]) 15:49, 20 January 2023 (UTC) |
|||
*'''Support''' My biggest gripe with the new skin, and why I'm using the legacy version. [[User:AirshipJungleman29|~~ AirshipJungleman29]] ([[User talk:AirshipJungleman29|talk]]) 15:55, 20 January 2023 (UTC) |
|||
*'''Support''' I went to dig up my old account for this, because I do not approve of this change. Of the changes, I don't particularly mind the decision to add the ToC to the side, but the huge amount of whitespace is horrible for my experience reading articles, and makes it feel like I'm using a mobile website. If that was changed, I think the new Vector would be a much more acceptable design. [[User:SkyAmp6|SkyAmp6]] ([[User talk:SkyAmp6|talk]]) 16:01, 20 January 2023 (UTC) |
|||
*'''Support''' This would fix one of the bigguest problems with it. The other being hiding and burying some of the most heavily used menu items. <b style="color: #0000cc;">''North8000''</b> ([[User talk:North8000#top|talk]]) 16:04, 20 January 2023 (UTC) |
|||
*'''Support'''–Constriction is not a feature.[[User:SmallJarsWithGreenLabels|small jars]] <small><code>[[User talk:SmallJarsWithGreenLabels|<b style="color:#270">t</b>]][[special:contributions/SmallJarsWithGreenLabels|<b style="color:#270">c</b>]]</code></small> 16:20, 20 January 2023 (UTC) |
|||
*'''Support.''' Establishing unlimited text width as the default would resolve what is, in my opinion, the primary problem with the moment-to-moment user experience of Vector 2022. See also Jeffreynye's thorough and eloquent explanation of why unlimited text width is particularly suitable for the Wikipedia environment, as opposed to that of other text-focused websites. [[User:ModernDayTrilobite|ModernDayTrilobite]] ([[User talk:ModernDayTrilobite|talk]] • [[Special:Contributions/ModernDayTrilobite|contribs]]) 16:43, 20 January 2023 (UTC) |
|||
*'''Support'''. This is the single biggest gripe with the new skin, and it is something that the majority of editors wanted at the RfC that was held on whether or not to move to new vector. If this cannot be achived upstream in the skin itself due to a lack of willingness by the WMF, we can simply use common.css to keep this fixed for everyone until switching the default in the code (something that is technically trivial to do, by the way) is implemented. — <span style="background: linear-gradient(#990000,#660000)">[[User:Red-tailed hawk|<span style="color: white">Red-tailed hawk</span>]] <sub>[[User talk:Red-tailed hawk|<span style="color: white">(nest)</span>]]</sub></span> 17:01, 20 January 2023 (UTC) |
|||
*'''Support'''. Anonymous readers do not have a way to set a preference for wide-screen viewing, and the limited width was by far the primary objection in the rollout RFC (read through the oppose votes, and you'll see that 90+% of those who cited a specific problem state that the width is a problem). The previous RFC would have sailed through as "support" if the width problems had been resolved, and the limited width continues to be the primary objection among post-rollout commenters. All of the incompatibility with tools and scripts for us power users can be resolved. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 17:12, 20 January 2023 (UTC) |
|||
*'''Support'''. This is the #1 reason why Vector 2022 is bad. Restricting width like this uses so little screen space at the expense of any customizability in width to the user. If anything, it should be default expanded width and then a toggle button for restricted width. I see no quality evidence that this improves readability beyond the cherry-picking provided by WMF. — [[User:Shibbolethink|<span style="color: black">Shibboleth</span><span style="color: maroon">ink</span>]] <sup>([[User talk:Shibbolethink|♔]]</sup> <sup>[[Special:Contributions/Shibbolethink|♕]])</sup> 17:59, 20 January 2023 (UTC) |
|||
*'''Support'''. Even after pressing the button, it's still too narrow for my taste. There's nearly an inch of white space to the left of the text and about half an inch to the right. Just give us widescreen, get rid of the button, and let the small minority of users that want a restrictive narrow column find it in the settings. Fix these issues and I'd accept Vector 2022 as the default. [[User:Thebiguglyalien|Thebiguglyalien]] ([[User talk:Thebiguglyalien|talk]]) 18:28, 20 January 2023 (UTC) |
|||
*'''Oppose''' – Fixed width is actually the main part of the new skin that I prefer over the old one (and the sole reason I started using it before its official deployment). IMO this would just make it a worse version of the old skin, with the lack of visual borders between the content, TOC, header, and everything else; just a sea of white. I do agree that the non-persistence of the width toggle is annoying. –'''[[User:Sonicwave32|<span style="color:green;">Sonicwave</span>]] <small><sup>[[User talk:Sonicwave32|<span style="color:#008FB2">talk</span>]]</sup></small>''' 18:30, 20 January 2023 (UTC) |
|||
* '''Oppose''' based on research and rationales behind the change in the first place. — '''[[user:fourthords|<span style="color:#CC0000">Fourthords</span>]] | [[user talk:fourthords|=Λ=]] |''' 22:07, 20 January 2023 (UTC) |
|||
*'''Support''', per Jeffreynye's comment above. There are some things I personally don't like about V22, some things I do like, and also some things I just love. But I'm not !voting based on that, nor should anyone: since any registered user can revert to legacy vector, this RfC should be '''about unregistered users' experience only'''. But this involves more: registered users should also switch to whatever skin unregistered users have every time they are working on the lay-out of articles, and the width that unregistered users will get to see is in fact of fundamental importance for all our future lay-out decisions.{{pb}}Now while I appreciate the [[mw:Reading/Web/Desktop_Improvements/Features/Limiting_content_width#Research|research cited]] by the web team showing that limited line width is beneficial for reading comprehension, I am not entirely convinced that this research can simply be generalized to every type of application. Contrary to the websites which are often cited as examples of big players who use limited width, we are an ''encyclopedia''. The type of information we offer is fundamentally different from what is usually offered on the web. I believe that it may be the case that encyclopedic content heavily benefits from text density, because people who are looking for a specific piece of information will want to scan a lot of text at once, and because all readers will have a strong need to orient themselves within the structure of the text (which is benefited by seeing as much as possible of the section headings and other structural elements, as well as of the info in other parts of the text).{{pb}}This is not based on any research, but on my long-term (+10 years) and heavy use of Wikipedia for research purposes. Still, I think that contrary to the non-specific research on the benefits of limited line width, my experience ''may'' be generalized: people do primarily use Wikipedia to do research, whether it be scholarly research like me or just 'looking things up'. It is my belief that the limited width will be detrimental to that 'looking up'. At the very least, I would like to see research that is specific to Wikipedia or encyclopedic text in general before moving to the limited width lay-out. <span style="text-shadow:#000 0em 0em 1em">☿ [[User:Apaugasma|<span style="color:#6a0dad">Apaugasma</span>]] ([[User talk:Apaugasma|<span style="color:#000">talk</span>]] [[Special:Contributions/Apaugasma|☉]])</span> 22:35, 20 January 2023 (UTC) |
|||
*'''Comment'''—What about allowing readers (logged-in or otherwise) the option of toggling wide text on and off? [[User:Kurtis|Kurtis]] [[User talk:Kurtis|<sup>(talk)</sup>]] 00:05, 21 January 2023 (UTC) |
|||
*:They can (by clicking the 'full screen' button at the bottom to the right), though it doesn't persist across pages. This persistence is something the web team has said they are willing to work on. However, when editing we need to base our lay-out on one of the two views, and the large majority of unregistered readers will see the default view most of the time. Customization options are always only used by a minority. This makes determining what the default view should be a crucial decision. <span style="text-shadow:#000 0em 0em 1em">☿ [[User:Apaugasma|<span style="color:#6a0dad">Apaugasma</span>]] ([[User talk:Apaugasma|<span style="color:#000">talk</span>]] [[Special:Contributions/Apaugasma|☉]])</span> 00:17, 21 January 2023 (UTC) |
|||
*'''Support''', graphs tend to be too small. Sometimes, you can hardly read what is written on the axis. There is not enough space to have graphs, which are large enough. One can click on the graph to view it without problems. So, now we have too small graphs combined with wasted space. That does not make any sense. --[[User:Boehm|Boehm]] ([[User talk:Boehm|talk]]) 00:24, 21 January 2023 (UTC) |
|||
* '''Oppose'''... but to be honest I never liked the unlimited width, it's unique to wikipedia in, like, a bad way [[User:DecrepitlyOnward|DecrepitlyOnward]] ([[User talk:DecrepitlyOnward|talk]]) 00:31, 21 January 2023 (UTC) |
|||
====Link to the research about limited line width==== |
|||
[[mw:Reading/Web/Desktop Improvements/Features/Limiting content width#Research]] |
|||
Although I personally believe that this research may not be specific enough for encyclopedic text-types and that the way Wikipedia is used by most readers may actually suffer from limiting line width (see my !vote above), I would of course be happy to be shown wrong, and in general !voters in Question 2 may want to read up on this research. <span style="text-shadow:#000 0em 0em 1em">☿ [[User:Apaugasma|<span style="color:#6a0dad">Apaugasma</span>]] ([[User talk:Apaugasma|<span style="color:#000">talk</span>]] [[Special:Contributions/Apaugasma|☉]])</span> 22:47, 20 January 2023 (UTC) |
|||
====Publicizing this RfC==== |
|||
I've notified [[Wikipedia talk:Vector 2022]], [[Wikipedia:Village pump (policy)]], [[Wikipedia:Village pump (technical)]], and [[Wikipedia:Village pump (WMF)]], but most users do not watch those pages. How can this RfC be publicized to as many users as possible? I'm thinking [[WP:MMS|mass messages]] to all active Wikipidia users, is that feasible? [[User:InfiniteNexus|InfiniteNexus]] ([[User talk:InfiniteNexus|talk]]) 01:17, 20 January 2023 (UTC) |
|||
::Also notified [[Wikipedia talk:Requests for comment/Deployment of Vector (2022)]]. [[User:InfiniteNexus|InfiniteNexus]] ([[User talk:InfiniteNexus|talk]]) 01:33, 20 January 2023 (UTC) |
|||
:::And [[mw:Talk:Reading/Web/Desktop Improvements]]. Not sure if notifying [[WP:AN]] is in order. [[User:InfiniteNexus|InfiniteNexus]] ([[User talk:InfiniteNexus|talk]]) 05:08, 20 January 2023 (UTC) |
|||
::::[[WP:AN]] would make sense to me. — [[User:Shibbolethink|<span style="color: black">Shibboleth</span><span style="color: maroon">ink</span>]] <sup>([[User talk:Shibbolethink|♔]]</sup> <sup>[[Special:Contributions/Shibbolethink|♕]])</sup> 18:00, 20 January 2023 (UTC) |
|||
:NO, do not use mass message to publicize this rfc, that is using a hammer to crack a nut that will result to the displeasure of many. |
|||
:There's an essay at [[WP:Publicising discussions]]. I have already done {{tl|Centralized discussion}} and I started a discussion for adding it to watchlist notices(the latter of which one editor objected to). I don't think this warrants a site notice though. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 01:23, 20 January 2023 (UTC) |
|||
::I'm aware of the essay, but I'd argue this is an exceptional case since it literally affects ''the entire community and the millions of users who use the English Wikipedia''. The closest comparison I can think of is ArbCom elections, which also uses MMS, but even that does not have as large of an impact as a UI change. [[User:InfiniteNexus|InfiniteNexus]] ([[User talk:InfiniteNexus|talk]]) 01:33, 20 January 2023 (UTC) |
|||
:::This RfC isn't THAT significant. Just following the guidance under "...affecting the whole community" and "General..." would be enough. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 01:41, 20 January 2023 (UTC) |
|||
::::It is extremely significant. It affects every single page view by every single user, whether logged in or not. That's billions of impressions daily. This is far more significant/important than whatever esoteric internal governance issues appear to be the subject of the other RFC solicitations linked at the top of this page. |
|||
::::Consider that most internal decisions presumably don't have tons of people creating new accounts just to argue against the decision. [[User:IWantTheOldInterfaceBack|IWantTheOldInterfaceBack]] ([[User talk:IWantTheOldInterfaceBack|talk]]) 02:12, 20 January 2023 (UTC) |
|||
:::::Yes but mass messaging and 100% sitenotices would spam every user. Your proposal below is better. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 02:23, 20 January 2023 (UTC) |
|||
::::::If not all active users, at least everyone with extended-confirmed permissions or above who has made at least 5 edits within the past three months. Heck, we could even just reuse [[WP:ACE2022#eligibility|the mailing list for last year's ArbCom elections]]. Any other method would be too passive, and we can see how that approach failed last time. [[User:InfiniteNexus|InfiniteNexus]] ([[User talk:InfiniteNexus|talk]]) 04:19, 20 January 2023 (UTC) |
|||
:::Fully agree. These changes effect everyone and everyone should get a chance to weigh in on it. I still support a site-wide poll for the next week to get the best possible data about where users' stand. [[Special:Contributions/2600:1700:1471:2550:4102:7C99:2804:8FC3|2600:1700:1471:2550:4102:7C99:2804:8FC3]] ([[User talk:2600:1700:1471:2550:4102:7C99:2804:8FC3|talk]]) 21:09, 20 January 2023 (UTC) |
|||
::'''''I was that editor''''' 😲 [[User:Terasail|<span style="color:#088; font-weight:800;">Terasail</span>]][[User talk:Terasail|<sup><span style="color:#000;">'''[✉️]'''</span></sup>]] 21:55, 20 January 2023 (UTC) |
|||
::YES, notify everyone, this is extremely important and all editors should be made aware that they get a say.[[User:StarTrekker|★Trekker]] ([[User talk:StarTrekker|talk]]) 22:03, 20 January 2023 (UTC) |
|||
:Proposal: use some mechanism (perhaps a random number generator?) to send an alert to 1 out of 100 pageviews soliciting feedback. Qualitative feedback is far more useful than the design team's dubiously meaningful statistics anyway! [[User:IWantTheOldInterfaceBack|IWantTheOldInterfaceBack]] ([[User talk:IWantTheOldInterfaceBack|talk]]) 02:10, 20 January 2023 (UTC) |
|||
@[[User:InfiniteNexus|InfiniteNexus]]: In my opinion, this RfC was a bit rushed and not well-thought-out. It would have been better to plan carefully how to advertise it to all users, both registered and unregistered. Also, while RfCs are not polls, I think that it would have been better if the comments were split into two sections, support and oppose, and numbered as it was in the previous RfC. [[User:Æo|Æo]] ([[User talk:Æo|talk]]) 16:20, 20 January 2023 (UTC) |
|||
:I agree. Separating into sections was what we were planning to do, as being discussed on [[WT:VECTOR2022]], but then another editor jumped the gun and created this RfC without even consulting WT:VECTOR2022. If they had, they would've noticed the discussion where the RfC was being drafted. [[Special:PermaLink/1134681662#RfC: Reversal of Vector 2022 deployment|This]] was the format that was being planned, which is far superior in my opinion. It was also intended to be hosted on a standalone page, but I'll save my comments on that matter at [[Wikipedia talk:Village pump (proposals)#Move Vector RFC to subpage]]. [[User:InfiniteNexus|InfiniteNexus]] ([[User talk:InfiniteNexus|talk]]) 16:29, 20 January 2023 (UTC) |
|||
::What's stopping us from switching this RfC to a support/oppose/discussion format? It's still new and managably small, reordering the !votes into categories would be a bit of work but I could do it. Plus it would probably solve the issue of people mistaking question #2 for where to weigh in on #1 - that's rapidly become a problem. --[[User:Kizor|Kiz]][[Special:Contributions/Kizor|<span style="color:black;">o</span>]][[User_talk:Kizor|<span style="color:green;">r</span>]] 17:44, 20 January 2023 (UTC) |
|||
:::The only thing I can think of is the sheer volume of new responses causing Edit conflicts. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 17:55, 20 January 2023 (UTC) |
|||
::::I've worked in articles for ongoing disasters that had far greater volume of edits than this. The volume here is not ideal but it's manageable. Move a couple dozen at a time, incorporate the edits that happened during the switchover. There'd be a bit of disruption during this, but a lot less, I think, than from leaving things as is. We need to take action to differentiate question #2 and any & all further questions from the main event. Should I get cracking? --[[User:Kizor|Kiz]][[Special:Contributions/Kizor|<span style="color:black;">o</span>]][[User_talk:Kizor|<span style="color:green;">r</span>]] 18:05, 20 January 2023 (UTC) |
|||
:::::InfiniteNexus and another user have proposed to move the RfC into a separate page ([https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Village_pump_(proposals)&oldid=1134785049#Move_Vector_RFC_to_subpage? cfr.]). I think you should reorganise the comments while moving them there. [[User:Æo|Æo]] ([[User talk:Æo|talk]]) 18:14, 20 January 2023 (UTC) |
|||
::::::I think we should keep those jobs separate. Trying to do both at once would probably lead to more disruption, not less, and take longer, meaning more potential edit conflicts, meaning more time spent sorting those out, meaning more potential edit conflicts, et al. This may not be rocket science, but it still calls for keeping payloads small. Also, do you know how long it'll take to get the support to go through with the move? --[[User:Kizor|Kiz]][[Special:Contributions/Kizor|<span style="color:black;">o</span>]][[User_talk:Kizor|<span style="color:green;">r</span>]] 18:43, 20 January 2023 (UTC) |
|||
:::::::I don't think that the move will require many support votes to be done, after all a formal RfC in the style of the previous one is what they were planning since before this RfC was opened. But, if InfiniteNexus agrees, proceed with the reorganisation. Then this entire page will likely become a redirect. [[User:Æo|Æo]] ([[User talk:Æo|talk]]) 19:09, 20 January 2023 (UTC) |
|||
::::::::InfiniteNexus is in favor. I'm pulling the trigger on this change. Brace yourselves. --[[User:Kizor|Kiz]][[Special:Contributions/Kizor|<span style="color:black;">o</span>]][[User_talk:Kizor|<span style="color:green;">r</span>]] 19:32, 20 January 2023 (UTC) |
|||
:Note that this rfc was not from infinite nexus but from Hal 333 without much communication or deliberation. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 16:30, 20 January 2023 (UTC) |
|||
Note: feel free to reword the text to question #2 for clarity if necessary (of course without changing the substantive meaning). I'm not super familiar with all the jargon used around here and I've been using "skin", "design", and "interface" interchangeably. [[User:IWantTheOldInterfaceBack|IWantTheOldInterfaceBack]] ([[User talk:IWantTheOldInterfaceBack|talk]]) 18:22, 20 January 2023 (UTC) |
|||
:I think it was great as-is. But I just changed "the new design" to "Vector 2022" to be a bit more future-proof and remove any need to debate skin vs design vs interface. — [[User:Shibbolethink|<span style="color: black">Shibboleth</span><span style="color: maroon">ink</span>]] <sup>([[User talk:Shibbolethink|♔]]</sup> <sup>[[Special:Contributions/Shibbolethink|♕]])</sup> 18:25, 20 January 2023 (UTC) |
|||
==== Allowing for IP users to change the skin back? ==== |
|||
Maybe we should create an easy way for IP users (and all Wikipedians) to be able to switch back to the old look? I know if I turn my skin on to Vector 2022, on the side, there is a button that says "Switch to old look." We could maybe do something like that with [[Cookies (Internet)|cookies]]. It seems like at the [[wp:Teahouse|Teahouse]], there are a lot of IP users complaining about the skin. [[User talk:Helloheart|<b style="border-radius:3em;padding:4px;background:#FF67CF;color:white;"> Helloheart </b>]] <span style="display:inline-block;margin-bottom:-0.3em;vertical-align:-0.4em;line-height:1.2em;font-size:80%;text-align:left"></span> 03:00, 20 January 2023 (UTC) |
|||
:The stated objection is the increased load on the servers caused by the need for more caching. I have outlined some possible technical solutions to this [[Wikipedia:Village_pump_(technical)#Vector_2022_Post-Deployment_Update_from_WMF_team|here]] (ctrl+F "particular items that have been listed"). [[User:IWantTheOldInterfaceBack|IWantTheOldInterfaceBack]] ([[User talk:IWantTheOldInterfaceBack|talk]]) 03:04, 20 January 2023 (UTC) |
|||
::They have a $100 million dollar endowment. I think that's sufficient to get servers that can do that. ~ [[User:HAL333|<span style="background:red; color:white; padding:2px; border:1px solid red;">'''HAL'''</span>]][[User talk:HAL333|<span style="background:black; color:white; padding:2px; border:1px solid red;">'''333'''</span>]] 06:13, 20 January 2023 (UTC) |
|||
:::Agree that there should be a way that they can implement preferences like that. It shouldn't be impossible given that https://en.m.wikipedia.org/w/index.php?title=Special:MobileOptions&returnto=Main+Page exists in mobile. [[User:CactiStaccingCrane|CactiStaccingCrane]] 08:52, 20 January 2023 (UTC) |
|||
::::Its possible but i doubt that will happen as i think the WMF wants more registered users and I wont be surprised if they remove the ability of IP users to edit or even to read articles in the future [[User:Qwv|Qwv]] ([[User talk:Qwv|talk]]) 10:25, 20 January 2023 (UTC) |
|||
:::::That's particularly funny since the WMF has generally been then one pushing back against community attempts to limit edits from IPs. [[User:Nil Einne|Nil Einne]] ([[User talk:Nil Einne|talk]]) 15:45, 20 January 2023 (UTC) |
|||
::{{tq|I have outlined some possible technical solutions to this here}}{{break}}[https://en.wikipedia.org/?diff=1134695925 here] is a permalink to your comment. I agree the argument against having skin-specific cookies for those who wish to default away from V22 is extraordinarily weak. We wouldn't need to cookie everyone, just those who wish to go back to V10. And any server usage increases must be weighed against those increases attributable to new accounts who wish to default to V10, increased clicks and reloads from navigation issues, need to have expandedwidth toggles, etc. It's not a decision that's made in a vacuum.— [[User:Shibbolethink|<span style="color: black">Shibboleth</span><span style="color: maroon">ink</span>]] <sup>([[User talk:Shibbolethink|♔]]</sup> <sup>[[Special:Contributions/Shibbolethink|♕]])</sup> 18:57, 20 January 2023 (UTC) |
|||
::Agreed. If their current technical staff can't handle this then they need to do some new hiring. They have plenty of money to do so. [[Special:Contributions/2600:1700:1471:2550:4102:7C99:2804:8FC3|2600:1700:1471:2550:4102:7C99:2804:8FC3]] ([[User talk:2600:1700:1471:2550:4102:7C99:2804:8FC3|talk]]) 21:10, 20 January 2023 (UTC) |
|||
:I think any such creation of this should be handled upstream, not with any sort of hacks here. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 11:49, 20 January 2023 (UTC) |
|||
:I find it hilarious and sad that, after spending the entire year begging me for money, you then go and make a chance like this which makes me LESS likely to come here anymore. I'll get my information elsewhere. You aren't the only wiki in town anymore, fan wikis often have far more information anyway. [[Special:Contributions/2603:3023:180:4800:112D:D97D:8F55:28B3|2603:3023:180:4800:112D:D97D:8F55:28B3]] ([[User talk:2603:3023:180:4800:112D:D97D:8F55:28B3|talk]]) 18:52, 20 January 2023 (UTC) |
|||
:This could be done with cookies but it would be very clunky, and I wouldn't support doing it on the server end since one user's preferences would stick to the next user on that IP address. Just as is the case with just about every website on the internet these days: if you want to save preferences, create an account to save them to. Otherwise you get whatever defaults the website gives you. [[User:Ivanvector|Ivanvector]] (<sup>[[User talk:Ivanvector|Talk]]</sup>/<sub>[[Special:Contributions/Ivanvector|Edits]]</sub>) 19:02, 20 January 2023 (UTC) |
|||
==== Vector 2022 Post-Deployment Update from WMF Team ==== |
|||
Hi everyone - we have posted an update to the [[Wikipedia:Village pump (technical)#Vector 2022 Post-Deployment Update from WMF team|technical Village Pump]] with some information about the deployment, responses to feedback we've received so far, and some upcoming changes we will be making to the skin. We encourage you to check it out and leave any comments or questions. Thank you! [[User:OVasileva (WMF)|OVasileva (WMF)]] ([[User talk:OVasileva (WMF)|talk]]) 01:36, 20 January 2023 (UTC) |
|||
:You really should be rolling back this unwanted change instead.[[User:Tvx1|T]][[User Talk:Tvx1|v]][[Special:Contributions/Tvx1|x]]1 01:53, 20 January 2023 (UTC) |
|||
::If it's unwanted by you, change to the old skin. There are people who do want it. Personally I am undecided, but at least willing to try it. [[User:331dot|331dot]] ([[User talk:331dot|talk]]) 01:54, 20 January 2023 (UTC) |
|||
:::As Daß Wölf put it in [[Wikipedia:Requests for comment/Deployment_of Vector (2022)|the previous RfC]]: "We can't pretend the settings are accessible to everyone when the user would have to go through all the steps of creating an account and logging in to use them. That would be a [[dark pattern]]." --[[User:Kizor|Kiz]][[Special:Contributions/Kizor|<span style="color:black;">o</span>]][[User_talk:Kizor|<span style="color:green;">r</span>]] 02:06, 20 January 2023 (UTC) |
|||
::::That cuts both ways, though. We have several officially supported skins, and you can only set a different default if you are a logged-in user; whichever one we choose as default forces some IP users to either put up with their less preferred skin, or create an account. People were just as upset by change when old Vector became the default, but today people are just used to that being the default interface. [[User:Caeciliusinhorto-public|Caeciliusinhorto-public]] ([[User talk:Caeciliusinhorto-public|talk]]) 09:30, 20 January 2023 (UTC) |
|||
:::::It only cuts both ways if we don't allow cookies to default a skin per user-agent. — [[User:Shibbolethink|<span style="color: black">Shibboleth</span><span style="color: maroon">ink</span>]] <sup>([[User talk:Shibbolethink|♔]]</sup> <sup>[[Special:Contributions/Shibbolethink|♕]])</sup> 18:02, 20 January 2023 (UTC) |
|||
:::I mean, this works both ways. If it was wanted by you, you could have just switched to the new one. No need to impose it on everyone, including those without accounts. [[User:RoadTrain|RoadTrain]] ([[User talk:RoadTrain|talk]]) 04:00, 20 January 2023 (UTC) |
|||
::::Exactly. There is no reason to make a highly contentious change like this a forced default. This should have been an option for those who like the new skin, not a forced global one. [[Special:Contributions/2600:1700:1471:2550:4102:7C99:2804:8FC3|2600:1700:1471:2550:4102:7C99:2804:8FC3]] ([[User talk:2600:1700:1471:2550:4102:7C99:2804:8FC3|talk]]) 15:22, 20 January 2023 (UTC) |
|||
:::{{ec}} Here's the thing. There are those who like Vector 2022, and there are those who hate it. For what reason should WMF favor those who like Vector 2022 over those who hate it, besides the fact that the new UI was designed by the Foundation? In XFDs, if editors are divided on what to do, the discussion is closed as "no consensus" and no action is taken. The page doesn't automatically get deleted or moved. Why should this situation be any different? [[User:InfiniteNexus|InfiniteNexus]] ([[User talk:InfiniteNexus|talk]]) 04:01, 20 January 2023 (UTC) |
|||
::::@[[User:InfiniteNexus|InfiniteNexus]], I'm fairly sure there will never be consensus concerning this, at least not now.<span id="Qwerfjkl:1674251842290:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — [[User:Qwerfjkl|<span style="background:#1d9ffc; color:white; padding:5px; box-shadow:darkgray 2px 2px 2px;">Qwerfjkl</span>]][[User talk:Qwerfjkl|<span style="background:#79c0f2;color:white; padding:2px; box-shadow:darkgray 2px 2px 2px;">talk</span>]] 21:57, 20 January 2023 (UTC)</span> |
|||
:Very much glad to see the feedback heard - hope to see Vector '22 refined to a state many more will be happy with. [[User:Lucksash|Lucksash]] ([[User talk:Lucksash|talk]]) 01:59, 20 January 2023 (UTC) |
|||
*If this RfC fails to find consensus for the WMF's [[Wikipedia:Be bold|BOLD]] decision, will you respect the community and return to the [[WP:STATUSQUO|STATUS QUO]]? ~ [[User:HAL333|<span style="background:red; color:white; padding:2px; border:1px solid red;">'''HAL'''</span>]][[User talk:HAL333|<span style="background:black; color:white; padding:2px; border:1px solid red;">'''333'''</span>]] 06:28, 20 January 2023 (UTC) |
|||
*:To ask the same question more pointedly - if consensus turns out to actively exist in favor of reverting the change, and English Wikipedia implements such a reversion, will the redesign developers respect this, or will they forcibly overrule said reversion? (it's still a very open question how consensus will turn out, since it's been less than half a day and non-account-holding users of Wikipedia have not yet been notified of this discussion in any way, shape or form) [[User:IWantTheOldInterfaceBack|IWantTheOldInterfaceBack]] ([[User talk:IWantTheOldInterfaceBack|talk]]) 06:33, 20 January 2023 (UTC) |
|||
*::At the very least, the WMF should try to take a measure of IP user sentiment, maybe through a click poll on the front page. If the readers like the new skin, I will gladly yield. I'm on Wikipedia for the reader, and most editors are. ~ [[User:HAL333|<span style="background:red; color:white; padding:2px; border:1px solid red;">'''HAL'''</span>]][[User talk:HAL333|<span style="background:black; color:white; padding:2px; border:1px solid red;">'''333'''</span>]] 06:41, 20 January 2023 (UTC) |
|||
*:::They've been doing that, and are continuing to do it, and have [[mw:Reading/Web/Desktop Improvements/Repository#Reports|shared the results]]. That's how they know that, e.g. from [[Wikipedia:Village pump (technical)#Vector 2022 Post-Deployment Update from WMF team|the post linked in the OP]], {{tqq|the sticky Table of Contents made editors 53% more likely and readers 46% more likely to navigate across multiple sections of a page}}. [[User:Levivich|Levivich]] ([[User talk:Levivich|talk]]) 06:48, 20 January 2023 (UTC) |
|||
*::::Those numbers alone mean nothing. I suspect that the 46% and 53% numbers refer specifically to navigation via the table of contents in particular, excluding navigation by scrolling up and down. This is no surprise, since the massive empty space introduced in the redesign makes scrolling much slower. This does not tell us anything about whether these users like or dislike the redesign. Stats alone can be massaged to manufacture almost any narrative. They tell us much less than qualitative feedback. [[User:IWantTheOldInterfaceBack|IWantTheOldInterfaceBack]] ([[User talk:IWantTheOldInterfaceBack|talk]]) 06:54, 20 January 2023 (UTC) |
|||
*:::::It's not numbers alone, [[Wikipedia:Requests for comment/Deployment of Vector (2022)/More about Vector (2022)#Process for developing the new skin]] has an overview about the testing, [[mw:Reading/Web/Desktop Improvements/Repository]] has links to reports about specific tests, and [[Wikipedia:Village pump (technical)#Vector 2022 Post-Deployment Update from WMF team]] is the latest update. [[User:Levivich|Levivich]] ([[User talk:Levivich|talk]]) 07:14, 20 January 2023 (UTC) |
|||
*:::Don' tsee any basis for a survey on the overall change. And specifically for the fixed-width, that should be measured through revealed preference, i.e. the amount of people clicking full-screen mode. A survey would only capture resistance to change, and would yield nothing informative. [[User:DFlhb|DFlhb]] ([[User talk:DFlhb|talk]]) 10:04, 20 January 2023 (UTC) |
|||
::As has been stated above, this RfC is a psuedo-review of the previous RfC's close. I'm not convinced that the closing comment interpreted the results of the discussion accurately (i.e. that there was consensus to roll out Vector 2022 if a limited-width toggle is added), and the comments on [[WT:VECTOR2022]] indicates that many users did not even have a chance to weigh in on the RfC, which means the RfC may not have been representative of the entire Wikipedia community. I agree that if this RfC closes as "no consensus", WMF should restore the old skin immediately. [[User:InfiniteNexus|InfiniteNexus]] ([[User talk:InfiniteNexus|talk]]) 07:06, 20 January 2023 (UTC) |
|||
:::And to reiterate my comments at [[WT:VECTOR2022#Requests for comment/Reverse deployment of Vector (2022)]], a close that does not end in the Web team's favor will not close the door on Vector 2022 being re-deployed in the future. If Vector 2022 is rolled back, the Web team is welcome to improve the skin to address the concerns raised here, come back with a follow-up discussion asking for more feedback, and then after most concerns have been addressed, a third RfC can be held. [[User:InfiniteNexus|InfiniteNexus]] ([[User talk:InfiniteNexus|talk]]) 07:11, 20 January 2023 (UTC) |
|||
:When are you guys rolling back the Vector 2022 update? Thanks! [[User:AdmiralBeans|AdmiralBeans]] ([[User talk:AdmiralBeans|talk]]) 07:45, 20 January 2023 (UTC) |
|||
::@[[User:AdmiralBeans|AdmiralBeans]] [[WP:CONSENSUS]] has not been reached. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 13:14, 20 January 2023 (UTC) |
|||
::::Or a lack thereof. [[User:InfiniteNexus|InfiniteNexus]] ([[User talk:InfiniteNexus|talk]]) 16:24, 20 January 2023 (UTC) |
|||
:::@[[User:Aaron Liu|Aaron Liu]] you didn't ask for our consensus when introducing it either, did you? [[User:2dk|2dk]] ([[User talk:2dk|talk]]) 16:22, 20 January 2023 (UTC) |
|||
::::The consensus was misinterpreted on the previous RfC. [[User:InfiniteNexus|InfiniteNexus]] ([[User talk:InfiniteNexus|talk]]) 16:24, 20 January 2023 (UTC) |
|||
:::::I'm surprised it didn't get taken to [[WP:Close review]]. But I guess WMF is the law of the land. That closure smelled to me of "[[regulatory capture]]" e.g. the closers closed with a bit of deference to what WMF actually wanted, even if not told to do so, and even if subconsciously so. — [[User:Shibbolethink|<span style="color: black">Shibboleth</span><span style="color: maroon">ink</span>]] <sup>([[User talk:Shibbolethink|♔]]</sup> <sup>[[Special:Contributions/Shibbolethink|♕]])</sup> 18:03, 20 January 2023 (UTC) |
|||
::::Introducing what?@[[User:2dk|2dk]] |
|||
::::If you’re talking about the new skin, I am not affiliated with WMF in any way. Also, the skin change was abiding by the misguided closing consensus at [[WP:V22RFC]]. [[User:Aaron Liu|Aaron Liu]] ([[User talk:Aaron Liu|talk]]) 16:25, 20 January 2023 (UTC) |
|||
== Making dark mode more accessible == |
== Making dark mode more accessible == |
Revision as of 01:10, 21 January 2023
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:
- Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
- This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
- Proposed policy changes belong at Village pump (policy).
- Proposed speedy deletion criteria belong at Wikipedia talk:Criteria for speedy deletion.
- Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
- Proposed new wikis belong at meta:Proposals for new projects.
- Proposed new articles belong at Wikipedia:Requested articles.
- Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
- Software changes which have consensus should be filed at Phabricator.
Discussions are automatically archived after remaining inactive for nine days.
Wikidata lists
Should mainspace lists where the contents are pulled from and maintained at Wikidata be allowed or disallowed? Fram (talk) 07:25, 19 September 2022 (UTC) (edited same day at 13.35, see start of discussion section)
Summary (Fram)
There are a number of lists where the contents are pulled from Wikidata through Template:wdtable row, with specific subtemplates for different types of content. The result can be seen e.g. here. The Wikipedia-only version of the same list can be seen here. Previous RfCs (see Wikipedia:Wikidata#Appropriate usage in articles have already agreed that "Wikidata should not be linked to within the body of the article except in the manner of hidden comment" and that it is "not appropriate to use Wikidata in article text on English Wikipedia ", but allowing Wikidata in infoboxes and de facto also many in external links templates. Previous lists where not only the contents, but even the entries were Wikidata driven have been disallowed in the mainspace as well.
The new type of lists has a number of disadvantages compared to enwiki-based lists, i.e.
- it isn't maintainable here but requires going to another website with another interface, making it harder for most people (for the data)
- requires editing templates or creating new ones for the layout
- Has issues with e.g. sorting, see for example here where (with the current Wikidata data) sorting on the "opened" column gives a random "Apr 1998" data inbetween the blank dates, and sorts "17 Apr 1968" before 1917 and so on. This example shows also a typical issue with getting data from Wikidata like this, the formatting. Wikidata has "April 1998", so I suppose the "Apr 1998" entry is formatted in a template. This makes it again harder for regular editors to maintain or layout such articles.
- Similarly, at Talk:List of dams in Saga Prefecture an editor asked to remove the image column from the article, as they were unable to do this under the Wikidata format. This required the creation of a new template, instead of simply editing the article. Fram (talk) 07:41, 19 September 2022 (UTC)
- There are other more minor issues, like the name appearing in the list being the Wikidata label, not the enwiki article name, or the sourcing being inadequate (Wikidata items referenced to some Wikipedia version, often outdated (e.g. some of the entries on List of islands of the Isles of Scilly use the 2001 census instead of the 2011 census our articles use, indicating the glacial speed of update Wikidata often has) Fram (talk) 09:03, 19 September 2022 (UTC)
- See for example List of learned societies in Australia, with issues from the start (e.g. one entry with the incorrect Wikidata title instead of the correct enwiki title, and entries which don't even belong there like the Austronesian Formal Linguistics Association), and then made worse by an editor who probably couldn't figure out how to correctly add an entry[1]. This type of list is not editor-friendly at all. Fram (talk) 12:38, 19 September 2022 (UTC)
Summary (MSGJ)
Thank you for starting this discussion and inviting me to present an alternative viewpoint. First, some background for those who may not be familiar with Wikidata. This Wikimedia sister project, launched in 2012, is designed to hold data for use by Wikipedias and other sister projects. Its use on the English Wikipedia is not at all new - it has been used extensively in infobox templates for many years now - so its use in data tables and lists should not be surprising to Wikipedia editors. I really thought and hoped that the "us and them" attitude towards Wikipedia and Wikidata had diminished over the years.
Being designed for this purpose, Wkidata offers many advantages over conventional wikitext for storing reliable data, including:
- Numerous constraints which can catch incorrect data, such as incorrect units, a date of death before a date of birth, etc.
- A very user-friendly interface (almost certainly easier than editing wikitext for new editors). For example, compare how you would update the height of a dam on wikitext version compared with on Wikidata.
- Ability to use powerful queries to find information.
- And probably most importantly, improvements to the data by one project will be of benefit to all projects.
All data on Wikidata can (and should) be referenced, just as it is on Wikipedia. All changes can be monitored via RecentChanges (if you have the appropriate option selected).
The use of a template to produce the rows of the table has several advantages, including:
- The template allows any column to be overridden by locally defined content. For example on List of Welsh mathematicians the "Notes" column is entirely local content.
- The wikicode to produce rows and columns, which is complex for many editors, is conveniently separated from the content of the table.
- A column can be added or removed from the table by making a single change to the template, rather than dozens of changes to the wikitext.
- The pencil icon
links straight to where the data is stored.
Finally, a word on the previous discussions about the use of Wikidata on Wikipedia. A table is not classed as "article text" so the prohibition on using Wikidata for article text is not relevant here. And, regarding the linking to Wikidata, the only link is the pencil icon mentioned earlier which is widely used and accepted in infobox templates. — Martin (MSGJ · talk) 17:04, 19 September 2022 (UTC)
Discussion (Wikidata lists)
- @Fram: Two things: this is asking whether they're allowed, not whether they should be allowed. Is this about getting clarity of where past decisions have landed us, or deciding whether they should be allowed? If it's really just asking whether they're allowed, the list of reasons why they're bad seems out of place. If it's asking whether they should be allowed, you may want to edit the initial statement. The other suggestion is sort of dependent on the first, but you may want to separate the summary of where consensus stands from specific arguments about what our policy should be. The latter isn't so much a summary as arguments supporting one outcome. — Rhododendrites talk \\ 13:00, 19 September 2022 (UTC)
- Well, it's kind of a double question; are they allowed viz-a-viz the previous RfCs, and should they be allowed or not? I guess the second is more important than the first, as it's not intended as a "you did something that wasn't allowed" but more of a "this is how we'll proceed from now on". I'll change the RfC accordingly. Fram (talk) 13:35, 19 September 2022 (UTC)
- Initial thoughts (should I be creating my own section per above?): I have mixed feelings about Wikidata lists. On the bad side: technical limitations. Some of the things Fram lists seem like they could be fixable, but for others it's a matter of better integration of Wikidata in Wikipedia (in the sense of editing). The current templates, which send would-be editors to a Wikidata page with no explanation, are a bit clumsy (but, granted, an early step in the process). On the good side: I can see at least two good uses for Wikidata in Wikipedia lists. The first is as a starting point. If you want to make a lists of dams in a given place, that's something Wikidata has data for, and pulling from Wikidata could save a lot of time vs. hunting it down and formatting it yourself. Then you could convert it to wikitext and move on. I don't expect that's very controversial, though. The second case is when Wikidata pulls from databases that are more easily kept up-to-date than a Wikipedia list. We have an awful lot of out-of-date lists, and if it's an appropriate topic, why not let Wikidata gnomes keep it up to date? We just need more sophisticated templates to allow for flexibility in display and for fixing errors without sending someone on a journey to Wikidata. So I guess part of my answer (although per above I'm not sure which question I'm answering) is: yes, at some point these are useful, and I'd encourage people to shift the discussion from a binary yes/no to figuring out (a) in what contexts they're useful, and (b) if the current setup is inadequate, what changes to the interface and/or templates would be needed to ensure we can take advantage of this data in those cases when it's useful? — Rhododendrites talk \\ 13:23, 19 September 2022 (UTC)
- Thanks for this very astute comment. I will happily admit that the template can be improved (e.g. sorting on dates which is mentioned earlier), and any suggestions will be much appreciated — Martin (MSGJ · talk) 18:07, 19 September 2022 (UTC)
- Rhododendrites I agree. If we have concerns about referencing, then use reputatable source checker to confirm them and colour/flag them differently (red = dodgy etc).If we want to see who did the edit change in Wikidata then create a combined history search, if they are coi change the colour.
- WIkidata would be useful for
- Detecting scam/bankrupt smaller companies/pheonix - they are better setup for receiving feeds from regulators/credit agencies
- Structured validated data in infoboxes: we could get rid of categories, and instead have a search based on the infobox.
- Allowing readers to view chnages over time in table data in an article (which would act an an open alternative to statista ) - What were the top 5 exporters of truffle in 1932? Or does Template:Graph:Chart or similar already cater for that?
- Allowing preferred data formatting in tables to be seperated from validdated data. (Sep rather than Sept, or my bugbear of non date in date fields). Wakelamp d[@-@]b (talk)
- Wakelamp d[@-@]b (talk) 02:40, 22 November 2022 (UTC)
- My understanding from past RFCs is that we continue to be extremely wary of Wikidata, and have limited its use… but that, within those limits, it can be used.
- That said, I don’t think we have been very clear as to what exactly those limits ARE. We need to spell them out clearly. Do we have a guideline or policy section covering this? Blueboar (talk) 13:55, 19 September 2022 (UTC)
- I don't think its specific use in lists/tables has been put to RfC before. The closer of 2013 discussion wrote "There is a valid point raised that while running text is clearly not suitable for Wikidata use, it might be worth discussing use in tables specifically – but no consensus regarding this has been reached in this discussion." — Martin (MSGJ · talk) 18:09, 19 September 2022 (UTC)
- I would think that this is disallowed per the previous RfC, which stated that it is
not appropriate to use Wikidata in article text on English Wikipedia
. A list article is still an article. I've actually come across some of these lists before and wondered why they were using {{Wdtable row}} instead of {{Wikidata list}}. The presumable reason is that {{Wikidata list}} produces an error when used in mainspace due to the results of that RfC and others. The use of {{Wdtable row}} in mainspace articles strikes me as a clumsy workaround to skirt consensus. Spicy (talk) 16:31, 19 September 2022 (UTC)- Yes, a list is an article but the values in a table are not "article text", which I take to mean prose. Some tables combine values and prose, e.g. List of Welsh mathematicians, and the template will only produce the content for the values and not for the prose. — Martin (MSGJ · talk) 18:12, 19 September 2022 (UTC)
- I'm of a mind that we shouldn't encourage them, and don't personally use them, but if someone wants to put together say a rather exhausting list of plant species or something, Wikidata may simplify the process. If someone finds a clever way to use them, why stop them? I agree with Rhododendrites that we should focus on where they're best used and how to improve their usage. CaptainEek Edits Ho Cap'n!⚓ 16:54, 19 September 2022 (UTC)
- I agree with Rhododendrites - tables pulled from Wikidata are suitable for some uses and not from others. Where they are suitable I see no justification for either prohibiting or requiring their use (treat it like ENGVAR or citation styles: either version is acceptable, don't change without both a good reason and consensus). Where they aren't suitable obviously they shouldn't be used, but I hope nobody is advocating for that. We should work on making the integration better so that the problems identified are fixed rather than saying the first version is not perfect so go away and never come back again. I also suggest that developing a set of guidelines about where Wikidata tables are and are not appropriate for use to be a much better use of editors' time than arguing about whether they should or should not be used at all. Thryduulf (talk) 22:30, 19 September 2022 (UTC)
- In theory, I'm fairly open to tables containing entries from Wikidata. In practice, I'd like to see more working and non-working examples. I think there are a few other language Wikipedias with deeper Wikidata integration, but perhaps I am mistaken and that is all just infoboxes. There are also a lot of things where information is rather fuzzy, making Wikidata difficult to use. It is easy to annotate uncertain dates and debates around them in wikitext; learning how to do that on Wikidata is rather hard and certainly unintuitive for people used to Wikipedia. —Kusma (talk) 08:18, 20 September 2022 (UTC)
- Thanks for your comment. I am of the opinion that only a clear-cut value can be appropriately used from Wikidata. Anything which requires clarification or explanation should be locally defined. There are a couple of approaches I have used in these cases.
- For example on List of castles in Ireland#County Clare, the imprecise build date of Ballyhannon Castle is locally specified via
|c5=c. [[1490 in Ireland|1490]]<ref>{{harvp|Westropp|1899|p=351}}</ref>
- And on List of lighthouses in Scotland, I clarified the build date of Southerness Lighthouse by adding a footnote to the value from Wikidata via
|c5+={{efn|Built in 1748 but not lit till 1800. Rebuilt in 1844.}}
- For example on List of castles in Ireland#County Clare, the imprecise build date of Ballyhannon Castle is locally specified via
- — Martin (MSGJ · talk) 16:01, 21 September 2022 (UTC)
- Thanks for your comment. I am of the opinion that only a clear-cut value can be appropriately used from Wikidata. Anything which requires clarification or explanation should be locally defined. There are a couple of approaches I have used in these cases.
- I'll perhaps expand on my rationale later, but fundamentally, I support Wikidata-derived tables being allowed. It all comes down to implementation — if done well, the appearance to readers will be exactly the same as a manually generated article, and the Wikidata-derived one will be far more future-proof. {{u|Sdkb}} talk 06:03, 21 September 2022 (UTC)
- The only argument presented by people in favor of using Wikidata continuously (as opposed to using it once to generate a list) seems to be making things easier to keep up to date. But most uses of Module:Wikidata table are timeless: lists of dams, lighthouses, and castles, etc. don't need much updating (other than adding new entries if they are built, which still needs to be done manually in the Wikidata version), so in those cases that argument is not convincing. On the contrary, there's been no refutation to several of Fram's points above which amount to the fact that it will almost always be possible to further optimize such a list with local tweaks because humans are better at this then co. So what's the harm in detaching from Wikidata and letting that be done? I'm not seeing it. For the few that aren't timeless (List of Brazilian mathematicians, List of Welsh mathematicians and List of Polish mathematicians seem to be the only ones), there is a slightly better case for using Wikidata, and I haven't come to a strong opinion either way. * Pppery * it has begun... 17:43, 21 September 2022 (UTC)
- For me it is not only about the creation of the lists, but the future updates and improvements too. I do not expect these lists to stay the same for ever more - I really hope they will be expanded with more information and better references. I believe this is both easier and better in the Wikidata version. Easier, because of the structured environment which lends itself to data import and verification. Better, because the knowledge will be shared among all language Wikipedias. — Martin (MSGJ · talk) 19:19, 29 September 2022 (UTC)
- I would have thought the prohibition applied to lists and tables as well, but if that's not the consensus I would support extending the prohibition to lists and tables. No problem with using Wikidata to initially populate a table or list, of course; the onus is on the editor to make sure it's reliable data as with any edit. The problem of "sneaky vandalism", as I think Fram named it years ago, is real -- changes to Wikidata are not easily visible which means you may not know when your article has been vandalized, and even if it's detected a user who can edit here may be unable or unwilling to learn the quite different interface there. Re Rhododendrites' comment that it would be OK to have a table sourced to live Wikidata, knowing that the gnomes over there would keep it up to date -- I don't think anyone would be OK without outsourcing our table data to, say, Fishbase, for certain tables, so why would we be OK with it with an intermediary? Mike Christie (talk - contribs - library) 22:40, 21 September 2022 (UTC)
- Sneaky vandalism is a problem that can occur with any type of list. With watchlist integration, while not perfect, I can effectively patrol all changes to data which affect these articles. So I do not really accept that changes on Wikidata are invisible or hard to catcher than on Wikipedia. — Martin (MSGJ · talk) 19:23, 29 September 2022 (UTC)
- When I last tried "Show Wikidata edits in your watchlist" it added an incredible amount of noise that made the watchlist unusable. Has that changed? Johnuniq (talk) 01:25, 30 September 2022 (UTC)
- Yes, a couple of years ago. WMDE did the work, so it's probably documented at Meta-Wiki. The volume and relevance of notified changes seems to depend on the subjects that you're watching, so I suggest trying it out and seeing what you think for yourself/your own subjects. I feel like volunteer-me gets a surprisingly large number of notifications for Apology (act) and Apologia, but less than I expect for other subjects, like Lymphoma. Most of the changes I see are changes to the linked articles (e.g., someone creating an article at another language's Wikipedia about lymphoma). Whatamidoing (WMF) (talk) 22:32, 30 September 2022 (UTC)
- It's probably fair to say that there are still too many entries that make it through the filter. I don't need to know when someone changes the Bangladeshi label or adds a sitelink to the Hebrew Wikipedia. Really the only ones needed are those which affect the display of the relevant article, although an option to display all changes might be useful for some editors. — Martin (MSGJ · talk) 14:34, 1 October 2022 (UTC)
- Yes, a couple of years ago. WMDE did the work, so it's probably documented at Meta-Wiki. The volume and relevance of notified changes seems to depend on the subjects that you're watching, so I suggest trying it out and seeing what you think for yourself/your own subjects. I feel like volunteer-me gets a surprisingly large number of notifications for Apology (act) and Apologia, but less than I expect for other subjects, like Lymphoma. Most of the changes I see are changes to the linked articles (e.g., someone creating an article at another language's Wikipedia about lymphoma). Whatamidoing (WMF) (talk) 22:32, 30 September 2022 (UTC)
- When I last tried "Show Wikidata edits in your watchlist" it added an incredible amount of noise that made the watchlist unusable. Has that changed? Johnuniq (talk) 01:25, 30 September 2022 (UTC)
- Sneaky vandalism is a problem that can occur with any type of list. With watchlist integration, while not perfect, I can effectively patrol all changes to data which affect these articles. So I do not really accept that changes on Wikidata are invisible or hard to catcher than on Wikipedia. — Martin (MSGJ · talk) 19:23, 29 September 2022 (UTC)
- Question, if I wish to change or amend something in a table that uses Wikidata to generate info, would I have to go to Wikidata to make the edit, or can it be done using the edit mode here in WP? Say something simple like a style correction. Blueboar (talk) 01:46, 30 September 2022 (UTC)
- Taking the eventualist view, with future interface improvements, yes, you'll be able to stay on Wikipedia. Also, it's worth noting that tables generated through Wikidata are less likely to have errors to begin with because there are fewer elements being created manually. {{u|Sdkb}} talk 03:47, 30 September 2022 (UTC)
- So your "yes, you'll be able to stay on Wikipedia" is actually a "no". Deciding on the current status of such lists based on what might happen one day, perhaps (Wikidata is 9 years old, so it's not as if such changes happen rapidly) is not a good idea. So, @Blueboar: you indeed have to go to Wikidata to edit the info, Wikipedia edit mode won't help you. And Sdkb, your "less likely to have errors" doesn't seem to make much sense either, the elements are created manually at Wikidata or manually at enwiki, no reason why one would be less likely to have errors (on the one hand, Wikipedia has more editors and thus more vandals: on the other hand, vandalism on Wikidata is much more likely to stay undetected, see e.g. here where it took a full month until someone noticed that the page "Punjabi" had been moved (retitled) to "josh saunders", or here where it took more than a month for someone to notice that "Aaron Ramsey" was moved to "Penalty in the UEL final". Fram (talk) 07:37, 30 September 2022 (UTC)
- The reason Wikidata-derived tables have fewer errors is that, when you're adding a row through Wikipedia, you need to add both the data and the formatting, and each of those is a potential spot to mess up. I'm sure we've all seen tables that have an extra column used only in one row because someone put an extra "|-". When you're adding information on Wikidata, however, all you have to worry about is the data. And even there, constraint violations can help identify errors that Wikipedia would not have been able to flag, and data imports can help a single experienced editor add large amounts of high-quality information (rather than relying on piecemeal contributions by many different editors, any one of whom might mess up). {{u|Sdkb}} talk 15:26, 3 October 2022 (UTC)
- That's a rather anti-wiki position you take there. "relying on piecemeal contributions by many different editors" is what makes Wikipedia, and excluding these editors from pages is a good argument against Wikidata lists, not for them. (Never mind the countless times experienced editors made completely incorrect or botched mass updates of info on Wikidata of course). Fram (talk) 16:07, 3 October 2022 (UTC)
- I'm absolutely a fan of crowdsourced editing or I wouldn't be a Wikipedian. What I'm not for is forcing information that can be more efficiently handled in bulk to be handled piecemeal. That's why I oppose the wholesale deletion of template namespace, and also why I support the use of Wikidata. Neither of those things make me anti-wiki. Regarding the potential for errors in Wikidata imports, that potential exists in normal editing, too. I think the anti-wiki position would be to say that we should prohibit a type of editing entirely just because it's not done properly 100% of the time. {{u|Sdkb}} talk 18:18, 3 October 2022 (UTC)
the wholesale deletion of template namespace
Strewth!! Was that actually proposed? When? — GhostInTheMachine talk to me 19:15, 3 October 2022 (UTC)- I'm using it as a hyperbolic analogy here, but there are certainly examples of resistance to template usage for things like census data that I'd say fall at a milder point along the same spectrum. {{u|Sdkb}} talk 20:54, 3 October 2022 (UTC)
- I'm absolutely a fan of crowdsourced editing or I wouldn't be a Wikipedian. What I'm not for is forcing information that can be more efficiently handled in bulk to be handled piecemeal. That's why I oppose the wholesale deletion of template namespace, and also why I support the use of Wikidata. Neither of those things make me anti-wiki. Regarding the potential for errors in Wikidata imports, that potential exists in normal editing, too. I think the anti-wiki position would be to say that we should prohibit a type of editing entirely just because it's not done properly 100% of the time. {{u|Sdkb}} talk 18:18, 3 October 2022 (UTC)
- That's a rather anti-wiki position you take there. "relying on piecemeal contributions by many different editors" is what makes Wikipedia, and excluding these editors from pages is a good argument against Wikidata lists, not for them. (Never mind the countless times experienced editors made completely incorrect or botched mass updates of info on Wikidata of course). Fram (talk) 16:07, 3 October 2022 (UTC)
- The reason Wikidata-derived tables have fewer errors is that, when you're adding a row through Wikipedia, you need to add both the data and the formatting, and each of those is a potential spot to mess up. I'm sure we've all seen tables that have an extra column used only in one row because someone put an extra "|-". When you're adding information on Wikidata, however, all you have to worry about is the data. And even there, constraint violations can help identify errors that Wikipedia would not have been able to flag, and data imports can help a single experienced editor add large amounts of high-quality information (rather than relying on piecemeal contributions by many different editors, any one of whom might mess up). {{u|Sdkb}} talk 15:26, 3 October 2022 (UTC)
- And in at least one proposal to implement a list from Wikidata that I examined, the one list of items here would have been replaced with code that got items from dozens of different pages at Wikidata. In other words, the attack surface for vandalism would have been multiplied dozens of times, and manual checking of Wikidata items would have been dozens of times more difficult than looking at wikitext here. Johnuniq (talk) 09:12, 30 September 2022 (UTC)
- So your "yes, you'll be able to stay on Wikipedia" is actually a "no". Deciding on the current status of such lists based on what might happen one day, perhaps (Wikidata is 9 years old, so it's not as if such changes happen rapidly) is not a good idea. So, @Blueboar: you indeed have to go to Wikidata to edit the info, Wikipedia edit mode won't help you. And Sdkb, your "less likely to have errors" doesn't seem to make much sense either, the elements are created manually at Wikidata or manually at enwiki, no reason why one would be less likely to have errors (on the one hand, Wikipedia has more editors and thus more vandals: on the other hand, vandalism on Wikidata is much more likely to stay undetected, see e.g. here where it took a full month until someone noticed that the page "Punjabi" had been moved (retitled) to "josh saunders", or here where it took more than a month for someone to notice that "Aaron Ramsey" was moved to "Penalty in the UEL final". Fram (talk) 07:37, 30 September 2022 (UTC)
- If I need to go to WD to edit WP… that is a deal breaker for me. So put me down as still opposed. Blueboar (talk) 11:26, 30 September 2022 (UTC)
- Taking the eventualist view, with future interface improvements, yes, you'll be able to stay on Wikipedia. Also, it's worth noting that tables generated through Wikidata are less likely to have errors to begin with because there are fewer elements being created manually. {{u|Sdkb}} talk 03:47, 30 September 2022 (UTC)
- I remain extremely sceptical about the value of using Wikidata directly in articles for anything, although obviously compiling a list/table using Wikidata, and then disassociating it, is completely acceptable. As is using it in project space, and potentially talk pages. It makes editing the content nearly impossible for those not used to Wikidata, and it makes watching the page for changes completely impossible. ETA: For instance, List of Welsh mathematicians, linked above as an example, contains entries with three inline sources for things like date of birth, presumably unnecessary (and if the sources disagree, this should be footnoted), and has abbreviated months, which is not Wikipedia style but can't be edited within the Wikipedia page. The repeated edit links are also obtrusive. Espresso Addict (talk) 05:44, 1 October 2022 (UTC)
- Thanks for your comments.
- MOS:DATES suggests that abbreviated dates like 2 Sep 2001 or Sep 2, 2001 are acceptable in tables. I think the full unabbreviated dates would take up too much space in most tables.
- Do you have any suggestions to make the edit links less obtrusive? They are necessary to allow editors to change the values, but are only currently visible to logged in users.
- The maximum number of references is set at 3 and could be reduced further.
- — Martin (MSGJ · talk) 14:32, 1 October 2022 (UTC)
- Thanks for your comments.
- "Sep" as an abbreviation for September looks very odd in UK English, which would appertain to a list of Welsh people. The problem is the lack of easy-to-understand customisation. If I have five sources for a dob, I can choose to include only say no 3 because it is reliable & accessible, or put in two sources because one is highly reliable but not readily accessible, and another less reliable but accessible, &c&c. I have absolutely no idea how to do that within Wikidata, and no desire to have to learn a new and cumbersome editing interface. Also using things like n/a for the death date of a living person feels disrespectful. No clue how to make the edit links less prominent; I dislike them in infoboxes, but there's usually plenty of whitespace there to absorb them. Perhaps if they only showed in edit mode, somehow? And how are logged-out editors supposed to amend things? Espresso Addict (talk) 23:44, 1 October 2022 (UTC)
- @Espresso Addict: absolutely. If you are curating a list/table to such a degree then you will almost certainly want to forgo the convenience of the template and gain the greater flexibility. But 99% of lists are not like this, many of which are a bare list of links without additional information or references. For these, the template can produce a nice looking table with more detail, and is more likely to stay up to date. PS I use "Sep" all the time as an abbreviation for September, and it doesn't look odd to me! — Martin (MSGJ · talk) 15:51, 3 October 2022 (UTC)
- "Sep" as an abbreviation for September looks very odd in UK English, which would appertain to a list of Welsh people. The problem is the lack of easy-to-understand customisation. If I have five sources for a dob, I can choose to include only say no 3 because it is reliable & accessible, or put in two sources because one is highly reliable but not readily accessible, and another less reliable but accessible, &c&c. I have absolutely no idea how to do that within Wikidata, and no desire to have to learn a new and cumbersome editing interface. Also using things like n/a for the death date of a living person feels disrespectful. No clue how to make the edit links less prominent; I dislike them in infoboxes, but there's usually plenty of whitespace there to absorb them. Perhaps if they only showed in edit mode, somehow? And how are logged-out editors supposed to amend things? Espresso Addict (talk) 23:44, 1 October 2022 (UTC)
- Unless it can be altered on ENWP without going to Wikidata, I am in line with the previous consensus that wikidata imported content should not be used in article space except under the very limited exceptions. If it can be amended on ENWP and draw through to Wikidata, all my concerns disappear. Keep in mind those exceptions exist precisely because of the issues with Wikidata, chiefly its another project with its own rules and policies, its own admins, far less active users to combat deliberate vandalism, BLP violations etc. Importing lists that include living people is most BLP-watchers nightmare when you have to go to other projects to rectify it. (The same issues exist with imported commons content but at least thats relatively simple to fix). Being able to alter the content as it displays on ENWP, while on ENWP, without having to go to another project would seem to be something the WMF's tech tech could spend some time & cash doing (hint, its not difficult as anyone who has worked with a data warehouse and multiple databases knows) instead of whatever waste of time they are concentrating on. Only in death does duty end (talk) 16:22, 1 October 2022 (UTC)
- Frankly, I read the spirit of the various RFCs on wikidata as being pretty clearly against their use in making articles - so the claim that a table isn't "article text" and so it is fine to make tables from wikidata ... strikes me as very much a rules-lawyering type of statement. I wish that the proponents of wikidata would quit pushing it in such ways - it doesn't help their "cause". Ealdgyth (talk) 13:29, 3 October 2022 (UTC)
- The past RfCs have explicitly considered Wikidata use in tables and found no consensus on the question, so I'm not sure where you're getting that it goes against their "spirit" other than that you're reading your preferred opinion into them. Your idea of "pushing" can just as easily be flipped: I wish that those who fail to see Wikidata's potential would quit resisting it in such ways. {{u|Sdkb}} talk 15:19, 3 October 2022 (UTC)
- Its more that we do see the potential ... for abuse. And there needs to be either a strong mitigation or exceptional reason in place to ignore that risk. Which when it comes to wikidata, there rarely is. Only in death does duty end (talk) 16:47, 3 October 2022 (UTC)
- Particularly for lists that include BLPs, there is potential for BLP violation going unnoticed; a particularly common form of vandalism is to state a living person is dead, or less malevolently, to believe unreliable sources and assume incorrectly that death has occurred. This happens time and time again, and requires careful oversight. Espresso Addict (talk) 22:13, 3 October 2022 (UTC)
- Its more that we do see the potential ... for abuse. And there needs to be either a strong mitigation or exceptional reason in place to ignore that risk. Which when it comes to wikidata, there rarely is. Only in death does duty end (talk) 16:47, 3 October 2022 (UTC)
- No, Wikidata has been repeatedly banned from the body of the article. Every time a Wikidata-activist tries to shove Wikidata into the body of the article there is always consensus against it, they can't even get consensus for infoboxes. That's stuck in no-consensus. It appears that the only way to stop the recurring and disruptive creeping rollout-contrary-to-consensus by Wikidata-enthusiasts is to entirely shut off the calls to Wikidata in Wikitext itself. As long as it's available they just keep cooking up new ways to shove it out unilaterally. Alsee (talk) 06:50, 7 October 2022 (UTC)
- Additional note: lists [] are articles, and we have established consensus against linking to Wikidata anywhere in the body of the article. All of this content may be immediately deleted from any list or other article as a consensus action, as these tables massively spam Wikidata links. In theory the templates could be revised to eliminate the Wikidata links, however I hope/believe that the wikidata-enthusiasts here would not be so perverse as to advocate a blatantly broken and blatantly harmful result. It would be practically impossible for ANYONE to edit the page via Wikipedia OR Wikidata, as the wikitext contains nothing but jibberish and there would be no pencil link to edit via Wikidata. Alsee (talk) 19:57, 6 December 2022 (UTC)
- Additional issue: editing of tables like this in Visual Editor is nearly impossible and gives, for the few things it can do, very poor results. I tested this with List of dams in Tochigi Prefecture. Compared to "normal", non-Wikidata lists, here I can only add a new line at the top, not anywhere else in the list, and the result is badly formatted. I don't know if the WD list template can be changed to solve these issues, but if not, I don't think it is acceptable to introduce new things into Wikipedia which are incompatible with Visual Editing (even though I loathe it, it is used by a fair percentage of people and many new editors, and making it impossible for them to edit a type of articles is not anything that should be tolerated). Fram (talk) 10:04, 13 October 2022 (UTC)
- That could be partially mitigated through proper use of TemplateData. {{u|Sdkb}} talk 14:06, 13 October 2022 (UTC)
- How so? My remark about the template is not that an editor won't know that they need to add the wikidata template or add a Qnumber, but that even with that information, you can't produce a good result in VE. Perhaps I am missing something, but I don't think Templatedata can solve or even mitigate the underlying technical issue. Fram (talk) 14:26, 13 October 2022 (UTC)
- VisualEditor at this point is capable of doing anything with templates that source editor can do, I believe. Having good TemplateData makes the interface easier for editors. {{u|Sdkb}} talk 17:56, 13 October 2022 (UTC)
- Have you actually tested this, e.g. with List of dams in Tochigi Prefecture? Try to add e.g. a new dam in the middle of the list, or to move one of the existing entries up or down. TemplateData won't change anything about this functionality. Fram (talk) 18:32, 13 October 2022 (UTC)
- VisualEditor at this point is capable of doing anything with templates that source editor can do, I believe. Having good TemplateData makes the interface easier for editors. {{u|Sdkb}} talk 17:56, 13 October 2022 (UTC)
- How so? My remark about the template is not that an editor won't know that they need to add the wikidata template or add a Qnumber, but that even with that information, you can't produce a good result in VE. Perhaps I am missing something, but I don't think Templatedata can solve or even mitigate the underlying technical issue. Fram (talk) 14:26, 13 October 2022 (UTC)
- This is a valid point, and I have made a start on creating TemplateData for this template, which can be observed on List of dams in Tochigi Prefecture. I do not know if rows can be added in different places, but I will seek advice on this. — Martin (MSGJ · talk) 12:08, 14 October 2022 (UTC)
- Thanks. Adding entries anywhere in the list is just one of the issues, you e.g. also can't delete the existing ones, and when you add a new line at the top (using the Wikidata template) it only fills the first cell, instead of filling the table as it should (no idea if this list is exhaustive, I stopped testing after this). Templatedata helps at editing the already existing lines (though not removing them or moving them inside the table), but does nothing to make the editing of the table possible. Just tested again at List of dams in Toyama Prefecture, and the new Templatedata is good (e.g. overriding an existing row label), but no solution to the fundamental issue. Fram (talk) 12:47, 14 October 2022 (UTC)
- That could be partially mitigated through proper use of TemplateData. {{u|Sdkb}} talk 14:06, 13 October 2022 (UTC)
- Thanks for the interesting discussion. I came here after participating in Wikipedia:Articles for deletion/List of CryEngine games and Category:Video games by game engine, and I was pointing people to here to see if a bigger discussion could be had. However this discussion is interesting with respect to the deletion discussion, as one suggested solution to prevent information being deleted was actually using WikiData to store the information, and not need categories or lists, and for users who are interested they could pull the data out of Wikidata. I've read with interest everyone's positions, and I agree with user User:Rhododendrites and User:CaptainEek. We should absolutely not force people to use them, but if editors use them appropriately that is also fine. I feel that inboxes and tables are good uses. Perhaps *not* inline text *for the moment* - we need to still make Wikipedia useful to casual editors and this is likely a step too far. However a table in the text is fine. With the original RfC being done in 2013 (as noted above), it is likely a good time to revisit the topic. I think we should use structured data in tables to help WP articles, and the benefit is that using it consistently means that updating information in WikiData updates it on all language Wikipedias (?potentially even other wikis such as WikiVoyage). The downside is single point of failure; however also single point of fixing - this may need other policies e.g. only logged in edits on WikiData. However may be better for consistency than some pages in WP where information on the same topic is markedly different as pages have not all be updated simultaneously. The application to lists for data is something I'm equivocal about. I hate a lot of list pages and think they should be better categorised, however there are supporters and detractors to this method of organisation as well. I do not like deleting referenced information, and if there was a way of archiving and easily searching it via WikiData I would be all for that. It would be nice if in future a "WikiData Explorer" page type was created where we could just pass it a search string to autogenerate data so we could get rid of lists. This is one for the future. However in the meantime I think we need to at least try improving our use of structured data - not ban but also not force its use. And if it doesn't work go back to normal tables. I quite like the WikiData sourced list of dams provided by the OP. Out of interest for User:Fram - I looked at the example you gave at List of learned societies in Australia. It was interesting as I think the table is generated by passing individual IDs - my futurist hat btw would be looking at this and saying in future it should be "table = learned society + based in australia -> autogenerate table with these fields". Why is this not a case of taking the ID code pointing to the wikidata entry out of there? This kind of error would also be made if manually creating the table, and isn't a commentary on why not to use wikidata for information. It's more a comment on how if you're not careful incorrect information can be put in any type of table, and what I get out of this is that if we truly passed a query to a database (if we made sure we had properly structured data) the presented information would be "better". Or have I missed the point here? - Master Of Ninja (talk) 07:42, 14 October 2022 (UTC)
- Thanks for sharing your comments.
- No one is suggesting using data for inline text, and I can't think of a situation when that could be appropriate.
- The reason that each row of the table is produced seperately is to allow human editors to override the data with locally defined content.
- I agree completely with your comments on keeping tables updated.
- There are all sorts of ways to browse Wikidata already, and Wikipedia is not really needed for that. See wikidata:Wikidata:Tools/Visualize data for ideas.
- I can see the possible benefit, if someone is searching for a list which we do not yet have on Wikipedia, of linking to an automatically generated list. But there would be a lot of technical and policy issues to navigate.
- — Martin (MSGJ · talk) 12:21, 14 October 2022 (UTC)
- Thanks for sharing your comments.
- Not only does Wikidata have questionable sourcing and verifiability policies not fully compatible with Wikipedia, but I wonder if folks would consider whether it's worth the trouble to make editing list pages even more complicated than they already are? I hate having to jump back and forth between Wikipedia and Wikidata just to manage interwiki links, and it would be an absolute nightmare if it was allowed to make up significant chunks of actual list content. Just say no to more complex articles, so we can focus more on encyclopedic content and less on formatting or template garbage. As for the idea that Wikidata is easier to edit than Wikipedia... I am highly skeptical of this claim, given that I think the average person couldn't even define what a knowledge graph is, much less find out how to add a statement to a Wikidata page. For new and anonymous editors in particular, it is likely extremely confusing to click edit on a cell in a Wikipedia list and then be taken to the read mode of an entirely different website that 99% of our readers have probably never heard of at all. Steven Walling • talk 20:41, 17 October 2022 (UTC)
- On a procedural note: it seems clear from previous RFCs that existing consensus is toward disallowing Wikidata use in articles. It should almost certainly be removed from any existing lists unless and until a new consensus supporting it develops. Steven Walling • talk 21:01, 17 October 2022 (UTC)
- Sorry for late comment but I only just saw this discussion. As an occasional compiler of lists of power stations in non-English speaking countries I support the use of Wikidata in lists. There are often new or retired power stations and keeping such a list up to date in 2 languages is too much work without Wikidata. Chidgk1 (talk) 19:10, 30 October 2022 (UTC)
- But I just looked at the template mentioned and I am pretty sure I will not use it as it seems more work than {{Wikidata list}}. I will just leave the English article out of date unless {{Wikidata list}} is allowed here Chidgk1 (talk) 19:47, 30 October 2022 (UTC) *
- It might be easier for some editors to pull data from WD, but using it in a WP article can make it impossible for other editors to edit.
- But I just looked at the template mentioned and I am pretty sure I will not use it as it seems more work than {{Wikidata list}}. I will just leave the English article out of date unless {{Wikidata list}} is allowed here Chidgk1 (talk) 19:47, 30 October 2022 (UTC) *
- To share my own experience … I went to WD and simply could not figure out how to edit it. I don’t even understand its basic structure, much less it’s coding. I was completely baffled. The thing is, Wikipedia is supposed to be an encyclopedia that anyone (including me) can edit. When an article pulls data from WD, it means that I simply can not edit that data. That is a fundamental flaw. Blueboar (talk) 19:51, 30 October 2022 (UTC)
- This unfortunately is my experience too. The idea of Wikidata seems so good, put having tried to use it the implementation of that idea is terrible. That is aside from the implementation of interfacing in Wikipedia to Wikidata. The chances of a new editor trying to edit a Wikipedia page being aware, let alone able, to edit Wikidata to achieve there edit is zero. I have also struggled with trying to edit Wikidata, and having to do so to fix minor issue is a major headache. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:03, 5 November 2022 (UTC)
- To share my own experience … I went to WD and simply could not figure out how to edit it. I don’t even understand its basic structure, much less it’s coding. I was completely baffled. The thing is, Wikipedia is supposed to be an encyclopedia that anyone (including me) can edit. When an article pulls data from WD, it means that I simply can not edit that data. That is a fundamental flaw. Blueboar (talk) 19:51, 30 October 2022 (UTC)
- Strongly support allowing the use of Wikidata and {{Wikidata list}} in lists. I'll make my case in the first paragraph, and respond to opposition in the second one.
- Wikidata gives us an enormous advantage: structured data. It'll be highly beneficial to transition more content to Wikidata anyway, thanks to the fantastic meta:Abstract Wikipedia project. It improves verifiability and reliability across Wikipedias (since all data is in one place); allows editors from all languages to contribute to the same database, which automatically gets updated across all Wikipedias (reducing Anglo-centric bias); and will likely help these very low-visibility articles stay "fresh". Using more structured data is vital to reducing our maintainability burden, saves tons of time with adding images and data on separate Wikipedias, and future-proofs the encyclopedia for projects like Abstract Wikipedia.
- Most of the counterarguments I've seen result from current deficiencies in Wikidata. That doesn't mean we shouldn't use it; we should seek to improve it. It's a collaborative Wikimedia project too, not some kind of exogenous imposition. Some Wikidata pages can't be edited by even established editors here, who lack user rights on Wikidata, due to semi-protection; that should be fixed by switching to a "pending changes" or "edit request" model. Wikidata being edited on a separate website, not here, is a good thing, since it makes it clear that people are changing the structured data, not its presentation. I find {{Wikidata list}}s significantly easier to edit. Some criticized Wikidata's verifiability policy, but they're explicitly based on enWiki's guidelines.
- I'm only addressing whether Wikidata should be blanket-banned in tables/lists; not whether it should be mandated. Page-specific consensus still reigns; I just don't want the consensns of a few dozen editors here (you gotta concede this is a low-visibility page) to bind our hundred thousand active editors. DFlhb (talk) 09:30, 8 November 2022 (UTC)
- Unfortunately the discussions to include also have low participation as well, and of course WP:LOCALCONSENUS. Maybe it's time to have a site wide discussion of somesort. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:45, 8 November 2022 (UTC)
- This is a sitewide discussion. * Pppery * it has begun... 17:50, 8 November 2022 (UTC)
- Nevermind. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:14, 8 November 2022 (UTC)
- This is a sitewide discussion. * Pppery * it has begun... 17:50, 8 November 2022 (UTC)
- Unfortunately the discussions to include also have low participation as well, and of course WP:LOCALCONSENUS. Maybe it's time to have a site wide discussion of somesort. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:45, 8 November 2022 (UTC)
- I should start with a disclaimer that I primarily (really, these days *exclusively*) edit on Wikidata and have 200k edits there between me and my bot account. So my comment is not from the perspective of an ENWP editor (although I do read ENWP regularly). That said, I obviously support usage of Wikidata on all Wikipedias, as the Wikidata community - in collaboration with many other WPs including ENWP - has invested a lot of time and energy into collecting a fairly massive depot of data, with citations (though, citations are admittedly somewhat less common in Wikidata vs ENWP currently, sadly) and images. Having the ENWP community and many smaller Wikipedias involved in the collection and validation of the data has been a huge help over the years. It seems that a lot of the concerns here are around tooling and software issues that can ultimately be fixed by improvements to the templates, the Lua scripting tools, and other improvements to the MediaWiki and Wikibase codebases. It'd be a shame to miss out on the ability to optimize list maintenance and leverage data across all language Wikipedias rather than improve the tooling itself. Unfortunately, I admittedly don't have a great solution for getting those improvements to happen short of either convincing WMF folks of its importance or doing it ourselves. Nicereddy (talk) 17:36, 19 November 2022 (UTC)
- Is there any evidence that the existence of Wikidata lists on the English Wikipedia actually inspires people to make useful edits to Wikidata, rather than just give up? * Pppery * it has begun... 17:51, 19 November 2022 (UTC)
- Is there any evidence to suggest the opposite? Nicereddy (talk) 18:18, 19 November 2022 (UTC)
- The fact that people such as Blueboar in this very discussion have complained about being unable to figure out how to make the needed edits to Wikidata is good enough evidence for me. * Pppery * it has begun... 18:21, 19 November 2022 (UTC)
- Yup… as I said above, I took a look at editing WD and quickly became too confused to continue. Quickly gave up. Blueboar (talk) 18:36, 19 November 2022 (UTC)
- More confused than the first time you tried to navigate a template-filled Wikipedia article pre-Visual Editor? The most difficult thing about editing Wikidata is knowing which properties to use. With a list, however, you're typically just working with one or two that have been predefined. I'm curious where the complexity was? (Not saying there can't be a learning curve, but it doesn't seem too advanced for the average Wikipedian. — Rhododendrites talk \\ 13:54, 21 November 2022 (UTC)
- I can't reply for Blueboar, but for me, yes, it is very confusing: and comparing it with a "template-filled Wikipedia article" is not really fair. One can easily create an article on Wikipedia, and then start learning the ropes. On Wikidata, the complexity jumps are a lot larger in my view. I just took a link from one of the lists we discuss here, Anthropological Society of Victoria, Wikidata link. When I try to add the year it was founded, I suppose I need to use "inception". So far, sp good. Then add a reference to the year 1934: some properties I can find through gambling, some others I have no idea what they are called so I can't add them. IF I then want another fact from the same reference (e.g. the first chairperson, Henry Gencoult-Smith), then I have to readd the same fields all over again, and I'm rewarded with a pink box around the name because Wikidata doesn't have that name yet. Adding a reference on enwiki is a lot simpler. Then it merged in 1976 with the Archaeological Society of Victoria (A) to form the "Archaeological and Anthropological Society of Victoria" (B). Is this "part of (merged with)"? No, it merged with (A), but this property seems to expect (B). Or was it "merged into"? No, that only applies if (B) had already existed before the merger. And so on, and so on... Fram (talk) 14:21, 21 November 2022 (UTC)
One can easily create an article on Wikipedia
- For a newbie? Without Visual Editor?some others I have no idea what they are called so I can't add them
- sort of like Wikipedia categories, or Wikipedia templates, or Wikipedia help pages, or Wikipedia style conventions.then I have to readd the same fields all over again
- When you create multiple Wikipedia articles, you do not have to create the same sections, infoboxes, etc. again?rewarded with a pink box around the name because Wikidata doesn't have that name yet
like linking to a red link? I'm not trying to pretend as though Wikidata is a delightful and intuitive interface. Figuring things out is a pain, like Wikipedia was for the non-savvy in its early years. Of course, you can just write something on Wikipedia where you can't on Wikidata, but we don't typically take kindly to people just writing something around here these days (unformatted, with the wrong tone, without references, etc.). Wikipedia has a lot more to understand when it comes to rules, conventions, expectations, etc. Wikidata is frustrating for its lack of obvious properties, but that's 90% of what a typical user does on Wikidata -- find/create an item, find a property, insert a value, repeat. I just have a hard time thinking that anyone could put in a tiny fraction of the time it takes to become a savvy Wikipedia playing with/learning to understand Wikidata and still have trouble updating a list. If we expected people to develop data models, propose new properties, and sync up metadata fields while importing a new database, then sure, but updating a list is just a couple simple properties. Would it be better if it were integrated into Wikipedia and more intuitive? Sure, but I just don't see the people slinging nested template parameters and quoting style guides as the "it's too hard to search for a property and insert a value" type. — Rhododendrites talk \\ 02:58, 22 November 2022 (UTC)
- I can't reply for Blueboar, but for me, yes, it is very confusing: and comparing it with a "template-filled Wikipedia article" is not really fair. One can easily create an article on Wikipedia, and then start learning the ropes. On Wikidata, the complexity jumps are a lot larger in my view. I just took a link from one of the lists we discuss here, Anthropological Society of Victoria, Wikidata link. When I try to add the year it was founded, I suppose I need to use "inception". So far, sp good. Then add a reference to the year 1934: some properties I can find through gambling, some others I have no idea what they are called so I can't add them. IF I then want another fact from the same reference (e.g. the first chairperson, Henry Gencoult-Smith), then I have to readd the same fields all over again, and I'm rewarded with a pink box around the name because Wikidata doesn't have that name yet. Adding a reference on enwiki is a lot simpler. Then it merged in 1976 with the Archaeological Society of Victoria (A) to form the "Archaeological and Anthropological Society of Victoria" (B). Is this "part of (merged with)"? No, it merged with (A), but this property seems to expect (B). Or was it "merged into"? No, that only applies if (B) had already existed before the merger. And so on, and so on... Fram (talk) 14:21, 21 November 2022 (UTC)
- More confused than the first time you tried to navigate a template-filled Wikipedia article pre-Visual Editor? The most difficult thing about editing Wikidata is knowing which properties to use. With a list, however, you're typically just working with one or two that have been predefined. I'm curious where the complexity was? (Not saying there can't be a learning curve, but it doesn't seem too advanced for the average Wikipedian. — Rhododendrites talk \\ 13:54, 21 November 2022 (UTC)
- Yup… as I said above, I took a look at editing WD and quickly became too confused to continue. Quickly gave up. Blueboar (talk) 18:36, 19 November 2022 (UTC)
- The last few times I added/updated properties in Wikidata, as I recall I went down a rabbit hole to ensure that all the corresponding Wikidata items were in place to document the citation. I don't know if this has gotten easier since then. It's a large overhead that has discouraged me from editing Wikidata further. isaacl (talk) 21:07, 19 November 2022 (UTC)
- I have struggled with making Wikidata edits in the past, to the point where I have now given up trying to do so in the future. Loopy30 (talk) 23:23, 19 November 2022 (UTC)
- The fact that people such as Blueboar in this very discussion have complained about being unable to figure out how to make the needed edits to Wikidata is good enough evidence for me. * Pppery * it has begun... 18:21, 19 November 2022 (UTC)
- Is there any evidence to suggest the opposite? Nicereddy (talk) 18:18, 19 November 2022 (UTC)
- Is there any evidence that the existence of Wikidata lists on the English Wikipedia actually inspires people to make useful edits to Wikidata, rather than just give up? * Pppery * it has begun... 17:51, 19 November 2022 (UTC)
- Unless you can edit Wikidata lists on Enwiki, I'd be against using them in articles. There's this from 2013 that says that local editing is planned, but it's still not a thing nearly a decade later apparently. ♠JCW555 (talk)♠ 18:01, 19 November 2022 (UTC)
- You can't (yet!) edit Wikidata from within Wikipedia - the project is mw:Wikidata Bridge but it seems to have stalled. However the Wikidata item is just one click away from the Wikipedia article. It's a bit like images which are hosted on Commons - they are also one click away. I don't see why this should be a barrier to using Wikidata as we are well accustomed to working with Commons. — Martin (MSGJ · talk) 20:32, 22 November 2022 (UTC)
- I don't do anything with images, so this comparison to Commons isn't applicable to me. Bottom line: I feel like everything on English Wikipedia should be editable on English Wikipedia, including lists and tables. I shouldn't have to go to another site to edit tables/lists on Wikipedia. ♠JCW555 (talk)♠ 20:49, 22 November 2022 (UTC)
- You can't (yet!) edit Wikidata from within Wikipedia - the project is mw:Wikidata Bridge but it seems to have stalled. However the Wikidata item is just one click away from the Wikipedia article. It's a bit like images which are hosted on Commons - they are also one click away. I don't see why this should be a barrier to using Wikidata as we are well accustomed to working with Commons. — Martin (MSGJ · talk) 20:32, 22 November 2022 (UTC)
- Note: I have nominated Template:Wdtable row for deletion because, whatever one's opinion about Wikidata lists, I don't believe a template which is incompatible with Visual Editor editing should be allowed. All opinions welcome at the TfD of course. Fram (talk) 09:33, 30 November 2022 (UTC)
- Note: The discussion was closed as keep. {{u|Sdkb}} talk 03:56, 9 December 2022 (UTC)
- I edit at Wikidata, but I think that making an article solely based on an auto generated list is laziness. An auto generated list might complement an existing article but should not be the sole content of one. My only exception would be if the list was so large it would not fit on the main topic's article page. RPI2026F1 (talk) 03:03, 6 December 2022 (UTC)
- I tend to agree, and yet a "lazy" list is probably better than no list at all, and a maintained list is definitely better than an unmaintained list. The best lists we have tend to combine data and prose. — Martin (MSGJ · talk) 07:25, 6 December 2022 (UTC)
- I never said we should ban lazy lists, I just said they should be merged in with the main topic unless the size of the autogenerated list prevents it from being included in the main topic. RPI2026F1 (talk) 02:17, 9 December 2022 (UTC)
- I tend to agree, and yet a "lazy" list is probably better than no list at all, and a maintained list is definitely better than an unmaintained list. The best lists we have tend to combine data and prose. — Martin (MSGJ · talk) 07:25, 6 December 2022 (UTC)
- Strong oppose, As a massive proponent of One version of the truth in real life; I'd love to say I like this idea. But I don't think it will work practically; I have 3 main issues
- Verifiability. Wikidata has a different value of 'Truth' than Wikipedia. The 'List_of_dams_in_Kanagawa_Prefecture' fails WP:V on face value (no references), and worst of all, it fails WP:V covertly, people will see 'Wikidata' and assume it's right, but if you dig 3 or 4 clicks into the 'reference' you see things like the 'Elevation' of 'Doshi Dam' being 'referenced' to 'Cebuano Wikipedia' (No article link, no 3rd party source) and the height being referenced to the ENW article (and Wikipedia:Wikipedia_is_not_a_reliable_source) . This could be fixed in wikidata with the reference being changed to the original source, but even then, experienced editors will find it hard to see that the data is poorly referenced and have to click each record individually to see the sourcing. Worse, readers looking for the original source so they can validate the information for themselves (as many students are told to do, for example) won't know where to start. Why would they click a 'pencil' to edit something, to find the source?
- We might not WANT one version of the truth; using wikidata breaks WP:Consensus on content; what if, hypothetically, the editors on wikipedia agree that 'Doshi Dam' is 117 Metres tall, but the WikiData editors disagree? (Or more likely agree on a different definition of 'Height', for example)
- Using templates breaks the flexibility of the article, editing a template is a massive pain; say we decide by consensus that (random example) 'Dams in the UK' should have a 'Nation' column, it would be impossible for the average visual editor user to make this happen, especially if we want to add facts that aren't on WikiData. JeffUK 15:05, 3 January 2023 (UTC)
- It's routine to make Wikidata-based templates not include statements that are either unsourced or sourced only to a Wikipedia; this is already done, for example, in {{Infobox person/Wikidata}}. Facts that aren't on Wikidata (though they can and should be added to Wikidata, of course) and those that are at variance with what Wikidata records are also routinely included in Wikidata-based templates; same example applies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:13, 3 January 2023 (UTC)
- That's less of an issue for single instance things like info boxes though; as it's 'opt-in' per property/parameter; and once a person has a sourced biographical property, it's unlikely to become unsourced. However, if you have lists of things, where some of them have a source for one particular property, and some don't (and new entrants may appear in either state) you either end up with a list page that's missing loads of entries, or someone has to manually fiddle with the wiki markup to hard-code sourced data back in again (then you get some entries which update automatically, and some that don't, which is absolutely the worst possible case), or the editor must go to WikiData to add the information over there and I don't think participation in another site should be mandatory. Either way it's a barrier of entry to editing boldly. JeffUK 19:01, 3 January 2023 (UTC)
- It's routine to make Wikidata-based templates not include statements that are either unsourced or sourced only to a Wikipedia; this is already done, for example, in {{Infobox person/Wikidata}}. Facts that aren't on Wikidata (though they can and should be added to Wikidata, of course) and those that are at variance with what Wikidata records are also routinely included in Wikidata-based templates; same example applies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:13, 3 January 2023 (UTC)
- @JeffUK you raise the issue of cross-wiki disagreements, using dam height as a random example. If I may suggest better examples, we seriously do not want cross-wiki warring on things like nationality or gender. I've dealt with more than enough Russians shoving "Jewish" into Nationality fields, and I sure as heck don't want to waste all my time warring with transphobe-majority communities. Alsee (talk) 00:39, 7 January 2023 (UTC)
- So your preferred approach for a project that aims to document all of human knowledge is to shut out non-English speakers because some of them have objectionable views? {{u|Sdkb}} talk 06:26, 7 January 2023 (UTC)
- I have no idea where that strawman came from. I said, quote, do not want cross-wiki warring. Cross-wiki warring is especially disruptive. "Non-English speakers with objectionable views" aren't locked out of anything. They are free to argue their case on whatever wiki they actually edit.
On a related note, I am appalled that the WMF was so clueless and misguided as to deploy the existing Wikidata integration such that Wikidata edits BYPASS/OVERRIDE our local page protections. If an infobox (or anything else) uses Wikidata, a vandal/troll/POVwarrior can defeat our Full-Page-Protection by shoving arbitrary text into a field on Wikidata and purging the linked Wikipedia page. Not only does it bypass page protections, it's impossible for a Non-admin to fix it without going to Wikidata. In other words it is effectively for most editors to fix it at all, because most editors have no idea Wikidata even exists. Alsee (talk) 06:34, 10 January 2023 (UTC)
- That is truly awful. BUT It did make me wonder whether we could do something similar in the other direction as an initial step; make it impossible to change end wikipedia referenced data in Wikidata (protect a section). (Actually, Is that possible to do in wikipedia?)
- All up, the way the different Wiki systems integrate is very unclear at least to me.
- For instance
- * Are there permanent integrations in wikidata to external databases, or is everything a once off?
- * When I look at the references on Wikidata, the top level URL is listed but not the source. I would have expected a recipe/script, and an auto check for updates.
- * There are a lot of items with 0 references if an infobox has no reference for something, does it get created in Wikidata as a 0reference? Can you tell that this has happened
- * If there is conflicting Wiki data between say en and de different wikipedia, which does es choose?
- * If editors are using translation software and dumping it in to their wikipedia, is Wikidata needed? (although machine translated pages that are never updated is another issues) Wakelamp d[@-@]b (talk) 10:13, 10 January 2023 (UTC)
- @Wakelamp,
- Anything in Wikidata is stored on Wikidata, i.e. the data may have been obtained from an external database at some point, but it will not be automatically updated unless via a bit
- I'm not sure what you mean by this - as far as I know, references are just a URL
- Again unclear, but I think you are referring to how data from Infoboxes is exported to WD. Typically the tools for this just say [imported from page foo at oldid bar]
- If you're referring to the data on WD, it is the same for all languages. If you're referring to importing data, this is done manually (semi-automatically), so a user will choose.
- One of the differences between MediaWiki (the software behind Wikipedia, largely developed by the WMF) and Wikibase (the software behind Wikidata, largely not developed by the WMF) is that Wikidata entries can have multiple answers for the same point. To use the example started by @JeffUK, Wikidata can simultaneously say that the height of Doshi Dam is 177 m, 194 yd, 600 ft, and 175 m, with separate sources cited for each number, and an editor-chosen priority level for which one (if any) should be preferred. It is not necessary to have only one version of "the truth" in Wikidata; you can instead choose which one you believe is most relevant. Whatamidoing (WMF) (talk) 22:55, 11 January 2023 (UTC)
- Of course, this doesn't solve the problem, as the template has to decide which of the multiple conflicting sources of truth to show (or show all of them). The module being discussed here seems to do the latter approach, which may not be what is wanted locally. * Pppery * it has begun... 01:33, 12 January 2023 (UTC)
- @Wakelamp,
- @Alsee, surely the is like templates, even if most editors are less familiar with it. I don't think it's within the WMF's responsibility to decide who this is used in articles - this can be done locally. — Qwerfjkltalk 20:57, 10 January 2023 (UTC)
- I have no idea where that strawman came from. I said, quote, do not want cross-wiki warring. Cross-wiki warring is especially disruptive. "Non-English speakers with objectionable views" aren't locked out of anything. They are free to argue their case on whatever wiki they actually edit.
- So your preferred approach for a project that aims to document all of human knowledge is to shut out non-English speakers because some of them have objectionable views? {{u|Sdkb}} talk 06:26, 7 January 2023 (UTC)
- My concerns have already been brought up repeatedly above, but I oppose the creeping in of content that fundamentally cannot be verified and edited on Wikipedia. Wikidata might be more user friendly in isolation, but it's not on Wikipedia, which makes it extremely user-hostile. The use of WikiData has absolutely crept past community accepted bounds and should be reined in. Der Wohltemperierte Fuchs talk 01:26, 12 January 2023 (UTC)
Poor tooling
The arguments here are transferable to a number of other sister projects, like Commons, which suffer from many more problems than enwp and wikidata, including low adminship, tooling, limited i18n and yet it is the standard way to insert images in enwp, despite the built in tooling that enwp has for hosting files. If the goal is to solely focus on enwp and screw other language editions of Wikipedia, then yes wikidata/commons can feel like overkill at times. Wikidata is one of the few projects, that leverage the knowledge and expertise of non English editors, that can directly benefit enWP, and likewise allow english editors to benfit other language editions. We should celebrate that instead of admonishing it. I am sympathetic to many comments here, about difficulty in editing, and leave the recommended/preferred solution per specific articles (list of plants versus evolving breaking news section). ~ 🦝 Shushugah (he/him • talk) 15:25, 8 November 2022 (UTC)
- Absolutely. A lot of systemic bias toward the English-speaking world tends to come through in discussions like this, with editors failing to realize how much content we lack in non-English speaking areas and how much Wikidata could help us there. Reminder: Two thirds of all topics covered on Wikipedia don't have an article in English. {{u|Sdkb}} talk 16:12, 8 November 2022 (UTC)
- Yes! Thank you for making this point. ENWP is able to be self-sufficient due to the large English-speaking community, but that isn't true of many languages outside the top 10 or 15 largest Wikipedias. Being able to pull data from Wikidata to get up-to-date information is really useful for smaller communities, and having the large community of ENWP helping verify and maintain that information along with the Wikidata community and the communities of other language WPs would be a huge boon. Nicereddy (talk) 17:26, 19 November 2022 (UTC)
- If this is the outcome you'd like the I suggest listening to user issues with using Wikidata and the issue that Wikidata can cause to Wikipedia. That way more editors will start and continuing using Wikidata. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:31, 22 November 2022 (UTC)
I expect few, if any, opponents are going to see 'new tooling' as solving anything. However anyone could of course start an RFC to determine whether the new tools lead to a more favorable change in consensus, if/when such 'new tooling' actually exists. Until then we have the inherent downsides of using Wikidata combined with tools and support that even Wikidata-advocates acknowledge are bad. Alsee (talk) 17:49, 9 December 2022 (UTC)
- I like the idea of a new tool/data type - if the problem is edit control, referencing, and different guidelines, Why couldn't we just use a wikidata structure in a separate instance linked to enW?
Maybe there is some money as Wikidata has now got an extra USD 2.4 million in the updated Annual Plan 22/23 budget as part of the 17 to 28 % increase in funding "representing inflationary and other year-on-year costs" Do people know why it is such a priority for WMF? Is it auto create of articles using lambda functions in other languages, or high status because of GLAM projects, or selling access, or ,,,??? Wakelamp d[@-@]b (talk) 06:55, 10 December 2022 (UTC)- @Wakelamp while a local Wikidata instance would solve issues with administrative control, referencing, policies&guidelines, that would wipe out the entire argument in support of it. The entire rationale for stripping this content completely out of EnWiki's control was to create a single shared global database. The justification is for other wikis to benefit from any work we do editing Wikidata, and for us to benefit from work done by others there. Creating and using a local version would leave us with all of the increased complexity and difficulties of the additional system, in exchange for pretty much no purpose or benefit for anyone.
- While I may disagree with Wikidata enthusiasts on the cost-benefit trade-off of using Wikidata here, I'm pretty sure they'd hate the idea of local instances. I understand the benefits they're trying to pitch. They want to suck up as much data as possible into a single centralized system... and to pipe that data out to as many places as possible. A local instance defeats the entire point. It's all about pushing everyone to become a Wikidata editor, centrally editing everything at Wikidata. Their project is so super-duper amazingly great that they think everyone at every Wikipedia on the entire planet should be feeding and serving their project. Alsee (talk) 03:31, 12 December 2022 (UTC)
- @Msgj @Fram Many of the comments are about process (reliable references, etc ) and systems (how can we update in enWikipedia transparently, history) and single source of truth (Wikidata was in part created using enWikipedia data, GLAM databases).
- What would you both think of having an interim option of en wikipedia having it’s own wikibase instance updated by en editors using our guidelines?
- Looking at the opposite direction from en WP to Wikidata, @Ser Amantio di Nicolao @User:BrownHairedGirl. I think you both do a lot of categoriustion, and my apologies in advance if i am incorrect.
- Is Wikidata the reason for the increase in complex intersection categories in Wikipedia? And what do you if the categoristion/infoboxes/lexemes (?) are different between the 2 systems? ~~ Wakelamp d[@-@]b (talk) 10:46, 17 December 2022 (UTC)
- I'm very reticent about getting involved here, but I do think we have to look at this from the perspective of a typical Wikipedia reader, and their experience. They almost certainly arrive via Google, and all they do is read. They never use categories explicitly, and tend only to look at lists if they googled for a list. They use links to jump to related articles, and disambiguation pages if their Google search wasn't specific, but that's about it. They look at an article as an integrated whole, and it would never occur to them that the infobox isn't part of the article, or might be following a different set of rules about referencing and data-integrity. There is no logic whatsoever in deciding that a birthdate in an infobox can be derived from wikidata but outside an infobox it can't; from the reader's perspective, both are just birthdates in an article. But our readers do care about being given accurate data. The point about wikidata is that if the world is behaving properly, a lot of French editors will be noticing problems in French data and correcting them; if we decide to go our own way and use our own data, all those French corrections will pass us by, and we'll carry on showing bad data, relying on a tiny number of English-language editors who happen to have a foot in French matters. Or, in the less-likely event of one of those English editors spotting a problem with a French data-item, our correction won't benefit the French Wikipedia. Together, we can curate data much better. Elemimele (talk) 10:27, 22 December 2022 (UTC)
- I agree in principle that it would be awesome if we have one repository of verified facts that we could use in multiple projects. But in reality, Wikidata has 23,890 active users, Wikipedia has 116,976 active editors, and consistently more than 50,000,000 unique visitors (devices) every day who can become an editor the second they see something that they know is wrong. That's a hell of a lot more eyeballs finding and fixing incorrect data. and reducing barriers to entry for those millions of people to make edits is surely the most important? Of course if we could have some way to integrate them, such that a 'data list' on Wikipedia is synchronised with wikidata, which in turn can be consumed by other wikis, that would be awesome, but the technology isn't there right now. JeffUK 10:55, 4 January 2023 (UTC)
- @JeffUK the issue is worse than that. stats.wikimedia.org puts Wikidata "active editors" at 12 thousand, but Wikidata editor stats are severely inflated. Edits on other wikis, such as page moves, may trigger bot clone-edits updating Wikidata links to those pages. Those bot edits get attributed to the person who made the edit elsewhere. They have only a few thousand genuine active editors and over a hundred million Wikidata-items. Wikidata culture is primarily about sucking up as much data as possible, preferably with bulk bot edits. The actual community far too small to meaningfully patrol content quality or vandalism, even if they did consider it a priority. They have few content policies. The only reason they created a fig-leaf BLP policy is because their long-standing failure to create one was dragging their reputation through the gutter. Alsee (talk) 04:53, 7 January 2023 (UTC)
- I agree in principle that it would be awesome if we have one repository of verified facts that we could use in multiple projects. But in reality, Wikidata has 23,890 active users, Wikipedia has 116,976 active editors, and consistently more than 50,000,000 unique visitors (devices) every day who can become an editor the second they see something that they know is wrong. That's a hell of a lot more eyeballs finding and fixing incorrect data. and reducing barriers to entry for those millions of people to make edits is surely the most important? Of course if we could have some way to integrate them, such that a 'data list' on Wikipedia is synchronised with wikidata, which in turn can be consumed by other wikis, that would be awesome, but the technology isn't there right now. JeffUK 10:55, 4 January 2023 (UTC)
- I'm very reticent about getting involved here, but I do think we have to look at this from the perspective of a typical Wikipedia reader, and their experience. They almost certainly arrive via Google, and all they do is read. They never use categories explicitly, and tend only to look at lists if they googled for a list. They use links to jump to related articles, and disambiguation pages if their Google search wasn't specific, but that's about it. They look at an article as an integrated whole, and it would never occur to them that the infobox isn't part of the article, or might be following a different set of rules about referencing and data-integrity. There is no logic whatsoever in deciding that a birthdate in an infobox can be derived from wikidata but outside an infobox it can't; from the reader's perspective, both are just birthdates in an article. But our readers do care about being given accurate data. The point about wikidata is that if the world is behaving properly, a lot of French editors will be noticing problems in French data and correcting them; if we decide to go our own way and use our own data, all those French corrections will pass us by, and we'll carry on showing bad data, relying on a tiny number of English-language editors who happen to have a foot in French matters. Or, in the less-likely event of one of those English editors spotting a problem with a French data-item, our correction won't benefit the French Wikipedia. Together, we can curate data much better. Elemimele (talk) 10:27, 22 December 2022 (UTC)
RfC on establishing a policy exclusively for British monarch article titling (withdrawn)
We propose that English, Scottish, Irish and British monarchs from William II of England onwards[a] should always conform to the "[Name][Ordinal] of [Country]" or "[Name], [Queen/King] of [Country]" format, without exception.
Reasons given by Tim O'Doherty
- 1. It should not matter if the shortened version, e.g. "Elizabeth I" is more commonly used. The article titles for UK monarchs are becoming inconsistent, a violation of the policy WP:CONSISTENT which states "
We strive to make titles on Wikipedia as consistent as possible with other titles on similar subjects.
" This means that if passed, all British monarch's pages should be moved to the aforementioned format, e.g. Elizabeth I → Elizabeth I of England
- 2. Far more monarchs use the aforementioned format rather than the "[Name] [Ordinal]" format: 27 do, with only 12 not and 2 using neither format, those being James VI and I and Queen Victoria.[c]
- 3. If moved, the old titles would become redirects (e.g. Elizabeth I would still redirect to Elizabeth I of England) so that the everyday Wikipedia user has the same ease of navigation between the articles.
- 4. The guideline WP:SOVEREIGN states "
kings, queens regnant and emperors and empresses regnant who are known as "first name + ordinal"...have article titles in the form "{Monarch's first name and ordinal} of {Country}".
" We propose to make this policy specifically for British monarchs.
- 5. If accepted, this policy should override WP:COMMONNAME on future RMs concerning such articles for the reasons mentioned above, and the fact that this is written specifically for British monarchs (and therefore have their pages in the best interest) whilst COMMONNAME does not.
- 6. Articles for monarchs that reigned from 1087 to 1707 should be titled "[Name] [Ordinal] of England". Articles for monarchs that reigned from 1707 to 1801 should be titled "[Name] [Ordinal] of Great Britain". Articles for monarchs that reign/ed from 1801 to the present day should be titled "[Name] [Ordinal] of the United Kingdom".
Reasons given by GoodDay
- 7. Elizabeth II & Charles III are most associated with the United Kingdom, they lived & live in that realm. Elizabeth II is buried in the UK, Charles III & his successors will most likely (in future) also be buried in the UK. Note - Because the UK is the primary resident realm? it has no governor-general.
Notes
- ^ For a full list, click here and here: the monarchs that this proposal covers begin at William II and end at Charles III and his successors. This is with the intentional exclusion of William the Conqueror and disputed monarchs such as Empress Matilda and Lady Jane Grey. Other persons on the two lists that are excluded from this proposal are as follows: Louis VIII of France, Philip II of Spain, Oliver Cromwell and Richard Cromwell. Also excluded is Henry the Young King.
- ^ James VI and I would, however, remain as is until further discussion on his article's talk page.
- ^ If accepted, Queen Victoria should move to Victoria, Queen of the United Kingdom.
Tim O'Doherty (talk) 17:20, 2 January 2023 (UTC)
Discussion - Articles on UK Monarchs
- I have no great interest in this topic, as I can support anything that makes it obvious what the title means, but I must say that I am very wary of anything that uses the words "always" and "without exception", especially if those words are bolded and especially if we immediately have to have exceptions spelt out in footnotes. It seems that this proposal is to apply "without exception" except in the cases where we have exceptions. Phil Bridger (talk) 17:40, 2 January 2023 (UTC)
- There is a clarification, not an exception. If you want the article titled James I of England and VI of Scotland then be my guest, but the reason as to why there really shouldn't be any exceptions is because this proposal is to bring consistency to British monarchs' articles. One exception leads to another, two exceptions is a precedent and then consistency unravels once more, which defeats the point. Tim O'Doherty (talk) 17:45, 2 January 2023 (UTC)
- William the Conqueror is an exception. Why does this proposal only start with William II, if not to create an exception? Phil Bridger (talk) 19:12, 2 January 2023 (UTC)
- I'm not maliciously creating an exception; it's easier to just begin with William II because he is the first monarch after the Norman Conquest to be styled with ordinals. I could add William the Conqueror, but he would just end up in point 2 as another that doesn't follow any other format, so there wouldn't be much point in it at all. Tim O'Doherty (talk) 19:24, 2 January 2023 (UTC)
- William the Conqueror is an exception. Why does this proposal only start with William II, if not to create an exception? Phil Bridger (talk) 19:12, 2 January 2023 (UTC)
- There is a clarification, not an exception. If you want the article titled James I of England and VI of Scotland then be my guest, but the reason as to why there really shouldn't be any exceptions is because this proposal is to bring consistency to British monarchs' articles. One exception leads to another, two exceptions is a precedent and then consistency unravels once more, which defeats the point. Tim O'Doherty (talk) 17:45, 2 January 2023 (UTC)
- I can think of no reason whatsoever why Wikipedia would need a policy on this particular matter. How is it any different from any of the umpteen other things that people find it necessary to bicker about? You can't create an encyclopaedia by formulating endless rules... AndyTheGrump (talk) 18:00, 2 January 2023 (UTC)
- But there is a need for consistency. Having RMs for monarchical articles every other week doesn't build an encyclopaedia either. It does no harm to have a policy on it. Tim O'Doherty (talk) 18:06, 2 January 2023 (UTC)
- You could write an essay/guideline, if it's good, people will buy into it even if it's not a policy. Selfstudier (talk) 18:10, 2 January 2023 (UTC)
- Yes, but it's not ideal as policy overrides guidelines and so, again, it defeats the point of creating a fixed standard for the titles. This policy proposal only really works if it is policy rather than guideline, otherwise I may as well not bother with it. Tim O'Doherty (talk) 18:19, 2 January 2023 (UTC)
- You could write an essay/guideline, if it's good, people will buy into it even if it's not a policy. Selfstudier (talk) 18:10, 2 January 2023 (UTC)
- But there is a need for consistency. Having RMs for monarchical articles every other week doesn't build an encyclopaedia either. It does no harm to have a policy on it. Tim O'Doherty (talk) 18:06, 2 January 2023 (UTC)
- I guess one concern I'd have is that this would effectively override the recent Charles III RM, which gained very wide participation before being closed in the negative, on whether to move the article to Charles III of the United Kingdom, discussion here, with the RM close upheld here, with the closer on that review (who has since passed an RfA) noting that the participation in the RM was "abnormally heavy". Possibly that result should be respected here.--Wehwalt (talk) 18:17, 2 January 2023 (UTC)
- I admit that did cross my mind (I even supported Charles III rather than Charles III of the United Kingdom) but I do think that broader consistency is more important than the result of an RM on one page. If this RfC is heavily interacted with as well, then that will sort the matter. Tim O'Doherty (talk) 18:23, 2 January 2023 (UTC)
- I doubt you'll get quite the number of opinions in such a short period ... would the policy ensure that the old names (say Charles III) remain redirects? I suspect there will be some seeking equal treatment for Charles III of Spain etc (as in the RM), who will be anxious to make Charles III a disambiguation page, as they suggested in the RM. Wehwalt (talk) 18:39, 2 January 2023 (UTC)
- Yes, they would, as point 3 states. Tim O'Doherty (talk) 18:43, 2 January 2023 (UTC)
- But William III and George I and George II and probably others point to disambiguation pages so there's still going to be inconsistency. Wehwalt (talk) 19:02, 2 January 2023 (UTC)
- That comes down to whether they are the primary topic or not, which is out of my control. Tim O'Doherty (talk) 19:03, 2 January 2023 (UTC)
- But William III and George I and George II and probably others point to disambiguation pages so there's still going to be inconsistency. Wehwalt (talk) 19:02, 2 January 2023 (UTC)
- Yes, they would, as point 3 states. Tim O'Doherty (talk) 18:43, 2 January 2023 (UTC)
- I doubt you'll get quite the number of opinions in such a short period ... would the policy ensure that the old names (say Charles III) remain redirects? I suspect there will be some seeking equal treatment for Charles III of Spain etc (as in the RM), who will be anxious to make Charles III a disambiguation page, as they suggested in the RM. Wehwalt (talk) 18:39, 2 January 2023 (UTC)
- I admit that did cross my mind (I even supported Charles III rather than Charles III of the United Kingdom) but I do think that broader consistency is more important than the result of an RM on one page. If this RfC is heavily interacted with as well, then that will sort the matter. Tim O'Doherty (talk) 18:23, 2 January 2023 (UTC)
- The policy that governs this is our WP:AT policy, which does list Consistency as one of the factors we must consider when determining the best title for an article. However, the policy makes it clear that we must also consider Recognizability, Naturalness, Precision, and Conciseness - and I am not at all sure that the proposal takes those other factors into consideration. Indeed, my experience is that, of these five factors, Consistency is arguably the weakest (the one most often over-ridden by the others). Blueboar (talk) 19:21, 2 January 2023 (UTC)
Issues I thought of immediately, there may be others:
- This is claimed to apply to English, Scottish, Irish and British monarchs from William II of England onwards. But it is not obvious why William II of England is a sensible starting point for Scottish monarchs or for High Kings of Ireland. It is also not clear why Welsh monarchs are not included.
- The argument for retaining William the Conqueror as an exception might legitimately apply to later monarchs such as Robert the Bruce. There are other Scottish, Welsh and Irish monarchs who are primarily known by names outside this pattern such as John Balliol and Owain Glyndŵr. There is also the case of Mary, Queen of Scots, who is almost never called Mary I, even though Scotland did have Mary II.
- After the Statute of Westminster, the Crown is split, so it is not clear that George V, Edward VIII, George VI, Elizabeth II and Charles III should be treated as monarchs solely of the United Kingdom.
- While James VI and I is treated as an exception, the parallel cases of James VII and II and William III and II are not treated as exceptions.
- British Monarchs started referring to themselves as monarch of Great Britain in 1604, long before the Act of Union. It is not clear whether this proposal intends to refer to these as kings and queens of Great Britain, of England, Scotland and Ireland, of England and Scotland, of England, of Scotland or something else.
- If they are to be called monarchs of something other than Great Britain it is not clear how Queen Anne fits in to this, given that she was monarch at the time of the union that created the Kingdom of Great Britain.
- If they are to be called monarchs of something other than England and Scotland or England, Scotland and Ireland it is not clear how James VI and I fits in to this, given that he had been King of Scots for 35 years by the time he inherited the English throne.
- It is not obvious why Scottish kings should be of Scotland and not of Scots.
- It is not obvious why Irish high kings should be King of Ireland and not High King of Ireland.
- There is an issue with Henry the Young King, who by this standard should presumably be Henry, King of England, a name that nobody will recognise.
- There is a question of whether Henry VI of England, by this standard should also be listed as a King of France, given the circumstances of the dual monarchy of England and France.
It appears to me that this is a proposal that tries to create consistency where consistency is not necessarily desirable, and thus I am inclined to oppose it. Kahastok talk 19:23, 2 January 2023 (UTC)
- Nobody's claiming that George V to Charles III are soley British Monarchs. We're merely pointing out that they've resided in & are mostly associated with the United Kingdom. It's not often (for example) that we read or hear about "King Charles III of Tuvalu" or "Queen Elizabeth II of Saint Lucia". GoodDay (talk) 19:35, 2 January 2023 (UTC)
- We did not mean Monarchs of England, Scotland and Ireland as the monarchs of the separate kingdoms, but monarchs of Britain that were at some point monarchs of those countries (e.g. George IV was King of the United Kingdom, which included England, Scotland and Ireland, but not the individual kingdoms of said countries). We are not dealing with monarchs who were only monarch of Scotland or Ireland, e.g. Mary, Queen of Scots. I did provide the list in the original statement, but apologies if the wording was not clear.
- All those examples listed are from the individual kingdoms, so see the paragraph above.
- They are primarily known as monarchs of the UK rather than the countries in the Commonwealth, as their leads state (e.g. "
Elizabeth II (Elizabeth Alexandra Mary; 21 April 1926 – 8 September 2022) was Queen of the United Kingdom and other Commonwealth realms
" puts clear emphasis on the fact that she was Queen of the United Kingdom). - They are not treated as "exceptions" because their articles are not titled as such...
- I am not the one responsible for this. Monarch's articles from 1604 to 1707 practically always have "of England" after then, e.g. Charles I of England, Charles II of England. I am simply continuing this, so the problem is not with this proposal.
- It is clear how Queen Anne fits into it as her article is called "Anne, Queen of Great Britain" and should continue to be titled as such.
- The proposal says that "James VI and I" should remain the title of his article.
- See paragraph one of this reply.
- See paragraph one of this reply.
- Apologies for not listing Henry the Young King in the first note. The proposal does not cover him.
- No, similar reasoning as given in the third paragraph of this reply. Tim O'Doherty (talk) 19:56, 2 January 2023 (UTC)
- I'm afraid that the proposal that then becomes, they all have to be consistent with this pattern, without exception except the ones that do not have to be consistent with the pattern.
- If there is some great need for consistency here, then James VI and I becomes a huge problem because the proposal admits that it remains as is, which is inconsistent with all the others. I do not think you can claim to be creating consistency without resolving that. And I feel your proposed guideline really needs to clear up the question of all of period from 1603-1707 if it's aiming to enforce consistency. I don't think saying well they're all already at [Name] [Ordinal] of England so they don't need to be covered is adequate - not least because I feel a guideline on this point should at least consider the fact that they were also Kings and Queens of Scots.
- I also don't see why the proposal should cover pre-Union monarchs from England, but not pre-Union monarchs from Scotland, Wales and Ireland. I note that only two articles for English pre-union monarchs are within scope and not already of the form [Name] [Ordinal] of England or [Name], King of England. These are James VI and I and Elizabeth I. And since James VI and I is excluded anyway, it's not obvious to me that adding Elizabeth I adds much. Perhaps if your proposal started from Queen Anne instead of William II it might better cover what you intend it to cover and get rid of a lot of the exceptions and oddities?
- And I am still concerned that there is a problem with acknowledging the UK and not the other Commonwealth Realms - at least after 1931. You say that the article starts with
Elizabeth II... was Queen of the United Kingdom and other Commonwealth realms
- well the implied article name in that case would surely therefore beElizabeth II of the United Kingdom and other Commonwealth realms
, which feels a bit of a mouthful. Kahastok talk 21:15, 2 January 2023 (UTC)- Why are you concerned? If we had to choose one of the realms, it would be the United Kingdom. I doubt a RM proposal to move to "Charles III of Australia" or "Charles III of Canada" would garner much support. Last time I checked, his coronation is going to be held in London, UK. It's not going to be repeated 14 more times, in each of the other realms' capitals. GoodDay (talk) 21:54, 2 January 2023 (UTC)
- I do not accept that we necessarily have to choose one of the 15 realms, and I feel that there are significant problems with doing so. Kahastok talk 17:38, 3 January 2023 (UTC)
- Just like before, you & I are likely never going to agree on this topic. GoodDay (talk) 17:48, 3 January 2023 (UTC)
- When was "before", exactly? I'm fairly certain I've never discussed naming of these articles before on Wikipedia, with you or otherwise. Kahastok talk 18:23, 3 January 2023 (UTC)
- Just like before, you & I are likely never going to agree on this topic. GoodDay (talk) 17:48, 3 January 2023 (UTC)
- I do not accept that we necessarily have to choose one of the 15 realms, and I feel that there are significant problems with doing so. Kahastok talk 17:38, 3 January 2023 (UTC)
- I have said that monarchs from 1087-1707 should by titled "[Name] [Ordinal] of England". I view James I as a sensible transition monarch between the pre-Union monarchs and the monarchs that reigned after the Union of the Crowns; it addresses that he was King of Scotland, but also the first King of Scotland to be King of England as well. The alternative is James VI of Scotland and I of England or James I of England. At a push, I'd go for the latter, but that would, no doubt, cause Scottish Wikipedians to (rightfully) protest, which is a situation best avoided and a situation that should be treated with tact.
- Why are you concerned? If we had to choose one of the realms, it would be the United Kingdom. I doubt a RM proposal to move to "Charles III of Australia" or "Charles III of Canada" would garner much support. Last time I checked, his coronation is going to be held in London, UK. It's not going to be repeated 14 more times, in each of the other realms' capitals. GoodDay (talk) 21:54, 2 January 2023 (UTC)
- And I am still concerned that there is a problem with acknowledging the UK and not the other Commonwealth Realms - at least after 1931. You say that the article starts with
- It only covers monarchs of England before 1603 because that is what the policy was written to do. There is no issue that needs fixed with Scottish monarchs, so no need to cover them in a policy.
- I used the opening sentence to rebut what you had said about the proposed titling not covering the other realms, I did not intend to imply that Elizabeth II's article should be called "Elizabeth II of the United Kingdom and other Commonwealth realms" as that is a pretty obvious violation of WP:CONCISE. Tim O'Doherty (talk) 23:27, 2 January 2023 (UTC)
- If the Scots rightfully protest at James I of England, why is it not equally rightful that they protest at Charles I of England?
- And, when I read
It only covers monarchs of England before 1603 because that is what the policy was written to do
I see a circular argument. It covers the period from 1087 because it covers the period from 1087.
- And, when I read
- You say there is no issue that needs to be fixed with Scottish monarchs, but so far as I can see the articles for Scottish monarchs show just as much variation as English ones. If we allow William the Lion, for example, why not also allow Richard the Lionheart? If anything Scottish monarchs show more variation than English ones.
- Overall, I find this proposal worryingly anglocentric. For those monarchs who were equally king or queen of multiple countries, we need to find a way of naming the articles that does not treat countries that are not England as unimportant. Kahastok talk 17:38, 3 January 2023 (UTC)
- I'd rather we had William I of Scotland, keep Richard I of England & have William I of England, Catherine II of Russia, Frederick II of Prussia, Mary I of Scotland, etc. Not the nickname titles. GoodDay (talk) 17:44, 3 January 2023 (UTC)
- The "nickname titles" - by which I assume you mean names that don't fit your pattern - tend to score quite highly in terms of the naming criteria. And in some cases - like English kings from before 1066 - they're pretty much the only names we have. History doesn't always fit a pattern and it doesn't always do to try to shoehorn it into one. Kahastok talk 18:23, 3 January 2023 (UTC)
- Can we momentarily bring this back to the proposal rather than debating on monarchs of different kingdoms? The fact is that the monarchs that this proposal covers are not known by epithets and all employ ordinals in their current titles. Monarchs of the Kingdom of Scotland (before 1603), Russia, and Prussia are irrelevant. We don't need to debate on whether we should use epithets or ordinals because they all already use ordinals. The discussion is on whether or not we should have a consistent policy on UK monarch titling. Tim O'Doherty (talk) 18:44, 3 January 2023 (UTC)
- I do not accept that monarchs of Scotland are irrelevant. Because if there is a problem with English and post-1603 Scottish monarchs, then there is also a problem with pre-1603 Scottish monarchs. If there is not a problem with pre-1603 Scottish monarchs, then there is also not a problem with English and post-1603 Scottish monarchs. It makes no sense to me that we should have a special guideline for English and post-1603 Scottish monarchs that does not apply anywhere else, including Scotland before 1603.
- Can we momentarily bring this back to the proposal rather than debating on monarchs of different kingdoms? The fact is that the monarchs that this proposal covers are not known by epithets and all employ ordinals in their current titles. Monarchs of the Kingdom of Scotland (before 1603), Russia, and Prussia are irrelevant. We don't need to debate on whether we should use epithets or ordinals because they all already use ordinals. The discussion is on whether or not we should have a consistent policy on UK monarch titling. Tim O'Doherty (talk) 18:44, 3 January 2023 (UTC)
- The "nickname titles" - by which I assume you mean names that don't fit your pattern - tend to score quite highly in terms of the naming criteria. And in some cases - like English kings from before 1066 - they're pretty much the only names we have. History doesn't always fit a pattern and it doesn't always do to try to shoehorn it into one. Kahastok talk 18:23, 3 January 2023 (UTC)
- I'd rather we had William I of Scotland, keep Richard I of England & have William I of England, Catherine II of Russia, Frederick II of Prussia, Mary I of Scotland, etc. Not the nickname titles. GoodDay (talk) 17:44, 3 January 2023 (UTC)
- Overall, I find this proposal worryingly anglocentric. For those monarchs who were equally king or queen of multiple countries, we need to find a way of naming the articles that does not treat countries that are not England as unimportant. Kahastok talk 17:38, 3 January 2023 (UTC)
- I would add as a separate point that I am concerned that this may in practice be an WP:RM that has not been adequately notified to the affected articles. Yes, the proposal is that a separate RM would be required, but that RM would surely come, and this proposal essentially defines the outcome of the RM. So the risk of accepting this is that we do an end run around the standard RM process and its notification requirements.
- I'm going to boil this down I guess. I oppose because (a) I don't think this specific point needs its own separate guideline, (b) I don't think the proposed move targets are appropriate and (c) because of procedural concerns. Kahastok talk 23:04, 3 January 2023 (UTC)
- I'll notify the concerned articles with RMs if this passes. If this doesn't pass, they'll just have to be withdrawn anyway as the policy to back them up won't exist.
- Also, the monarchs of Scotland pre 1603 aren't irrelevant, but that's not what this proposal was written to cover. The are an entirely different case-sensitive can of worms. I am not proposing, for example, that Mary, Queen of Scots be moved to Mary I of Scotland. I would need to write a different proposal on it to cover those cases. Tim O'Doherty (talk) 23:12, 3 January 2023 (UTC)
- I'm going to boil this down I guess. I oppose because (a) I don't think this specific point needs its own separate guideline, (b) I don't think the proposed move targets are appropriate and (c) because of procedural concerns. Kahastok talk 23:04, 3 January 2023 (UTC)
- Nobody is suggesting that countries outside of the UK are unimportant (they all get fair treatment within the article body) but the alternative is to have such articles titled things like "Elizabeth II of the United Kingdom, Canada, Australia, New Zealand, South Africa, Pakistan, Ceylon, Ghana, Nigeria, Sierra Leone, Tanganyika, Jamaica, Trinidad and Tobago, Uganda, Kenya, Malawi, Malta, The Gambia, Rhodesia, Barbados, Mauritius, Fiji, The Bahamas, Grenada, Papua New Guinea, the Solomon Islands, Tuvalu, Saint Lucia, Saint Vincent and the Grenadines, Belize, Antigua and Barbuda and Saint Kitts and Nevis". We can't have them all. Tim O'Doherty (talk) 18:52, 3 January 2023 (UTC)
- @Tim O'Doherty, I appreciate all the work you've put into this, but I'm struggling to see what it means in actual practice. Consider George III: Are you proposing that the article be moved to George III of England? George III of Great Britain? George III of Great Britain and Ireland? George III of the United Kingdom? Or something else? A firm rule would work best if we all knew what the result was supposed to be. WhatamIdoing (talk) 21:59, 3 January 2023 (UTC)
- Its previous title, George III of the United Kingdom. GoodDay (talk) 22:04, 3 January 2023 (UTC)
- It would be George III of the United Kingdom. If you want a list of all the new names that would be if the proposal is accepted, I'll gladly write them down in my second sandbox. If not, point 6 provides some instruction on the point you've raised. Tim O'Doherty (talk) 22:13, 3 January 2023 (UTC)
- Note to everybody: the list of titles under the proposal if accepted is here. Tim O'Doherty (talk) 22:38, 3 January 2023 (UTC)
- @Tim O'Doherty, I appreciate all the work you've put into this, but I'm struggling to see what it means in actual practice. Consider George III: Are you proposing that the article be moved to George III of England? George III of Great Britain? George III of Great Britain and Ireland? George III of the United Kingdom? Or something else? A firm rule would work best if we all knew what the result was supposed to be. WhatamIdoing (talk) 21:59, 3 January 2023 (UTC)
In Australia, this will be taken as a polemical political statement, arguing against the de jure status of Australia as a monarchy. This alone would be enough for me to oppose under our WP:NPOV policy. Hawkeye7 (discuss) 19:42, 2 January 2023 (UTC)
- Saying this is against NPOV is surely a bit of a stretch. All monarch's articles address that they are monarch of the Commonwealth realms. They are known as monarch of the United Kingdom, and if you find this proposal problematic, then surely you must also find WP:COMMONNAME problematic too, which argues for the common name, which is what "of the United Kingdom" is. This "problem" already exists too; take Charles II of England as an example. He was king of Scotland and Ireland as well, but nobody is arguing that that is against NPOV. The issue that you take with it is not exclusive to this proposal. Tim O'Doherty (talk) 20:02, 2 January 2023 (UTC)
- I personally think that including some sort of country in the article name would be ideal under WP:NPOV/WP:GLOBAL, because, and this may surprise some people, countries other than England exist. I just have no clue what country name that would be, in some cases, and this proposal seems to create more problems then it solves. casualdejekyll 20:22, 2 January 2023 (UTC)
- Not really a problem. The Stuarts 1603-1707, are more recognisable as English monarchs. Meanwhile, after the Union Acts, George I to Charles III, are more recognisable as British monarchs. GoodDay (talk) 22:02, 2 January 2023 (UTC)
- Utter waste of time. Firstly this is a MOS issue, not a policy issue. Secondly the point of MOS is to provide a standard framework for consistency, where it cannot provide that consistency, it just causes more trouble than it solves. Thirdly, any time you proscribe something and say "this is the way it must be done" and even before the ink is wet you have a dozen exceptions, it's just a deliberate act of riling people up at that stage. No, god no. Only in death does duty end (talk) 21:31, 2 January 2023 (UTC)
- It absolutely is not a MoS issue as we already have WP:AT which isn't a part of the Manual of Style. Furthermore, there are topic-specific titling guidelines, none of which are in the MoS. This is just another topic specific AT regulation, to say it should be in the Manual of Style when none of the others are and then calling it an "utter waste of time" is not really justifiable. And I'm not saying "this is how it should be done"; you could say that about any policy. I'm suggesting it as a proposal for the way it might be done, and if passed as policy, then yes, it should be done that way. Tim O'Doherty (talk) 22:13, 2 January 2023 (UTC)
- Oppose per all of the abovementioned objections, this is a clear case of a solution in search of a problem. Roger (Dodger67) (talk) 22:32, 2 January 2023 (UTC)
- Oppose. Firstly this does not need to be a policy - if there is a problem that needs solving (and I'm not convinced there is) then a naming convention is the way to go. Secondly, there is almost never a good reason for a policy to prohibit all exceptions and require absolute conformity (WP:CSD is the only one not dealing with legal issues I can think of). Thirdly, even if there was a problem that needed solving, required a policy to solve it, and required there to be no exceptions to that policy, this proposal would not (per pretty much everyone above) solve it. Thryduulf (talk) 10:19, 3 January 2023 (UTC)
Oppose. I don't see anything wrong with sticking to WP:DAB, for example, Henry VIII is clearly primarily the Henry the Eighth, and Henry III is clearly ambiguous, so gives a disambiguation page, this seems correct and entirely unsurprising to me. If someone wants consistency in a list, for instance, then pipe links are perfectly acceptable for this. (e.g. a list of Kings of England would have Henry II, but a list of Henries would have Henry VIII of England) JeffUK15:22, 3 January 2023 (UTC) (Struck by me, see below)- Oppose the unusually harsh absolutism language is completely undone by the growing list of exceptions/clarifications. This will just be used to aggravate editors especially new ones and should not be policy. Slywriter (talk) 22:36, 3 January 2023 (UTC)
- In case you haven't seen, you can view the list of titles here if you are concerned about the "undo[ing] of the proposal. Cordially, Tim O'Doherty (talk) 22:42, 3 January 2023 (UTC)
- That doesn't improve the situation. In fact, it highlights the arbitrary nature of choices. Elizabeth I is Queen of England and Ireland, yet Ireland is dropped. I'm sure there are reasons obvious to proposers but this just seems like a blanket attempt to codify a particular desire, rather than actually improve the encyclopedia. Slywriter (talk) 22:56, 3 January 2023 (UTC)
- Elizabeth I is remembered much more for being Queen of England, then Queen of Ireland. Besides, her being Queen of Ireland is already mentioned in the intro & infobox of her page. So we don't need Ireland mentioned in the article title. She resided in England, not Ireland. GoodDay (talk) 23:01, 3 January 2023 (UTC)
- It's not my choice. Henry VII was Lord (King) of Ireland, and yet he is Henry VII of England. I'm simply making all of the articles consistent with one another. Tim O'Doherty (talk) 23:02, 3 January 2023 (UTC)
- That doesn't improve the situation. In fact, it highlights the arbitrary nature of choices. Elizabeth I is Queen of England and Ireland, yet Ireland is dropped. I'm sure there are reasons obvious to proposers but this just seems like a blanket attempt to codify a particular desire, rather than actually improve the encyclopedia. Slywriter (talk) 22:56, 3 January 2023 (UTC)
- In case you haven't seen, you can view the list of titles here if you are concerned about the "undo[ing] of the proposal. Cordially, Tim O'Doherty (talk) 22:42, 3 January 2023 (UTC)
- Oppose. Policies should provide general rules on article content, rather than attempting to lay down the law for a single subject. Absolutely no evidence has been offered to demonstrate that there is any specific issue here that requires such exceptionalism. AndyTheGrump (talk) 23:22, 3 January 2023 (UTC)
- Agree (sort of.) I think there is actually a case of Systematic Bias here, and maybe WP:Recentism? If we say, for example, that 'Charles III' is THE 'Charles III', because of course he is, he's the one we see on the telly all the time. That elevates the specific Charles III who's most known in western culture to some higher level than others. I think the suggestion is valid, IF there are other sovereigns who are titled in the same way, we should not have 'primary article' pointing to one of them. For example, there is no other Elizabeth I, so we do not need to be more specific that Elizabeth I. I don't know if this is the problem the proposers were aiming to solve, but I do think it is something worth at least considering. I don't think this should be specific to English/British sovereigns, it should be across the board that multiple sovereigns with the same styling get the same treatment. This is pretty much what Wikipedia:Naming_conventions_(royalty_and_nobility)#Sovereigns says already. JeffUK 10:43, 4 January 2023 (UTC)
- By my reckoning, as the only articles where there is another monarch primarily styled with the same name, only Georges 3,4,5 and 6, and Charles III should be renamed to the styling recommended above (But with deference to the recent move discussion, Charles III should be left alone) and having all the King Georges in the same format does seem eminently sensible.
- Elizabeth I & II, William IV, Queen Victoria, and Edward VII&VIII are entirely unambiguous as sovereigns, so don't need disambiguating. Henry VIII is borderline as there was another Henry VIII who later because king, but I think he was the 8th Duke, and 4th King... so probably Henry VIII stays too. JeffUK 12:39, 4 January 2023 (UTC)
- @JeffUK I'm confused as you partially contradict yourself (
Charles III should be renamed ... Charles III should be left alone
), but you seem to arguing that each article's title should be determined individually (sometimes with reference to other English/British monarchs of the same name) based on their ambiguity with other topics. This is basically the status quo and exactly the opposite of the proposal, which is to establish a single format that every article in the set must follow without regard to other factors like primary topic or (lack of) ambiguity. Thryduulf (talk) 12:54, 4 January 2023 (UTC)- Yes, hence the 'Sort of'. I'm ignoring the way it's been worded and focusing on the intent; I do find some merit in more strongly suggesting (Maybe in the naming convention) that articles are titled using the normal format if there are other sovereigns with the same style, even if they are less well known. There should, as always, be no absolutes. JeffUK 14:45, 4 January 2023 (UTC)
- It shouldn't matter if the monarchs are unambiguous. It does no harm to add "of England/of Great Britain/of the United Kingdom". In fact, in most cases, it does quite a lot of good. Tim O'Doherty (talk) 21:41, 4 January 2023 (UTC)
- @JeffUK I'm confused as you partially contradict yourself (
- Oppose: Like the rest of the opposers, I don't see any compelling need for a specific naming convention for a very narrow set of articles to be enshrined in policy. This seems like unnecessary policy creep which would open the door to naming policies on every other narrow set of articles that someone or other gets a bee in their bonnet about. Despite being justified by reference to WP:CONSISTENT and including the phrases "always" and "without exception" in bold in the proposed text, there are already several exceptions enumerated in the text of the proposal; this does not suggest to me a policy which should be enacted without exception, and recent (well-attended!) move requests have clearly come to a consensus which contradicts this proposal, which also suggests that it does not represent community consensus. We already have Wikipedia:Naming conventions (royalty and nobility): if more specific guidelines for UK royalty are really desired, write a supplement to that. Caeciliusinhorto-public (talk) 15:45, 4 January 2023 (UTC)
- Oppose, consistency in following WP:COMMONNAME is more important than consistency between article names. WP:CONSISTENT was boldly changed last year; I have just undone this change and returned to the less prescriptive language that has served us well before. —Kusma (talk) 22:12, 4 January 2023 (UTC)
- I undid your change there, as it did't seem to have consensus to be made. GoodDay (talk) 22:28, 4 January 2023 (UTC)
- @GoodDay: Please do not revert unless you can give a substantial reason why you disagree with an edit, see WP:DRNC. For the record I can see no indication of any formal consensus for the edit I reverted, either, and I disagree with it because foolish consistency is something that Wikipedia has been good at wisely avoiding for 20 years. —Kusma (talk) 22:38, 4 January 2023 (UTC)
- I reverted you, because the change had been in place for quite sometime. Your (today) alterations appeared as an attempt to influence the discussion 'here'. It just doesn't look good, to make alterations on a related page, in the middle of a Village Pump RFC. GoodDay (talk) 22:42, 4 January 2023 (UTC)
- That's why I was very open about making this revert. But perhaps this discussion can serve as a counterpoint to the edit I reverted and you reinstated. —Kusma (talk) 09:09, 5 January 2023 (UTC)
- There is nothing foolish about consistency. If you or I had a physical, paper and ink encyclopedia in front of us, then all the titles of the entries there would be consistent with one another: not have arbitrary and random inconsistencies between them. Tim O'Doherty (talk) 22:58, 4 January 2023 (UTC)
- The real world has arbitrary and random inconsistencies in it. Names of Chinese people, for example, are sometimes commonly written in Chinese order, sometimes in Western order (consider Ang Lee versus Wong Kar-wai for two people in the same category of "film directors"). Enforcing consistency there would just make our article titles unrecognisable. Of course consistency is nice, but not if it leads to article names that nobody in the real world uses. —Kusma (talk) 09:06, 5 January 2023 (UTC)
- I do not believe that Chinese names in the Chinese/Western order is analogous to this. Sure, some Chinese people may be better known by the name put one way or the other, and I am not arguing for or against the use of either. However, the consistency proposed here makes article titles more recognisable. I defy you to look at any of the titles here and say that they are unrecognisable. Tim O'Doherty (talk) 16:39, 5 January 2023 (UTC)
- They aren't unrecognisable but the consistency you favour makes some of them less recognisable (not more as you claim), particularly Queen Victoria → Victoria, Queen of the United Kingdom. The real world being messy and inconsistent, partly due to the regnal titles being inconsistent (and your list being inconsistent and using the full area for some but only a partial one for others really doesn't help that), and so the common names (which are the most recognisable by definition) are messy and inconsistent. Thryduulf (talk) 17:19, 5 January 2023 (UTC)
- But, as the proposal says, the common names shouldn't matter in this very narrow, isolated instance. Victoria, Queen of the United Kingdom provides all the information of Queen Victoria and more: she was a Queen, of the United Kingdom, called Victoria. And the point of only using the "partial" area: that does not make the titles inconsistent. I can't very well have "Henry VII of England, France and Ireland" or "Elizabeth II of the United Kingdom and Commonwealth realms". While the titles may not include every single country they ever ruled over, a.) if they did, they would be less, not more consistent, b.) too long, and c.) unrecognisable and impractical for the everyday user. Tim O'Doherty (talk) 17:31, 5 January 2023 (UTC)
- The goal of the article title is not to provide information, it is to identify the topic of the article. Consistency is only beneficial if it aids this goal, which is why WP:COMMONNAME is the ruling factor and we don't make titles longer than they need to be. Your proposal does say that the common name shouldn't matter in this instance, but none of your justifications for why it shouldn't matter have convinced me (or pretty much anyone else) that this is beneficial to the project, let alone that it needs to be a policy more rigid than almost any other.
- Yes, using every single country would make the titles too long and less recognisable (but not unrecognisable) but they would be more consistent than your proposal which sometimes uses all and sometimes uses a subset - which is only a problem if your goal is consistency. Thryduulf (talk) 19:40, 5 January 2023 (UTC)
- But, as the proposal says, the common names shouldn't matter in this very narrow, isolated instance. Victoria, Queen of the United Kingdom provides all the information of Queen Victoria and more: she was a Queen, of the United Kingdom, called Victoria. And the point of only using the "partial" area: that does not make the titles inconsistent. I can't very well have "Henry VII of England, France and Ireland" or "Elizabeth II of the United Kingdom and Commonwealth realms". While the titles may not include every single country they ever ruled over, a.) if they did, they would be less, not more consistent, b.) too long, and c.) unrecognisable and impractical for the everyday user. Tim O'Doherty (talk) 17:31, 5 January 2023 (UTC)
- They aren't unrecognisable but the consistency you favour makes some of them less recognisable (not more as you claim), particularly Queen Victoria → Victoria, Queen of the United Kingdom. The real world being messy and inconsistent, partly due to the regnal titles being inconsistent (and your list being inconsistent and using the full area for some but only a partial one for others really doesn't help that), and so the common names (which are the most recognisable by definition) are messy and inconsistent. Thryduulf (talk) 17:19, 5 January 2023 (UTC)
- I do not believe that Chinese names in the Chinese/Western order is analogous to this. Sure, some Chinese people may be better known by the name put one way or the other, and I am not arguing for or against the use of either. However, the consistency proposed here makes article titles more recognisable. I defy you to look at any of the titles here and say that they are unrecognisable. Tim O'Doherty (talk) 16:39, 5 January 2023 (UTC)
- The real world has arbitrary and random inconsistencies in it. Names of Chinese people, for example, are sometimes commonly written in Chinese order, sometimes in Western order (consider Ang Lee versus Wong Kar-wai for two people in the same category of "film directors"). Enforcing consistency there would just make our article titles unrecognisable. Of course consistency is nice, but not if it leads to article names that nobody in the real world uses. —Kusma (talk) 09:06, 5 January 2023 (UTC)
- I reverted you, because the change had been in place for quite sometime. Your (today) alterations appeared as an attempt to influence the discussion 'here'. It just doesn't look good, to make alterations on a related page, in the middle of a Village Pump RFC. GoodDay (talk) 22:42, 4 January 2023 (UTC)
- @GoodDay: Please do not revert unless you can give a substantial reason why you disagree with an edit, see WP:DRNC. For the record I can see no indication of any formal consensus for the edit I reverted, either, and I disagree with it because foolish consistency is something that Wikipedia has been good at wisely avoiding for 20 years. —Kusma (talk) 22:38, 4 January 2023 (UTC)
- I undid your change there, as it did't seem to have consensus to be made. GoodDay (talk) 22:28, 4 January 2023 (UTC)
Maybe a good idea, but a bad idea to make a mere good idea mandatory. And unthinkable to make a policy dedicated to this. Sincerely, North8000 (talk) 19:48, 5 January 2023 (UTC)
- Oppose and Alternative proposal: All time-wasting renaming proposals for British monarchs should be forbidden from now until the end of time. Johnbod (talk) 23:16, 5 January 2023 (UTC)
- Oppose alternative proposal. Tim O'Doherty (talk) 23:33, 5 January 2023 (UTC)
- Oppose Because this is a foolish consistency. WP:COMMONNAME should be the more important principle in this case. --Jayron32 14:47, 6 January 2023 (UTC)
- Oppose This proposal attempts to fix what isn't broken. I restate the concerns I expressed in questions above, including that it attempts to reverse a RM on Charles III that failed overwhelmingly and thus expresses a recent consensus. This seems a good candidate for a close per WP:SNOW.--Wehwalt (talk) 15:32, 6 January 2023 (UTC)
Withdrawn by nominator It is clear now that this proposal will not become policy; therefore, I withdraw the proposal myself as the nominator per WP:SNOW. I may one day write a "softer" version as just another standard naming convention that will have to be re-submitted after a time sufficient to make sure there will be a new consensus, but that time is clearly not now. I accept the results of the RfC, and I thank all participants involved, whether they agreed with me or not. Cordially, Tim O'Doherty (talk) 19:41, 6 January 2023 (UTC)
- Oppose for the numerous reasons mentioned. Graham (talk) 20:44, 16 January 2023 (UTC)
New bot to change wikilinks following a requested move
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I started a BRFA yesterday for PuggleBot, where @Anomie thought this would require wider discussion, and suggested I brought it here and see if people think this could be a good idea. So, what this bot would do:
Following a successful requested move, this bot would change the wikilinks to the moved page if necessary. For example, if Foo was moved to Foo (bar), and Foo (disambiguation) was moved to Foo, the bot would change all links to Foo to [[Foo (bar)|Foo]]
, so the link continues to go to the right place. Originally, I was planning to run it on all successful moves, including ones where the changes would be near-cosmetic. However, I believe I have figured out how to skip them, but it's something I would have to test.
So, what do you think? It would be run once a day at first, and hopefully after a bit I could transition it to automatic operation, but this isn't something I'm thinking about at the moment. If anyone has questions about it, please ping me and let me know! Thanks, echidnaLives - talk - edits 23:30, 3 January 2023 (UTC)
- @echidnaLives: I primarily update linked articles when there are RM discussions involving dab pages created or moved. My experience thus far is that there would be portions of these linked articles being linked wrongly and would require an editor to correct the links. Just one example of the many I had closed (recalling offhandedly, primarily because of the number of links that had to be worked on): When I closed the discussion for Australian, there were
400+3,000-4,000 articles requiring editors to sort into the various possible articles, Australia, Australians, etc. - If implemented, I suggest that the bot skips changing wikilinks for requested moves discussions which result in a dab page occupying one of the original titles under discussion, so that editors can resolve the links manually postmove. – robertsky (talk) 00:09, 4 January 2023 (UTC)
- @Robertsky I completely understand this. If it was implemented, I don't think I would skip them completely though, as the bot would be supervised and I would be ready to fix any issues that come up almost immediately, but I would rethink it if it ever does become automatic. But in more complicated situations, including ones like Australian, it would definitely not be done by the bot. As you said, these situations are too advanced and need attention from editors themselves. Thank you for your feedback, echidnaLives - talk - edits 00:19, 4 January 2023 (UTC).
- @echidnaLives: I actually don't see the need to update the wikilinks beyond these dab page related moves except for what @The Banner said on changing links in the Template space. Or when another article occupies the original title. Are there any other considerations for implementing this bot task? – robertsky (talk) 03:58, 4 January 2023 (UTC)
- @Robertsky I believe it would be useful in most dab related moves, just not the ones where it may be a different intended page based on the context, like Australian. For example, this move. The old title is now held by a disambiguation page. However, since that title has been established for a long time, all links to it are intended for the now-moved page, and aren't meant to link anywhere else. Does that make sense? Thanks, echidnaLives - talk - edits 04:17, 4 January 2023 (UTC)
- My issue with automating the editing from Eddie Lewis (English footballer) to Eddie Lewis (footballer, born 1935) in the linked articles is that there may have been editors incorrectly linking to Eddie Lewis (English footballer) in the first place when the 1935 footballer article was there, for one reason or another, when they meant to link to Eddie Lewis (footballer, born 1926). I had encountered similar issues when closing similar requests (evidently, the page move was clearly needed in those cases). I can't find the exact RM discussion that I had closed now, but there was one which had 10-ish links to "Article A (B)" which was moved to "Article A (B, C)", and half of them were actually to a different topic "Article A (B, D)". – robertsky (talk) 04:45, 4 January 2023 (UTC)
- You raise an important point, and it's something I certainly should of considered more. However, I still think this bot could work well, it probably need more supervision than I first thought it would (which is fine). Maybe in AWB (assuming it has bot access) I could set the edit-delay to 3~ seconds (or longer), allowing me to look over it and decide whether it's good or not, and allowing me to look further and skip if necessary, echidnaLives - talk - edits 04:57, 4 January 2023 (UTC)
- My issue with automating the editing from Eddie Lewis (English footballer) to Eddie Lewis (footballer, born 1935) in the linked articles is that there may have been editors incorrectly linking to Eddie Lewis (English footballer) in the first place when the 1935 footballer article was there, for one reason or another, when they meant to link to Eddie Lewis (footballer, born 1926). I had encountered similar issues when closing similar requests (evidently, the page move was clearly needed in those cases). I can't find the exact RM discussion that I had closed now, but there was one which had 10-ish links to "Article A (B)" which was moved to "Article A (B, C)", and half of them were actually to a different topic "Article A (B, D)". – robertsky (talk) 04:45, 4 January 2023 (UTC)
- @Robertsky I believe it would be useful in most dab related moves, just not the ones where it may be a different intended page based on the context, like Australian. For example, this move. The old title is now held by a disambiguation page. However, since that title has been established for a long time, all links to it are intended for the now-moved page, and aren't meant to link anywhere else. Does that make sense? Thanks, echidnaLives - talk - edits 04:17, 4 January 2023 (UTC)
- @echidnaLives: I actually don't see the need to update the wikilinks beyond these dab page related moves except for what @The Banner said on changing links in the Template space. Or when another article occupies the original title. Are there any other considerations for implementing this bot task? – robertsky (talk) 03:58, 4 January 2023 (UTC)
- @Robertsky I completely understand this. If it was implemented, I don't think I would skip them completely though, as the bot would be supervised and I would be ready to fix any issues that come up almost immediately, but I would rethink it if it ever does become automatic. But in more complicated situations, including ones like Australian, it would definitely not be done by the bot. As you said, these situations are too advanced and need attention from editors themselves. Thank you for your feedback, echidnaLives - talk - edits 00:19, 4 January 2023 (UTC).
- I note my main concern was that the original proposal said the bot was intended to run automatically for every closed RM with little human input. If an experienced human is instead choosing only those targets that are safe and non-cosmetic to bot-update (and what displayed text to update them to when not already piped), I have much less concern about it. OTOH, it seems people already do that much in a semi-automated manner with AWB, which raises the question of whether a dedicated bot is needed. Anomie⚔ 03:19, 4 January 2023 (UTC)
- @Anomie I believe a dedicated bot would be helpful, and while this could be done with AWB, having the dedicated bot would allow me to check the list of RMs, quickly sort out the unnecessary RMs and let it run, allowing me to do other things and not have to keep clicking "save", "save", "save" a lot. The bot would also be helpful for people without access to AWB, and people who might forget about it or just not do it.
- Sorry for the confusion about the cosmetic edits, I originally believed they couldn't be filtered out, but I believe I have somewhat figured out how to do it. However, I will have to test it out first to confirm this. Thanks, echidnaLives - talk - edits 03:37, 4 January 2023 (UTC).
- Quick note: articles wouldn't have to be removed manually often. As I mentioned, I am pretty confident I'll be able to automatically filter out all of the cosmetic pages. The only ones which would need filtering out are very complicated situations like the Australian one mentioned by robertsky before, where a different link may be necessary depending on the context. echidnaLives - talk - edits 04:24, 4 January 2023 (UTC)
- Having worked on this task for years, wherever a page is moved because the title is actually ambiguous, there are usually a handful of errors uncovered through the disambiguation process. I'm not saying that it would be impossible for a bot to be set up to fix incoming links correctly, but it would basically need to be an AI. BD2412 T 04:42, 4 January 2023 (UTC)
- @BD2412 Does my reply above address this issue? If not, could you explain the errors a bit further? As I said above, I believe this task can work well, but it probably needs more supervision than I expected. Thanks, echidnaLives - talk - edits 04:59, 4 January 2023 (UTC)
- I have a bot approved for AWB access for fixing disambiguation links. I use it for this purpose in a very reserved manner, and only after finding very specific patterns in the course of manual disambiguation of rather large sets. BD2412 T 05:28, 4 January 2023 (UTC)
- @BD2412 This bot would essentially do the same thing, with supervision, daily on closed requested moves. At it's core, it would just do the normal thing you could do in an AWB task (or your bot), but configured so it runs on the necessary pages, with basic settings that would allow it to work most of the time, and for the times it doesn't, I'll be ready to step in straight away if the link doesn't need replacing/bot is having a different error.
- So basically, it wouldn't be adjusted to skip the situation that @Robertsky brought up before.(Robersky's comment from above: My issue with automating the editing from Eddie Lewis (English footballer) to Eddie Lewis (footballer, born 1935) in the linked articles is that there may have been editors incorrectly linking to Eddie Lewis (English footballer) in the first place when the 1935 footballer article was there, for one reason or another, when they meant to link to Eddie Lewis (footballer, born 1926).). But, my close supervision will allow me to easily skip these links, and only edit the ones required. Thanks, echidnaLives - talk - edits 06:09, 4 January 2023 (UTC).
- I have a bot approved for AWB access for fixing disambiguation links. I use it for this purpose in a very reserved manner, and only after finding very specific patterns in the course of manual disambiguation of rather large sets. BD2412 T 05:28, 4 January 2023 (UTC)
- @BD2412 Does my reply above address this issue? If not, could you explain the errors a bit further? As I said above, I believe this task can work well, but it probably needs more supervision than I expected. Thanks, echidnaLives - talk - edits 04:59, 4 January 2023 (UTC)
- Having worked on this task for years, wherever a page is moved because the title is actually ambiguous, there are usually a handful of errors uncovered through the disambiguation process. I'm not saying that it would be impossible for a bot to be set up to fix incoming links correctly, but it would basically need to be an AI. BD2412 T 04:42, 4 January 2023 (UTC)
- Quick note: articles wouldn't have to be removed manually often. As I mentioned, I am pretty confident I'll be able to automatically filter out all of the cosmetic pages. The only ones which would need filtering out are very complicated situations like the Australian one mentioned by robertsky before, where a different link may be necessary depending on the context. echidnaLives - talk - edits 04:24, 4 January 2023 (UTC)
- Some thoughts would be interesting to hear how you see these scenarios working.
- Say we have an article called Wikipedia that was mostly about the Wikimedia Foundation with a small Section on Wikipedia. So, we move Wikipedia-> Wikipedia Foundation. In this case, we would want the redirect to be to [[Wikimedia Foundation#Wikipedia]], how would it handle that?
- Sometimes is preferable to leave the redirects, because the original title is a plausible future article, but we're moving it to a 'parent' topic. In a few years someone replaces the Wikipedia redirect with an actual article; and we have to manually go through and find all the [[wikimedia foundation|wikipedia]] links and change them back again. If they were left as a redirect, we wouldn't have this problem. JeffUK 15:06, 4 January 2023 (UTC)
- Hello @JeffUK, thanks for your questions. These scenarios would not be handled by the bot as [[Wikipedia]] is still redirecting to the intended location. However, if it was decided that Wikipedia (the encyclopedia) is not the primary topic, and is moved to Wikipedia (encyclopedia) with Wikipedia (disambiguation) moved to Wikipedia, that’s when the bot would change links. This is because links to [[Wikipedia]] are supposed to be for Wikipedia (encyclopedia), but are now linking to the disambiguation page. There are more simple examples above. Thanks, echidnaLives sock - talk - edits 15:35, 4 January 2023 (UTC)
- I have my reservations on this. First let's take the following example before proceeding. The pages are moved in the following order:
- [[Foo]] → [[Foo (something)]]
- [[Foo (disambiguation)]] → [[Foo]]
- The proposed bot will change all incoming links of [[Foo]] to [[Foo (something)]], not controlling for the fact that [[Foo]] has incoming links that should've ideally been to [[Foo (other thing)]] & [[Foo (third thing)]], but were linked "mistakenly" to the base page. Blind changes would direct people to wrong destinations.
- A pagemover might manually modify the links, unaware of the bot's existence. They modified [[Foo (disambiguation)]] into [[Foo]]. How will the bot ensure that this manually modified [[Foo]] is not converted into [[Foo (something)]]?
- —CX Zoom[he/him] (let's talk • {C•X}) 08:38, 5 January 2023 (UTC)
- Thanks @CX Zoom for asking this, I completely understand the fact that you have reservations about this.
- This example brings up valid points, the first of which discussed above. As I will be supervising the bot when it goes through it's process, meaning if I come across this situation, I can easily stop it from making the change. In all situations, when I or the bot is unsure about a link, it would be skipped, as it's worth having a DAB link instead of the wrong link.
- For the second point, this is something I have thought about. Typically, I don't think this would be an issue. I've never encountered any closer doing this, as there would be no reason for them to do that. However, if the context seems weird (for example, if I saw a hatnote that says This article is about (page). For other uses, see [[Foo]], obviously it wouldn't be a good idea to change it. Although, if this has happened in the main content part of an article, then it would be the same as your first question. I would be supervising and ready to stop it.
- If you have any more questions, please ask! Thanks, echidnaLives - talk - edits 08:57, 5 January 2023 (UTC).
- Thanks for your reply @EchidnaLives. If you just want to fix the links with manual oversight, then I have no issues with it. It would basically be WP:DISAMASSIST but faster and more efficient. Is that right? —CX Zoom[he/him] (let's talk • {C•X}) 09:10, 5 January 2023 (UTC)
- @CX Zoom Yes, that's pretty much it. The main reasons I want to use a bot account are listed in my response to Kusma below, and AWB allows me to create a system to automatically list the RMs that may need attention (although, the list would still be checked to avoid doing the wrong pages, as discussed above.) Thanks, echidnaLives - talk - edits 09:33, 5 January 2023 (UTC)
- Thanks for your reply @EchidnaLives. If you just want to fix the links with manual oversight, then I have no issues with it. It would basically be WP:DISAMASSIST but faster and more efficient. Is that right? —CX Zoom[he/him] (let's talk • {C•X}) 09:10, 5 January 2023 (UTC)
- This is a bad idea for a bot, as it is likely to cause accidental wrong links. A hundred links to disambiguation pages (easy to find and not hard to fix) is preferable to a single wrong link (nearly impossible to find). —Kusma (talk) 08:55, 5 January 2023 (UTC)
- Hello @Kusma. I agree, having a bot do this automatically would be a very bad idea, but please see my responses above. The bot would not be doing this un-supervised, as that would result in a lot of accidental links like you said, and I would stop this edits straight away. The first half of my response to CX Zoom and my response to BD2412 both explain this more in-depth. If you have any other questions, please let me know! Thanks, echidnaLives - talk - edits 09:02, 5 January 2023 (UTC)
- If you're checking every edit manually (which sometimes requires pausing and thinking), you don't need a bot for this. If you're not checking every edit manually, you shouldn't do this at all. Disambiguation fixing is not a task for bots and requires care and attention (quite often, 95%+ of the links need to go to one page, but that is not nearly enough to just send all to that page). —Kusma (talk) 09:19, 5 January 2023 (UTC)
- @Kusma I would be checking all the edits, but I would like to use a bot account for it. With bot access in AWB, it makes it a lot easier to go through it semi-automatically (with manual supervision), and as it would be making a lot of edits (
maybe 15 or so a minute while running), a bot flag would be useful, as I wouldn't want to spam recent changes. But you are right. A bot account is not completely necessary to do this, just makes it a lot easier to work with. Hope that clears it up a bit. Thanks, echidnaLives - talk - edits 09:30, 5 January 2023 (UTC).- If you want to do 15 edits per minute on a task like this then I must oppose strongly (there is no way you can be careful enough at that rate). Something that could potentially have errors should also not be hidden behind a bot flag. —Kusma (talk) 09:38, 5 January 2023 (UTC)
- @Kusma 15 edits was probably a bit optimistic. At the end of the day, there isn't a set rate for this. I would need to test out the configuration, and see what speed I can do it at where I can be confident that mistakes aren't happening. You are 100% right about me needing to be extremely careful with this task, and that would be priority number 1. I also understand what you mean about hiding the edits behind a bot flag, but I don't really see any way around this. All bots can make mistakes, especially this one, but when every edit is being checked by a human who knows that their doing, I think this can balance it out. As I have mentioned before, any edit where there's any possibility of a mistake being made, is skipped, and I think that's an important part of having any chance for getting this approved. With that said, if this does end up going to a trial and it appears like hiding the edits behind a bot flag is a risk, then (I assume this can be done) the bot would be run without a flag, but just be added to the AWB bot list.
- Your questions and criticisms are really helpful, so if you have any more, please let me know. Thank you, echidnaLives - talk - edits 09:54, 5 January 2023 (UTC)
- If you want to do 15 edits per minute on a task like this then I must oppose strongly (there is no way you can be careful enough at that rate). Something that could potentially have errors should also not be hidden behind a bot flag. —Kusma (talk) 09:38, 5 January 2023 (UTC)
- @Kusma I would be checking all the edits, but I would like to use a bot account for it. With bot access in AWB, it makes it a lot easier to go through it semi-automatically (with manual supervision), and as it would be making a lot of edits (
- If you're checking every edit manually (which sometimes requires pausing and thinking), you don't need a bot for this. If you're not checking every edit manually, you shouldn't do this at all. Disambiguation fixing is not a task for bots and requires care and attention (quite often, 95%+ of the links need to go to one page, but that is not nearly enough to just send all to that page). —Kusma (talk) 09:19, 5 January 2023 (UTC)
- Hello @Kusma. I agree, having a bot do this automatically would be a very bad idea, but please see my responses above. The bot would not be doing this un-supervised, as that would result in a lot of accidental links like you said, and I would stop this edits straight away. The first half of my response to CX Zoom and my response to BD2412 both explain this more in-depth. If you have any other questions, please let me know! Thanks, echidnaLives - talk - edits 09:02, 5 January 2023 (UTC)
Number of women in ministry - Infobox government cabinet
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Suggestion to update the current Infobox government cabinet template to include a field to enter the number of women in the ministry (n) and the % of the ministry that are women to provide people an idea of the diversity of a government's ministry at a glance. Auseditor4you (talk) 03:59, 5 January 2023 (UTC)
- That would seem to be advocating for a particular agenda, rather than to be simply informative. I would oppose this. Zaathras (talk) 04:29, 5 January 2023 (UTC)
- Representation is not an agenda. Auseditor4you (talk) 05:47, 5 January 2023 (UTC)
- As a suitable alternative: number of men, number of women, number of people who identify as non-binary Auseditor4you (talk) 05:48, 5 January 2023 (UTC)
- This is a piece of information that people now seek - https://www.npr.org/2022/05/31/1102105392/australias-new-prime-minister-albanese-appoints-record-10-women-to-his-cabinet Auseditor4you (talk) 05:51, 5 January 2023 (UTC)
- Such information can be added to the body of the article about that specific cabinet, but certainly not added to all cabinets around the world. ✠ SunDawn ✠ (contact) 05:59, 5 January 2023 (UTC)
- Representation is not an agenda. Auseditor4you (talk) 05:47, 5 January 2023 (UTC)
- Not an appropriate use of an infobox. We base article content on what reliable sources say on the question (which will clearly vary from subject to subject), and not on our own research into 'diversity'. If it matters in say an Australian context, it can be discussed in the article body - citing the sources necessary to provide proper context. AndyTheGrump (talk) 05:55, 5 January 2023 (UTC)
- Oppose. Wikipedia is here to provide information, not to WP:RIGHTGREATWRONGS, and also not a place for WP:ADVOCACY. "Diversity" information is not critical information about government cabinets, and inclusion is unnecessary. Suppose a specific cabinet gets mainstream coverage about its diversity (or lack of diversity). In that case, it could be included in that cabinet's article, but not on the infobox that will affect all government cabinets worldwide. "Diversity" also begs more questions, why it must be about women? What about religious vs. non-religious? What about majority religion vs. minority religion? What about race? Etc. We didn't have a field for "religious composition" or "race composition" in the government cabinet infobox, I don't think we should have one for gender diversity. ✠ SunDawn ✠ (contact) 05:57, 5 January 2023 (UTC)
- I agree, on a case by case basis it might be due weight to include some sort of statistic on some intersection of members, but it varies by country as to which if any is most relevant. e.g., the Sunni/Shia split in Iraq is particularly pertinent, in New Zealand the Māori representation is specifically legislated etc. etc. We already have List_of_legislatures_by_female_members and Women_in_government which I think would be more useful for readers who are looking to compare and contrast governments globally on this one specific metric. JeffUK 11:10, 5 January 2023 (UTC)
- Oppose - while it may be appropiate to include suitable analysis in the body of an article on things like diversity if it is WP:DUE and suitably sourced from reliable sources, the infobox isn't the place to present this sort of detail.Nigel Ish (talk) 23:55, 5 January 2023 (UTC)
- Oppose - As others have mentioned, we can not focus on women as an indicator of diversity at the expense of other indicators of diversity. And if we go down this rabbit hole, and list some indicators but not others, which do we exclude? LBGTQ+ percentages? racial/ethnic breakdown? religious breakdown? Ableness? Etc. etc. We would have to stop at some point or the infobox becomes too unwieldy. And no matter where we stop, there will always be some other group that will be upset if their particular brand of diversity is not represented (how DARE we omit the percentage of Gingers in government!)
- So, no… better to not attempt to indicate diversity via the infobox at all. Blueboar (talk) 00:46, 6 January 2023 (UTC)
- Oppose and SNOW close GREATWRONGS, if you want to promote women’s rights on Wikipedia write and improve articles about them, don’t reduce them to a percentage slapped onto unrelated articles. Dronebogus (talk) 14:35, 6 January 2023 (UTC)
- Oppose not because the information is inappropriate in all cases, but because the infobox is a poor tool for discussing it. If gender equality is something that needs to discuss, then the prose of the article is the best place for it, NOT the infobox. --Jayron32 14:43, 6 January 2023 (UTC)
- Oppose. In most cases, there is no reason to mention it. If there is any need, discuss it in the article. And raw percentage is also a bit misleading - for a too-highly male government to add some women in minor positions - they can boost the percentage, but relatively meaningless; the body of the article can also discuss this. Animal lover |666| 15:53, 10 January 2023 (UTC)
Correcting Page edit
Hello every body,
Someone has edited the page "USM F.C.", that is in the start about a Malaysian club, linked about Universiti Sains Malaysia, inserting informations about Ulsan Citizen FC I presume, who already is existing. Can someone see if my propositions is correct, and in all case, the best is to restore the information about the Malaysian club and to fork the infos about the Korean club to somewhere else, whether on Ulsan FC, if it's that, or on an other page.
Thanks. Anas1712 (talk) 20:02, 8 January 2023 (UTC)
- I don't know if this belongs here, but I believe you are correct in your suggested line of action. At first glance the article about the Malaysian club seems to have been hijacked, but it seems that most of the added information is from the pre-existing Ulsan article, so this may just be a case of highly misguided editing. I would revert the non-relevant info and would try to engage the other editor(s) in the talk page as a first step. 65.88.88.62 (talk) 16:29, 9 January 2023 (UTC)
- Believe I've fixed this. An IP editor added the squad of current South Korean club Ulsan Citizen FC to the article about the defunct Malaysian club USM F.C.. Have reverted back to the last clean version of the USM F.C. article, if the IP returns then will explain it to them (though they haven't edited under that IP since September). Joseph2302 (talk) 11:57, 13 January 2023 (UTC)
Vector 2022 deployment update
Cross-posting for a better visibility: in the technical section, the Web team has posted an update on the deployment of Vector 2022. We will also be having three open meetings for anyone wanting to ask questions. Thanks! SGrabarczuk (WMF) (talk) 19:20, 10 January 2023 (UTC)
Extend Wikipedia:Do your own homework to article talk pages
I have been patrolling article talk pages for quite some time. I have seen all sorts of things happen on them, but one of the biggest issues are WP:NOTAFORUM violations. The main problem that I will be focusing on in this post is people treating article talk pages like a help desk. The revision history of Talk:Essay is a good example of the problem I am pointing out. It seems like these kinds of inappropriate discussions also occur on talk pages about academic subjects, such as Talk:Mathematics, Talk:English language, and Talk:Social studies (let me know if there are other talk pages that I have missed). Currently, the information page in question only pertains to the reference and help desks. I would like it to be extended to article talk pages. That would allow edit notices to be placed on the talk pages to redirect people asking for homework help.
Although the related problem I am going to talk about in this paragraph is about people trying to communicate with article subjects, I think it relates to people trying to get other editors to do their homework for them. People have been posting homework questions to Talk:ChatGPT, Talk:OpenAI, and Talk:Chatbot because they think they are communicating with the AI that will answer their questions for them. The first two listed have not gotten them in a while since they are currently protected (since the pages have been protected for quite a while, do you think I should request unprotection?). If my proposal gets accepted, I can combine it with an edit notice saying that article talk pages are not for communicating with the subject. SunilNevlaFan✨ 19:27, 12 January 2023 (UTC)
- It's not necessary to be overly-prescriptive in Wikipedia:Do your own homework. Feel free to kindly tell commenters that article talk pages aren't for answering questions about the article's subject or related matters. isaacl (talk) 21:52, 12 January 2023 (UTC)
- I would be surprised if there's a lot of it. I doubt if talk page commenters would answer questions within the timeframe demanded for homework, and so completely as to satisfy tthe teacher. Surely there are better places for homework answering than WP? Wehwalt (talk) 23:19, 12 January 2023 (UTC)
- Maybe a template or a semi-automated message that directs people to the reference desk would be beneficial. Thebiguglyalien (talk) 23:21, 12 January 2023 (UTC)
- Many edits of this kind will likely blow past any and all notices, but it might help at least somewhat on particularly problematic pages. If possible I'd like to limit the notices to IPs and non-autoconfirmed, but I'm not sure whether edit notices support that selectivity. If not, edit filters might work for selective notices. Alsee (talk) 00:54, 13 January 2023 (UTC)
- Given the problem of banner blindness, personally I don't feel there's enough of an issue, nor enough benefit gained in having an edit notice solely to discourage editors from using article talk pages for purposes other than improving the article. isaacl (talk) 05:04, 13 January 2023 (UTC)
- I feel that it would be a benefit even if only a few off-topic editors were to heed the edit notice. It looks like there are some talk pages listed above with weekly problems and any reduction in problems would also mean a reduction in editors having to remove the problematic conversations. --Super Goku V (talk) 11:20, 14 January 2023 (UTC)
- Banner blindness kicks in really, really quickly. Occasional questions that are ignored are not, in my view, a problem. Do you have any examples of talk pages that are difficult to use for article improvement as a result of many posts unrelated to improving the corresponding article? Plus I don't see any evidence that an edit notice is going to deter someone who isn't able to infer from context that no one is answering questions about the article's subject on the talk page. isaacl (talk) 04:46, 16 January 2023 (UTC)
- The problem to me isn't that the questions are being ignored, but that these violations also have to be removed regularly to keep the talk pages clear. Right now, the words revert or reverted appear 63 times in the last 200 edits to Talk:Mathematics. Talk:English language is worse with it appearing 160 times in the last 200 edits. It is clear that there is a problem, not just occasional incidents. Personally, we should try to avoid protecting talk pages if we can find an alternative solution. --Super Goku V (talk) 09:40, 16 January 2023 (UTC)
- I went through the last 500 edits for Talk:Mathematics and looked at all the edits that removed text (other than the archiving bot). I agree there's a significant test-edit issue on that page. Leaving aside three posts that appear to be in a foreign language that I didn't try to translate, I counted about five posts that might be problems to solve, but to be honest, given the numerous non-productive, non-sequitur edits, I assume they were just one of those and not good-faith attempts to ask a math question. Thus I don't think an edit notice will help. (I spot-checked a very small number of the reverts on Talk:English language; in that sample, they were all non-productive, non-sequitur edits.) isaacl (talk) 18:32, 16 January 2023 (UTC)
- Alright then. Maybe the only thing that can be done is to protect the talk page like ChatGPT and OpenAI or to leave them alone and just keep reverting, I guess. --Super Goku V (talk) 06:43, 17 January 2023 (UTC)
- I went through the last 500 edits for Talk:Mathematics and looked at all the edits that removed text (other than the archiving bot). I agree there's a significant test-edit issue on that page. Leaving aside three posts that appear to be in a foreign language that I didn't try to translate, I counted about five posts that might be problems to solve, but to be honest, given the numerous non-productive, non-sequitur edits, I assume they were just one of those and not good-faith attempts to ask a math question. Thus I don't think an edit notice will help. (I spot-checked a very small number of the reverts on Talk:English language; in that sample, they were all non-productive, non-sequitur edits.) isaacl (talk) 18:32, 16 January 2023 (UTC)
- The problem to me isn't that the questions are being ignored, but that these violations also have to be removed regularly to keep the talk pages clear. Right now, the words revert or reverted appear 63 times in the last 200 edits to Talk:Mathematics. Talk:English language is worse with it appearing 160 times in the last 200 edits. It is clear that there is a problem, not just occasional incidents. Personally, we should try to avoid protecting talk pages if we can find an alternative solution. --Super Goku V (talk) 09:40, 16 January 2023 (UTC)
- Banner blindness kicks in really, really quickly. Occasional questions that are ignored are not, in my view, a problem. Do you have any examples of talk pages that are difficult to use for article improvement as a result of many posts unrelated to improving the corresponding article? Plus I don't see any evidence that an edit notice is going to deter someone who isn't able to infer from context that no one is answering questions about the article's subject on the talk page. isaacl (talk) 04:46, 16 January 2023 (UTC)
- I feel that it would be a benefit even if only a few off-topic editors were to heed the edit notice. It looks like there are some talk pages listed above with weekly problems and any reduction in problems would also mean a reduction in editors having to remove the problematic conversations. --Super Goku V (talk) 11:20, 14 January 2023 (UTC)
- Given the problem of banner blindness, personally I don't feel there's enough of an issue, nor enough benefit gained in having an edit notice solely to discourage editors from using article talk pages for purposes other than improving the article. isaacl (talk) 05:04, 13 January 2023 (UTC)
RFC: Enforceability of the Universal Code of Conduct
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The Wikimedia Foundation has announced that January 17 begins voting on a second attempt to obtain approval of Enforcement Guidelines for the Universal Code of Conduct. There has been no such voting on the content of the Universal Code of Conduct itself.
The primary intended outcomes of this RFC are:
- for the community to consider this prior to casting a vote on the Enforcement Guidelines;
- informing the Foundation of any portion of the community who will not approve Enforcement Guidelines unless a Code of Conduct is approved first;
- the Foundation perhaps reconsidering whether to obtain community approval for Code of Conduct itself.
Is the Universal Code of Conduct enforceable even if the Code itself has not been formally approved by the community? Alsee (talk) 04:46, 13 January 2023 (UTC)
Responses: Enforceability
- Oppose. I will never approve Enforcement without approval of a code itself. The current Code of Conduct is botched, and without consensus the Code has no legitimacy. Consensus is especially NECESSARY as the Code is almost entirely worthless and ineffectual without active community support for it. Repeated attempts by the WMF to "improve" and re-vote the Enforcement Guidelines can never fix those fatal flaws. The WMF needs to stop trying to steamroll forwards, it is necessary to back up and let the community develop a new Code which actually gets consensus approval. Alsee (talk) 09:30, 13 January 2023 (UTC)
- This RfC seems founded on a rather narrow understanding of "approval". The UCoC was approved by the WMF Board of Trustees, the legal custodians of this project, who we play a part in selecting. Not all decisions are subject to consensus of editors and local policy specifically recognises acts of the WMF Board as one of those exceptions. The UCoC isn't the first policy to come via this route and we can enforce it with or without guidelines, just like we enforce the Terms of Use, for example. – Joe (talk) 10:12, 13 January 2023 (UTC)
- @Joe Roe even if we take accept everything you said as a given, the WMF is actively seeking community approval here. I, and anyone else, are invited to vote against the Enforcement Guidelines if we wish. We are also invited to explain why we voted that way, and to explain what it would take to get us to change our vote. If it becomes clear that continued revisions of the Enforcement Guidelines are not going to change the vote outcome, they are going to have to reconsider the path forwards. Given that they are actively seeking community approval, and given that any Code of Conduct would be almost entirely worthless and ineffectual without active community support, I believe they would be far more inclined to work with the community rather than attempting to fight the community on this. Alsee (talk) 18:09, 13 January 2023 (UTC)
- Oppose. The UCoC is well intentioned and contains many sensible rules. However, a similar and more tailored set of rules is already approved and enforced by the English Wikipedia community. The UCoC provides a model which smaller communities may choose to adopt, perhaps even by default, but neither the code nor the new police force that comes with it would be helpful to enwp. Certes (talk) 11:53, 13 January 2023 (UTC)
- Support. This RFC doesn't really seem in order, however, I agree with Joe Roe. The Code of Conduct should certainly be workshopped with editors but, in the end, the Wikipedia website and the Foundation and its legal agents or assignees can reasonably assume a baseline level of a Code of Conduct that protects their legal, as well as ethical and financial, obligations to their beneficiaries or fiduciaries or what have you. Any attempt to prevent such a thing from existing or being enforced seems to be to me not really possible let alone worth attempting to bring about. Andre🚐 19:46, 13 January 2023 (UTC)
- I think it was a mistake of the foundation's board to not get community ratification of the code itself. It was a mistake to not do it at the end of its drafting (before the Enforcement Guidelines started being drafted) and it was another mistake to not do it as part of the Enforcement Guidelines vote. However, it was not a policy violation either of the global policies or of enwiki's policies as Joe Roe points out. So we're in a situation of it was worse than a policy violation, it was a mistake territory. This means enwiki doesn't get to decide, without being asked, that the UCoC isn't policy even though we definitely should have been. Best, Barkeep49 (talk) 20:38, 13 January 2023 (UTC)
- There is a fundamental disagreement here between the community and the WMF. I suspect it will go onto the back burner until the WMF decides to take action of which we disapprove, á la Framgate. At that point, some editors will meekly roll over, whilst the rest of us will tell the WMF to stick UCoC up their corporate arse and retire noisily. Certes (talk) 22:06, 13 January 2023 (UTC)
- I appreciate that some editors won't want to enforce a code of conduct that the English Wikipedia community has not approved, and that some editors may choose to leave the community. Regarding the specific question in its current form, though ("Is the Universal Code of Conduct enforceable even if the Code itself has not been formally approved by the community?"), the answer is yes. No one can force editors to take actions on English Wikipedia to enforce anything, of course, but global policies can be set by the global community (for example, see meta:Linking to external advertising accounts) or through the authority of the Wikimedia Foundation (such as the wmf:Terms of Use). isaacl (talk) 22:34, 13 January 2023 (UTC)
- Indeed: enforcement would have to be through the WMF interfering by making edits (or other actions such as office blocks) on enwp. I don't see anyone here volunteering to do that work for them. Certes (talk) 23:09, 13 January 2023 (UTC)
- Oppose. I agree with everything User:Barkeep49 says above, except the conclusion. If it was a mistake and you don't want the mistake repeated you have to speak up. Frederick Douglass expressed it like this: If there is no struggle there is no progress … Power concedes nothing without a demand. It never did and it never will. Find out just what any people will quietly submit to and you have found out the exact measure of injustice and wrong which will be imposed upon them. Following his crystal-clear logic, there is no choice but to oppose. There is another reason to oppose as well: subject the UCoC to community vetting, and it will become a more robust, less ambiguous document. It will become better. Andreas JN466 00:34, 14 January 2023 (UTC)
- Comment Keep in mind the possibility of Wikipedia firing WMF and replacing them with somebody who isn't going awry. We're the ship that their ivory tower rides on. The mere concept might provide some perspective. A revision of the serious flaws in the bylaws which allowed the ivory tower problem to happen would prevent a repetition. North8000 (talk) 04:56, 14 January 2023 (UTC)
Discussion: Enforceability
Shouldn't the arguments about the validity of ratification be in the responses section rather than the RfC prompt itself, in line with WP:RFCNEUTRAL? — Red-tailed hawk (nest) 04:58, 13 January 2023 (UTC)
- Red-tailed hawk First, I hope you don't mind that I slid this into the new section as I created a Discussion section. Getting this RFC right was a bit messier than I anticipated.
- Are you referring to "validity of ratification" regarding the Code or the Enforcement Guidelines? And were you concerned with the mention that concerns exist with the Code (without getting into any such concerns), or the part where I try to clarify what sort of outcomes I thought this might have? Alsee (talk) 05:20, 13 January 2023 (UTC)
- If this is something like an up-or-down !vote on
Does the community endorse the UCOC, as written, and authorize enforcement of the UCOC by local administrators in a manner that treats the UCOC as English Wikipedia policy?
, then that question should be the prompt. The whole explanation regarding "there are concerns about the code" should probably be in one's rationale for supporting/opposing the enforcement or endorsement of the UCOC, rather than in the prompt itself. — Red-tailed hawk (nest) 05:34, 13 January 2023 (UTC)- Red-tailed hawk, this RFC is intended essentially as communication between community and WMF. Staff are working on assigned jobs, and I see the WMF having bad habit of deciding some stage is "complete" despite some fatal problem, then they pathologically proceed with subsequent stages attempting to finish the assigned job.
- What I was hoping for for here was lots of people to taking note of imminent Enforcement vote, hoping they they consider the unapproved-Code issue significant, hoping lots of people decide to vote against the Enforcement Guidelines, and then my key goal was to go talk to to the WMF and (hopefully) show them strong results here, convincing them that AGAIN revising the Enforcement-Guidelines for a 3rd vote would be futile.
- I didn't want to get into the Code itself here, and I didn't want to establish any sort of directive to admins. At this stage I didn't want a concrete clash between the community and WMF. At this time the WMF is seeking community approval to complete their assigned task. I want them to realize that the only path forwards towards community approval is to back up and re-open a stage that they consider "competed" and "closed". Alsee (talk) 06:20, 13 January 2023 (UTC)
- Makes sense. — Red-tailed hawk (nest) 06:24, 13 January 2023 (UTC)
- @Red-tailed hawk do you still think the RFC needs revision? Considering that no one has replied yet, I'm open to any sort of suggest for improvement. Alsee (talk) 06:28, 13 January 2023 (UTC)
- Something like
Should the English Wikipedia community ratify the text of the UCOC itself prior to voting on enforcement guidelines?
is more succinct, I think. Not sure EnWiki is entirely the right scope, but I think I understand the reason for the RfC you're launching. — Red-tailed hawk (nest) 06:32, 13 January 2023 (UTC)- @Red-tailed hawk umm, that's succinct but also runs into various interpretation problems. Trying to fit the intent here into a nice clean standard "RFCNEUTRAL" format is a mess. I'm getting tempted to scrap the "proper" RFC format, disclaiming any intent for an RFC style closure, and just stating what I'm trying to accomplish - inviting people to sign up on a collective message to the WMF saying we will never vote in favor of Enforcement Guidelines without a consensus-approved Code first. Would I make a mess trying to take a non-standard approach? Or does that sound like a solution here? Alsee (talk) 06:50, 13 January 2023 (UTC)
- I've tweaked the phrasing a bit, but I'll leave it mostly as-is. Alsee (talk) 09:25, 13 January 2023 (UTC)
- RfCs usually pose a question that the participants discuss. The question can be open-ended for general discussion, though most of them make a specific proposal. As currently worded, particularly with numbered points 2 and 3, it sounds like you are trying to promote a specific viewpoint and find supporters for it. There's nothing wrong with that in general, but typically RfC introductions are worded to allow for different outcomes, rather than assuming a specific outcome. This might reduce the effectiveness of step 3 in your list. isaacl (talk) 17:02, 13 January 2023 (UTC)
- Something like
- @Red-tailed hawk do you still think the RFC needs revision? Considering that no one has replied yet, I'm open to any sort of suggest for improvement. Alsee (talk) 06:28, 13 January 2023 (UTC)
- Makes sense. — Red-tailed hawk (nest) 06:24, 13 January 2023 (UTC)
- If this is something like an up-or-down !vote on
Can someone link previous enwiki & meta discussions on the UCoC and its Enforcement Guidelines? Thanks Fun Is Optional (talk page) (please ping on reply) 12:13, 13 January 2023 (UTC)
- There have been many. meta:Template:Universal Code of Conduct/Navbox is a good starting point. – Joe (talk) 16:41, 13 January 2023 (UTC)
As of late, the relationship between the WMF and "the community" has improved drastically (see Wikipedia:Fundraising/2022 banners and Wikipedia:Page Curation/2023 Moderator Tools project). We had the first vote on the enforcement guidelines because we made a politely-worded request. This prompted a detailed response from the BoT, including a commitment that [b]oth the UCoC and the enforcement guidelines (after ratified), will also be open for review and voter-endorsed amendments annually
. When we voted last year on the enforcement guidelines, it passed. The board responded by convening a revisions committee to address the concerns of the minority of people who opposed the guidelines, and they changed the UCoC itself based off of similar concerns. They have already shown plenty of good faith. I think an open letter requesting the promised amendment process on the UCoC itself followed by a ratification vote on the entire document is the most productive way forward. One final note: one of the recommendations from the Enforcement Guidelines Revisions Committee was that the UCoC be added to the Terms of Use. A consultation with legal about this (and some other modifications) is scheduled to begin on February 21. HouseBlastertalk 04:33, 14 January 2023 (UTC)
Approval of Enforcement Guidelines without first approving a Code of Conduct
![]() |
|
The Wikimedia Foundation has announced that January 17 begins voting on a second attempt to obtain approval of Enforcement Guidelines for the Universal Code of Conduct. There has been no such voting on the content of the Universal Code of Conduct itself.
Does the community Endorse or Oppose approval of Enforcement Guidelines prior to, or in the absence of, any community approval of a Code of Conduct itself?
This RFC is intended to determine and communicate a consensus position. Editors may consider this during current or future Enforcement Guideline votes, and the Wikimedia Foundation may consider it when evaluating how to proceed if the second Guideline vote turns out worse than the first vote. Alsee (talk) 07:53, 14 January 2023 (UTC)
Responses: Approval of Enforcement Guidelines
- Oppose. I will never approve Enforcement without approval of a code itself. The current Code of Conduct is botched, and without consensus the Code has no legitimacy. Consensus is especially NECESSARY as the Code is almost entirely worthless and ineffectual without active community support for it. Repeated attempts by the WMF to "improve" and re-vote the Enforcement Guidelines can never fix those fatal flaws. The WMF needs to stop trying to steamroll forwards, it is necessary to back up and let the community develop a new Code which actually gets consensus approval. Alsee (talk) 08:07, 14 January 2023 (UTC)
- This RfC seems founded on a rather narrow understanding of "approval". The UCoC was approved by the WMF Board of Trustees, the legal custodians of this project, who we play a part in selecting. Not all decisions are subject to consensus of editors and local policy specifically recognises acts of the WMF Board as one of those exceptions. The UCoC isn't the first policy to come via this route and we can enforce it with or without guidelines, just like we enforce the Terms of Use, for example. – Joe (talk) 10:12, 13 January 2023 (UTC)
- It's also worth pointing out that the (global) community has already approved the enforcement guidelines – the first vote was 56.98% in favour. – Joe (talk) 07:44, 16 January 2023 (UTC)
- Oppose I didn't participate in this before and I haven't really looked into it all in any depth but it seems to me that if the foundation position is that they must have the code whether community approved or not, then they can impose the enforcement as well and see what occurs. I would not personally approve the enforcement guidelines since by doing so that is in fact approving the code of conduct retrospectively. Selfstudier (talk) 08:18, 14 January 2023 (UTC)
- Oppose. I agree with everything Barkeep49 said earlier, except the conclusion. If it was a mistake and you don't want the mistake repeated you have to speak up. Frederick Douglass expressed it like this: If there is no struggle there is no progress … Power concedes nothing without a demand. It never did and it never will. Find out just what any people will quietly submit to and you have found out the exact measure of injustice and wrong which will be imposed upon them. Following his crystal-clear logic, there is no choice but to oppose. There is another reason to oppose as well: subject the UCoC to community vetting, and it will become a more robust, less ambiguous document. It will become better, more fit for purpose. --Andreas JN466 09:21, 14 January 2023 (UTC)
- I see that an abolitionist's words on fighting against racial inequality are being compared and applied to a code of conduct that prohibits
name calling, using slurs or stereotypes, and any attacks based on personal characteristics...like...race
(m:Universal Code of Conduct § 3.1 – Harassment). 🐶 EpicPupper (he/him | talk) 00:57, 15 January 2023 (UTC)
- I see that an abolitionist's words on fighting against racial inequality are being compared and applied to a code of conduct that prohibits
- Oppose. It would be grossly improper for the en.Wikipedia community to in any way endorse a 'code' being imposed without consensus by an outside body. AndyTheGrump (talk) 10:02, 14 January 2023 (UTC)
- Oppose. The UCoC is well intentioned and contains many sensible rules. However, a similar and more tailored set of rules is already approved and enforced by the English Wikipedia community. The UCoC provides a model which smaller communities may choose to adopt, perhaps even by default, but neither the code nor the new police force that comes with it would be helpful to enwp. The WMF will impose UCoC anyway, but they need to understand that this is a power grab without consensus which conflicts with the community's needs rather than satisfying them. Certes (talk) 10:59, 14 January 2023 (UTC)
- Oppose as it is inappropriate to enforce something that is not approved. Current codes and practice handles inappropriate behaviour here. Graeme Bartlett (talk) 21:41, 14 January 2023 (UTC)
- Oppose Graeme Bartlett said it perfectly. it is inappropriate to enforce something that is not approved. Current codes and practice handles inappropriate behavior here. Adding to that, if WMF insists on pushing guidelines invented by them without community approval, its time to fire WMF and replace them with an organization that has not gone astray and revised the bylaws that allowed that to happen. North8000 (talk) 22:05, 14 January 2023 (UTC)
- Oppose per all of the above (and more). Paul August ☎ 22:17, 14 January 2023 (UTC)
- Alternative - drop the facade of this being something was in any way “approved” by the community, and admit that it is something imposed by the WMF. Let them figure out how to “enforce” it. Blueboar (talk) 22:38, 14 January 2023 (UTC)
- I am not sure what this vote is about, but I am personally going to vote on Meta to adopt the enforcement. I opposed it last time and raised a specific concern. From what I see, the problematic part was eliminated, and I do not see any further issues with the enforcement.--Ymblanter (talk) 23:39, 14 January 2023 (UTC)
- Oppose per Alsee. I'm confused how we enforce a thing that has not, itself, been approved. Somehow I misunderstand. Chris Troutman (talk) 03:53, 15 January 2023 (UTC)
- I voted against the first enforcement guidelines as I thought there were enough flaws that nothing was better than those. I will be supporting the enforcement guidelines when they come up for a vote again, as enough has changed to tip me over. One concern noted above is something we don't have to worry about. No one is going to be compelled to enforce the UCoC, in the same way no one is compelled to enforce UPOL, BLP, Harassment, or any other policy (or guideline) now. In fact this removes a requirement for admin to agree to the UCoC at risk of losing their adminship and that change is one of the reasons I can support the revision. In the end this is a non-neutrally worded advisory RfC about a Wikimedia wide advisory vote to the Board who will make an actual vote. I suspect that this RfC will attract the people who are most opposed to the UCoC and I think it is important for their voices to be heard, in particular their frustration (which I share) about the lack of community ratification of the original guidelines. I also suspect this RfC will be less likely to attract the people who are mildly supportive of the guidelines but who might vote to approve them in the final vote. So I hope everyone takes note of whatever consensus is reached here - because if a consensus is reached it's worth taking very seriously - but at the same time those participating realize the limitations of what that consensus will mean. Best, Barkeep49 (talk) 05:16, 15 January 2023 (UTC)
- I generally agree with Barkeep's perspective here. — Wug·a·po·des 20:43, 19 January 2023 (UTC)
- Support - I might be the only editor on this project who voted for the enforcement guidelines last time and is looking forward to voting for it again. Yeah, it would have been better for the UCOC to be put to a community ratification vote, but that doesn't bother me so much because that decision was made by different WMF leadership than the one that is handling (well, IMO) the enforcement roll-out (cf. it passed with like 55% or so but they didn't implement it, sort of the opposite of how the UCOC itself was handled). The other reason it doesn't bother me is because the UCOC is such a vanilla document--like, it's beyond me what objections anyone could have to those provisions that aren't nitpicky--other than that it's way longer than it needs to be. But overall, put me down for being glad that there's a UCOC and hopeful that enforcement provisions will be put in place soon. That's been long overdue on this website, which has a terrible, terrible record of self-regulating user conduct over the past two decades. It's long past time for English Wikipedia to grow up and start behaving like the rest of the world and not like the wild west... which means a UCOC, and at least some method of UCOC enforcement by impartial professionals rather than volunteer members of the community. Cf. Twitter, which was improved significantly when they started being more serious about regulating user conduct on that website, and has backslid since those regulations were recently relaxed. Cf. all other social media. Levivich (talk) 20:19, 15 January 2023 (UTC)
It's long past time for English Wikipedia to grow up and start behaving like the rest of the world and not like the wild west... which means a UCOC, and at least some method of UCOC enforcement by impartial professionals rather than volunteer members of the community.
this is going to come off like snark, but I mean this sincerely: if you believe this you should vote against the UCoC Enforcement Guidelines. The Enforcement Guidelines have the Principle of subsidiarity as a major tenet which means that nearly all enforcement, including all new enforcement enabled on other projects that don't have policies and guidelines that already cover the tenets of the UCoC (unlike us), will continue to be done by volunteers (both in the sense that it's people willing to enforce the UCoC and that they are not impartial professionals). There's a path not taken where professional enforcement of the UCoC is what happens but that was not what either of the committees that drafted the UCoC Enforcement Guidelines chose. Best, Barkeep49 (talk) 02:21, 16 January 2023 (UTC)- Oh I know, but I disagree that one should vote against the UCOC Enforcement Guidelines if one believes in professional enforcement... I see UCOC and the Enforcement Guidelines as incremental steps. My prediction: both the UCOC and the Enforcement Guidelines will work, and work well. I think we will perceive no change on enwiki (for the reasons you point out: it's set up to not 'mess' with our developed self-government), and that in and of itself will be a big deal, as the enwiki community will come to realize that this is not a "power grab" or anything like that. I think, give it a few years, but it will help develop trust between enwiki and the WMF, and I hope that trust makes enwiki more comfortable with the idea of professional enforcement, which, btw, I pitched today at the idea lab in case anyone is interested (don't forget to hit that like and subscribe button). Levivich (talk) 04:32, 16 January 2023 (UTC)
- My own expectation is that there will mostly be "no change" until someone decides to try for another WP:FRAMBAN. And then the UCoC will be used to counter the opposition that ultimately resulted in the WMF's attempted ban being overturned. They've got the overbroad language that can be selectively interpreted, they've got the "protect the victim" language to justify not giving any details, they've got the language allowing them to override local processes if they think local processes "refuse to enforce the UCoC" or "lack will to address issues", they've got language mandating the committee be "diverse" in a bunch of ways (but not viewpoints) that could allow for disqualifying troublesome candidates for not being "diverse" enough, etc. Anomie⚔ 00:05, 17 January 2023 (UTC)
- In the current proposed enforcement guidelines, there is no requirement that the Universal Code of Conduct Coordinating Committee be diverse. That being said, the process for electing this committee is still to be determined by a yet-to-be formed group. isaacl (talk) 00:40, 17 January 2023 (UTC)
- There is a requirement that the building committee reflect the diversity of the movement and there is a requirement that the work of the building committee be ratified by vote. So while it's true that there is no requirement for the U4C to be diverse, but I would be amazed if there isn't a requirement by the time the U4C comes into existence. To give a peek behind the scenes, the way that the U4C building committee came to be was because I proposed some diversity requirements for the U4C and the original Enforcement Guidelines drafting committee quickly realized just how much time it would take to hammer those and other fundamental U4C questions out. Best, Barkeep49 (talk) 00:45, 17 January 2023 (UTC)
- Yes, for brevity I omitted discussion of the building committee. If the entire coordinating committee membership is elected, I can only imagine mandated diversity that covers certain broad characteristics, like geographical region. We'll see what the building committee comes up with. isaacl (talk) 00:56, 17 January 2023 (UTC)
- It says
The U4C’s membership shall be reflective of the global and diverse makeup of our global community.
True, the current "such as but not limited to" list is only in connection with the building committee, but I'd be surprised if they didn't wind up with basically the same thing for the committee itself. Anomie⚔ 10:17, 17 January 2023 (UTC)
- There is a requirement that the building committee reflect the diversity of the movement and there is a requirement that the work of the building committee be ratified by vote. So while it's true that there is no requirement for the U4C to be diverse, but I would be amazed if there isn't a requirement by the time the U4C comes into existence. To give a peek behind the scenes, the way that the U4C building committee came to be was because I proposed some diversity requirements for the U4C and the original Enforcement Guidelines drafting committee quickly realized just how much time it would take to hammer those and other fundamental U4C questions out. Best, Barkeep49 (talk) 00:45, 17 January 2023 (UTC)
- In the current proposed enforcement guidelines, there is no requirement that the Universal Code of Conduct Coordinating Committee be diverse. That being said, the process for electing this committee is still to be determined by a yet-to-be formed group. isaacl (talk) 00:40, 17 January 2023 (UTC)
- My own expectation is that there will mostly be "no change" until someone decides to try for another WP:FRAMBAN. And then the UCoC will be used to counter the opposition that ultimately resulted in the WMF's attempted ban being overturned. They've got the overbroad language that can be selectively interpreted, they've got the "protect the victim" language to justify not giving any details, they've got the language allowing them to override local processes if they think local processes "refuse to enforce the UCoC" or "lack will to address issues", they've got language mandating the committee be "diverse" in a bunch of ways (but not viewpoints) that could allow for disqualifying troublesome candidates for not being "diverse" enough, etc. Anomie⚔ 00:05, 17 January 2023 (UTC)
- Oh I know, but I disagree that one should vote against the UCOC Enforcement Guidelines if one believes in professional enforcement... I see UCOC and the Enforcement Guidelines as incremental steps. My prediction: both the UCOC and the Enforcement Guidelines will work, and work well. I think we will perceive no change on enwiki (for the reasons you point out: it's set up to not 'mess' with our developed self-government), and that in and of itself will be a big deal, as the enwiki community will come to realize that this is not a "power grab" or anything like that. I think, give it a few years, but it will help develop trust between enwiki and the WMF, and I hope that trust makes enwiki more comfortable with the idea of professional enforcement, which, btw, I pitched today at the idea lab in case anyone is interested (don't forget to hit that like and subscribe button). Levivich (talk) 04:32, 16 January 2023 (UTC)
- I don't broadly disagree with the intent of creating a UCoC, but I think that it's important to observe that the rest of the internet is (on the whole) even worse at this than Wikipedia, at least aside from smaller communities that are easier to moderate in a hands-on manner. Compared to eg. Facebook or Twitter we are vastly better at handling issues even on talk - I definitely don't agree that (even prior to their current issues) they were doing better than we are. Twitter and Facebook, for the most part, still allow, and have always allowed, things like the aggressive promotion of fringe theories or even "dogwhistle" racism, sexism, transphobia, blatant trolling and so on as long as it doesn't trip one of the few red lines they've set; similarly, aggressive harassment occurs on those platforms quite regularly as long as it doesn't cross one of their few red lines. Wikipedia isn't perfect but I feel that it has generally done better than those, and part of the reason is because of the limitations that come from trying to solve complex social issues via a set of rigid rules established from above with no input or buy-in from the community. I absolutely do not think we should be looking at Facebook or Twitter as the model for how to handle anything, ever, and I'm baffled that anyone would say otherwise - they are examples of what not to do. --Aquillion (talk) 04:24, 16 January 2023 (UTC)
allow, and have always allowed, things like the aggressive promotion of fringe theories or even "dogwhistle" racism, sexism, transphobia, blatant trolling and so on as long as it doesn't trip one of the few red lines they've set
is how I'd describe Wikipedia ¯\_(ツ)_/¯ I don't really think that Twitter or Facebook (or any other social media, or reddit, or 4chan, etc.) is any better or worse than Wikipedia, especially not Wikimedia as a whole. I don't have any statistics or way of measuring it, but in my admittedly anecdotal experience, I just don't perceive a difference between the people here, the people on any other social media I've used, and the people out there in "the real world". It's all filled with racism, sexism, -phobias, etc. If anything, I think we're a little bit worse, because we let people vote other people off the website, which gives Wikipedia more of a Lord of the Flies vibe than other sites, IMO...and I say that as a participant in many such votes. It's a YMMV situation I think. Levivich (talk) 04:36, 16 January 2023 (UTC)- I suspect we're better than those other sites you name. One reason I suspect this is that none of them have published how many of its users feel safe, unlike us. Best, Barkeep49 (talk) 00:48, 17 January 2023 (UTC)
- You're not the only one. One of the (many) problems of us only discussing the UCOC in negative RfCs like this one is that we tend not to hear from people who think the UCOC sounds like an okay idea and/or aren't into playing power games with the WMF. That in turn gives the impression that the UCOC is being imposed an an enwiki community that largely opposes it (seemingly taken as writ by many above), which we don't actually have any evidence of. The results of the last vote on the enforcement guidelines (57% in favour) would suggest that a majority are supportive – unless you think enwiki is out of step with the rest of the movement on this, which again we have no evidence of. – Joe (talk) 07:59, 16 January 2023 (UTC)
- I don't broadly disagree with the intent of creating a UCoC, but I think that it's important to observe that the rest of the internet is (on the whole) even worse at this than Wikipedia, at least aside from smaller communities that are easier to moderate in a hands-on manner. Compared to eg. Facebook or Twitter we are vastly better at handling issues even on talk - I definitely don't agree that (even prior to their current issues) they were doing better than we are. Twitter and Facebook, for the most part, still allow, and have always allowed, things like the aggressive promotion of fringe theories or even "dogwhistle" racism, sexism, transphobia, blatant trolling and so on as long as it doesn't trip one of the few red lines they've set; similarly, aggressive harassment occurs on those platforms quite regularly as long as it doesn't cross one of their few red lines. Wikipedia isn't perfect but I feel that it has generally done better than those, and part of the reason is because of the limitations that come from trying to solve complex social issues via a set of rigid rules established from above with no input or buy-in from the community. I absolutely do not think we should be looking at Facebook or Twitter as the model for how to handle anything, ever, and I'm baffled that anyone would say otherwise - they are examples of what not to do. --Aquillion (talk) 04:24, 16 January 2023 (UTC)
- Oppose. I don't think that this sort of top-down approach is workable on a site as large as Wikipedia is. We function, to the extent that we do, because of our collaborative culture, and while a UCoC is something we could benefit from, it is completely unworkable to try and impose or enforce one from above without the consensus of the community. --Aquillion (talk) 04:24, 16 January 2023 (UTC)
- Regardless of the provenance of the code of conduct, I agree with giving the community the opportunity to support or oppose the enforcement guidelines. Those who wish to oppose based on who approved the code of conduct are free to do so. Those who want to ensure that the enforcement guidelines defer to existing enforcement structures and existing guidelines (as per
UCoC violations that happen on a single wiki: Handled by existing enforcement structures according to their existing guidelines...
, from the revised enforcement guidelines) have a way to influence the process. isaacl (talk) 04:40, 16 January 2023 (UTC) - Oppose acting on them, neutral on actual voting on the EGs - I will join the gang in saying that I don't plan on ever (at least, in my role as an en-wiki admin - and I'm not planning on running for any other position in the next few years!) executing a sanction based on the UCOC here. I opposed the last set of enforcement guidelines, but am probably a weak support for the new set - although they *still* lack sufficient bits on the two aspects of right to be heard (evidentiary access and actually being heard). But while the EGs are much improved (and presumably passed by vote) the reasoning everyone else has given for the original UCOC holds true. I don't accept as a reasoning "you could always oppose the EGs if you don't like the UCOC", because that splits the reasoning with everyone who thinks it's already in place.
- The base policy text is unacceptably vague at multiple aspects, unacceptably blurs necessary and desired actions, and imposes a scope that covers every action any of us will take on this planet. It also lacks a sufficiently codified amendment structure. Per Barkeep49 - this technically is a just a community position RfC, with the issues he raises. I suppose we could do another one that would prohibit any on-en-wiki UCOC-based action that doesn't have an underlying (overlying?) en-wiki PAG as well, which could reasonably be viewed as causing quite a lot of conflict for not much practical difference. Nosebagbear (talk) 14:30, 16 January 2023 (UTC)
- Oppose per all the above. Just because the WMF is intent on imposing this, there is no reason we have to approve it. As has been pointed out, it's so vague anything we do could be an offence, or not, or it could be different based on how we identify, and they could call it anything they want and deal with it however they want. After all, they own the servers. It wasn't meant to be this way.--Wehwalt (talk) 16:46, 16 January 2023 (UTC)
- I think Barkeep49 has put it in a much better way than I could (see above):
In the end this is a non-neutrally worded advisory RfC about a Wikimedia wide advisory vote to the Board who will make an actual vote.
Also I'm somewhat skeptic about how to interpret whatever result comes out of this RFC, given there is a community consultation about EG approval via vote, which I'd expect to have higher participation than this RFC. MarioGom (talk) 20:11, 16 January 2023 (UTC) - Oppose, per (all) the other opposes. Lectonar (talk) 12:10, 17 January 2023 (UTC)
- Oppose I have to laugh at the WMF looking to take 'enforcement' action against ENWP users while simultaneously Rebecca MacKinnon (WMF VP, Global Advocacy) is deliberately attempting to interfere in UK legislation that would (potentially) hold tech executives liable for their organisation's misdeeds by mischaracterizing it as an attack on free speech. Only in death does duty end (talk) 13:15, 17 January 2023 (UTC)
- Support I don't find anything strongly objectionable in the UCOC or the Enforcement Guidelines, nor do I think they will have a significant impact on the way the English Wikipedia is run. Their influence is likely to be stronger on smaller Wikis, giving the WMF more tools to fight institutional capture by bad faith actors. The process was and is imperfect. However, the WMF is holding multiple community-wide ratification votes on these guidelines and has given many clear opportunities for us to be heard over a period of years. They have responded seriously to feedback and made changes as a result. Simply put, I think this is a net benefit for the Wikipedia movement as a whole and probably largely irrelevant to the English Wikipedia specifically. I echo what Barkeep and Levivich have said. —Ganesha811 (talk) 13:32, 18 January 2023 (UTC)
- Oppose I've seen little effort by the Foundation -- & especially the employees who were driving its adoption -- to discussing why their draft of the UCoC was a good thing. Instead, they engaged in patting themselves on the back for getting the board to adopt it (whom I doubt fully understood the document or how it would be implemented) & how it would be such a good thing. Considering the hostile acts the Foundation have taken against the volunteer communities in the past, I can't support this document without serious reservations & doubts about how it will be applied. One of the features about ruling by consensus is that one has to engage in dialogue with all parties so they know their concerns are heard, & hopefully addressed; there has been little effort by the Foundation to do exactly that. -- llywrch (talk) 21:24, 18 January 2023 (UTC)
- Oppose even being on the Arbitration Committee and hearing WMF talk about the early parts of the UCOC, I still don't really understand how it is particularly an improvement on the English Wikipedia's current mechanisms, and beyond that the fact that it was foisted upon the community and we're doing all these quasi-democratic showpieces around the thing treated as a fait accompli is beyond insulting, and against the pillars Wikipedia is supposed to operate on. The reality is regardless of what "votes" say about the UCOC, the first high-profile time someone tries to actually sanction someone based on it, we're going to get into a huge pissing contest the likes of the Fram debacle or similar WMF overreach showdowns. If they're so confident in their product, how about the community gets to decide? Der Wohltemperierte Fuchs talk 20:06, 19 January 2023 (UTC)
- Comment. I have very mixed feelings, and will make a "comment" instead of a support or oppose. It's very clear that the UCoC is going to be implemented and enforced regardless of what editors say here. The UCoC actually has been approved, just not by us. I will also say that I am actually pleased that the enforcement proposal being voted on now has removed, in response to community feedback, the implied requirement that all admins here would have to sign some sort of loyalty oath. So, on the one hand, I, like many other editors above, would like my opinion here to be heard as finding it offensive that the UCoC is being put into effect without clear community support, and that, as such, it feels wrong to ask us to approve its enforcement. But, on the other hand, I think that the proposed enforcement guidelines are as good as we are going to get, and could have been a lot worse. I'm going to say those two things, hope that both messages are heard, and accept that this RfC will be treated as advisory no matter what. And, more likely than not, en-wiki will adjudicate disputes as we choose to do, and when the day comes that we and the WMF disagree, we will have to fight that out regardless of what the WMF will have done with the input they are getting from us here. --Tryptofish (talk) 20:55, 19 January 2023 (UTC)
- Oppose I think it is quite evident how little regard WMF has for the community, and pushing though the CoC without community vote and then trying to add the associated enforcement guideline only goes to continue the pattern of disregard. It is not clear to me how another layer of rules changes or improves the situation for the enwiki community. We already have plenty of policy, rules, ToS, consensus and enforcement mechanisms as it is, and the complexity of engaging with Wikipedia already drives people away. I have never seen a serious case of disregard for community standards from any established editor, and the community has plenty of ways to police itself. Melmann 20:37, 20 January 2023 (UTC)
Discussion: Approval of Enforcement Guidelines
Note: There was a previous version of this RFC, above, with non-trivial discussion. Pinging previous participants: Joe Roe Certes Andrevan Barkeep49 Isaacl Andreas North8000 Red-tailed hawk FunIsOptional HouseBlaster Alsee (talk) 08:06, 14 January 2023 (UTC)
- @Alsee you should have a single neutral RfC question followed by a signature. But right now this RfC has neither. You could after the question then have background and then responses. Best, Barkeep49 (talk) 15:57, 14 January 2023 (UTC)
- I think it was poor form to simply discard the responses you received so far and start again. The question posed here is essentially the same as above. – Joe (talk) 07:32, 16 January 2023 (UTC)
I am going to copy my statement from above, given I feel it is still applicable despite the improved RfC format:
As of late, the relationship between the WMF and "the community" has improved drastically (see Wikipedia:Fundraising/2022 banners and Wikipedia:Page Curation/2023 Moderator Tools project). We had the first vote on the enforcement guidelines because we made a politely-worded request. This prompted a detailed response from the BoT, including a commitment that
[b]oth the UCoC and the enforcement guidelines (after ratified), will also be open for review and voter-endorsed amendments annually. When we voted last year on the enforcement guidelines, it passed. The board responded by convening a revisions committee to address the concerns of the minority of people who opposed the guidelines, and they changed the UCoC itself based off of similar concerns. They have already shown plenty of good faith. I think an open letter requesting the promised amendment process on the UCoC itself followed by a ratification vote on the entire document is the most productive way forward. One final note: one of the recommendations from the Enforcement Guidelines Revisions Committee was that the UCoC be added to the Terms of Use. A consultation with legal about this (and some other modifications) is scheduled to begin on February 21.
HouseBlastertalk 23:31, 14 January 2023 (UTC)
I am not sure what this vote is about
- Ymblanter. I'll try to clarify for anyone unsure what this is about. The issues are (1) the Code of Conduct itself has not been approved by the community, with the predictable result that (2) many people have issues with the contents of the Code of Conduct. It is impossible to "fix" either of those issues by revising the Enforcement Guidelines. The contents of the Enforcement Guidelines are irrelevant here. An "Oppose" vote here presumably indicates an intent to vote against any version of Enforcement Guidelines unless&until we have an approved Code of Conduct. That essentially says to the Foundation that it needs to back up and get an approvable and actually-approved Code first. Alsee (talk) 01:19, 15 January 2023 (UTC)
- No. ToU has also never been approved by the community, so what? Ymblanter (talk) 08:30, 15 January 2023 (UTC)
Chris_troutman I suspect your confusion/misunderstanding may be sarcasm, but in case it wasn't: The WMF took charge of producing the Code, the Board accepted it, and neither the WMF nor Board felt there was any need for community approval. I believe(?) it was pressure from various ArbComs that persuaded the WMF to graciously grant us permission to vote on the Enforcement Guidelines. They weren't originally planning on that. Praised-be the WMF, for they have so vastly improved relations and respect for the community as a partner. Oops, I think I just sarcasmed. Alsee (talk) 04:17, 15 January 2023 (UTC)
this removes a requirement for admin to agree to the UCoC at risk of losing their adminship
Again with the proviso that I have not looked at this in any real depth, that something like this was included to begin with is, I think, concerning, and makes me even less disposed to approve the guidelines. If anyone thinks that not approving them is misguided because of a lack of understanding/appreciation for the situation, I would appreciate a pointer to the relevant material.Selfstudier (talk) 13:58, 15 January 2023 (UTC)
- The first version of the enforcement guidelines included a section stating that
all advanced rights holders
should be required toaffirm [that] they will acknowledge and adhere to the Universal Code of Conduct
. There's nothing in there about what would happen if someone refused to affirm it. – Joe (talk) 07:40, 16 January 2023 (UTC)
- Houseblaster correctly notes that the WMF and the BOT has shown genuine, highly positive steps with their ultimate actions in the fundraising banner dispute. The UCOC issues however, rather significantly predate those. When the WMF finally started discussing ratification for EGs (and they at least were quite clear in those meetings it was the cross-arbcom letter that drove those), they seemed to feel that no-one had raised the desire for ratification on the policy text. When I provided the diff of I and another asking for it during the phase 1 consultations, that particular staffer seemed to ghost me for the remaining discussions - before the WMF just decided to opt for 50%+1 as a ratification margin. No adequate reason has ever been given for why, say, the policy text couldn't undergo ratification attempt alongside the EG's. Nosebagbear (talk) 14:37, 16 January 2023 (UTC)
@Levivich: - continuing this discussion on the effectiveness of Wikipedia's community-based moderation vs. Facebook and Twitter's from-above, since it seems central. Maybe we (or the WMF) should focus on producing those statistics, since we need to understand the problem we're trying to solve. But there's definitely massive volumes of studies on the problems Facebook and (even pre-Musk) Twitter have: [1][2][3] - in comparison, multiple studies have praised Wikipedia's community-based approach - caveat that many of them focus more on content, because that's what we're famous for, but: [4][5][6] Generally speaking, sources that discuss Wikipedia, Twitter, and Facebook's handling of content moderation together describe Wikipedia as a model for getting it right. I think the reason why it feels, anecdotally, like we don't is partially because our community-based system (the "Lord of the Flies" process you mentioned) tends to be loud, especially when dealing with longstanding editors - we just had that a massive incident with Athaenara, say. But that's partially because we do these things out in the open, which IMHO is necessary to catch things that more top-down systems don't and for the moderation system to scale in a way that keeps up with our size. I also think that, as "power-users" who are deep within Wikipedia, we're more familiar with the details of the places where it does fail. My concern is that if we shift to relying more on top-down rules, we'll have less big discussions like that, yes, but that will be because a lot of things slip through the cracks - I think that top-down approaches don't actually work at the scale we operate on. The sometimes riotous discussion is actually necessary for us to consider context and nuance and handle edge-cases that eg. a list of forbidden words wouldn't capture. It's also easier for a blunt top-down system to be abused - yes, sometimes we have issues here where someone is harassed and then snaps and gets in trouble themselves, but at least our processes give us some leeway to observe and understand that context; boomerangs are not uncommon. A more blunt and rigid code of conduct won't necessarily allow for that, leading to victims getting reported and banned by the very people abusing them (not uncommon on Facebook and Twitter.) --Aquillion (talk) 20:09, 16 January 2023 (UTC)
- I don't feel that Facebook and Twitter are good comparisons to Wikipedia, because whereas they are explicitly for chatter about anything, Wikipedia discussions must be related to Wikipedia editing and thus ultimately to improve Wikipedia. This provides a central guiding purpose that can be used to filter unrelated discussion. De-centralized enforcement of process can allow for more consideration of context, and that is what the code of conduct enforcement guidelines are proposing: disruption on English Wikipedia will continue to be handled by English Wikipedia's policies and enforcement procedures.
- On a side note, the problem with English Wikipedia's decision-making process is that it's a mass, unmoderated conversation amongst everyone, and that doesn't scale well to more than a small number of people. As a result, we don't necessarily get full consideration of context, as a small number of people can dominate discussion and drown out others, leading to attrition in participants. With no bar to participation, it's easy for anyone to chime in without taking time to become familiar with all aspects of the situation. It's also inefficient, taking up the time of a lot of people, and inconsistent, relying on whoever shows up on a given day. Without refinement, it's not a model for social networks to follow. isaacl (talk) 21:46, 16 January 2023 (UTC)
- @Aquillion: Yeah, I think as you say because I'm a "power user", I'm more familiar with inner workings, and that's why I beleive "the last great place on the internet" media narrative is more myth than reality--plus, as you mention, they (the studies, the media) focus on content dispute resolution (where I agree we are better than social media), but I'm talking exclusively about conduct dispute resolution (subject of the enforcement guidelines). I don't think there have been many (any?) studies of how well ANI has worked (or AE, or Arbcom, etc.). I freely concede that much of this is very subjective. In the recent massive RFA incident you mention, whether one sees that as a failure or success depends very much on one viewpoint: a block, and an unblock, and a reblock, but not a siteban. It's a glass-half-full-or-half-empty situation.
- The thing is, I don't see UCOC and UCOC enforcement as a "top-down" situation, mostly because I see us (the community) as being on top. I fully and always will support the community being the ultimate decider of policy, even though I think we should delegate some day-to-day stuff to paid professionals since we have the money. The enforcement guidleines are coming from the community: multiple votes, plus the drafting committee has community members on it, and the trustees who ultimately approve it are elected by the community. It's our document, written by our people, approved by our people. The UCOC was essentially the same except for the community ratification part. To me, neither document are "top-down" (imposed on us by the WMF).
- While I believe professional first-line-of-enforcement would reduce abusive reporting, the UCOC/enforcement guidelines don't do that, and they leave first-line-of-enforcement to enwiki, so in that sense, it's not changing, which means I don't believe that it'll have an effect on abusive reporting. However, I think the possibility for appeal to the U4C (or whatever it's called) would reduce abusive reporting by allowing another level of review, one of the things I like about the enforcement guidelines. Levivich (talk) 22:14, 16 January 2023 (UTC)
- Note, voting has opened on the UCOC-REG, I've added it to the Watchlist Notice per the precedent of the last notice. — xaosflux Talk 00:58, 17 January 2023 (UTC)
- After 3 days this RfC has, at the time I write this, attracted 22 participants who've given a topline comment in "responses". After less than 1 day of voting, the official ratification has had 151 participants whose homewiki is English Wikipedia. It appears that there will be a consensus of some kind reached here and it should be respected for what it is. But what it is not is a consensus of people interested in the UCoC on English Wikipedia. Best, Barkeep49 (talk) 15:50, 17 January 2023 (UTC)
- I agree completely. I still tend to think this RfC was created to serve as a fait accompli, and struggle to see how this could be interpreted by WMF in any way other than "micro-consensus". 🌈WaltCip-(talk) 13:33, 19 January 2023 (UTC)
- Quick question: Isn't there already a mechanism for users to vote on the enforcement guidelines? Why this second vote? Surely, anyone can go vote in the SecurePoll vote and have their voice heard that way. Why are we having a second vote here? --Jayron32 18:43, 19 January 2023 (UTC)
- If I understand correctly, the point of this RfC is to discuss whether the SecurePoll is about the right question. ~ ToBeFree (talk) 20:07, 20 January 2023 (UTC)
RfC: Quality Wikipedia rather than "building the encyclopedia".
no idea what this is supposed to be, but it’s not a proposal Dronebogus (talk) 12:30, 18 January 2023 (UTC)
|
---|
The living truth.. some parts of the community don't want high quality, they only want quantity, called "building the encyclopedia", and want to prohibit anonymous users from editing. These users would then be forced to register, and could be backtraced through their username and action taken against them in real life or online. I, for many, would rather see a quality wikipedia evolve. What is your opinion on this matter ? 194.223.29.253 (talk) 11:36, 18 January 2023 (UTC)
|
Graphic images in Vector 2022 search results
May be of interest to editors: You are invited to join the discussion at Wikipedia talk:Vector 2022 § Graphic images in Vector 2022 search results. ProcrastinatingReader (talk) 15:40, 18 January 2023 (UTC)
Provide an option to revert to the old site design
Wikipedia's new redesign attempts to align with trendy 'modern' themes, to the setback of usability. Why is there now a large amount of whitespace to the left and right of the page? That's space that could be used for text, content, or links, but is rather now an empty void. And I must also now make an unnecessary click to access the sidebar links or my talk/contribution pages.
This change is, in my opinion, detrimental to the site's usability. I therefore propose an option is provided to logged out viewers to return to the old site design. 78.151.201.169 (talk) 21:52, 18 January 2023 (UTC)
- Why not make an account? Then you can revert to the old version, or disable fixed width in the new version. Garuda3 (talk) 21:54, 18 January 2023 (UTC)
- phab:T91201 is blocking this (there is currently nowhere for logged out users to store a preference). As such, this is a non-starter; see Wikipedia:Village_pump_(technical)#Vector_2022_deployment_update and/or Wikipedia talk:Vector 2022 for more on this. — xaosflux Talk 22:29, 18 January 2023 (UTC)
- I didn't see that fixed width thing, thanks! Selfstudier (talk) 22:34, 18 January 2023 (UTC)
- @Selfstudier: in Special:Preferences#mw-prefsection-rendering uncheck "Enable limited width mode". — xaosflux Talk 23:10, 18 January 2023 (UTC)
- There is further discussion, including a solution which works for readers who are not logged in, at Wikipedia talk:Vector 2022#Use 2010 Vector as an IP. Certes (talk) 13:22, 19 January 2023 (UTC)
Should we have a more intuitive word for resizing images than "upright"?
[copied here per request from main VP talk page. — kwami (talk) 18:36, 19 January 2023 (UTC)]
Despite sizing images in absolute pixels being deprecated, that's how most of our images are. I think part of the problem might be that "upright" is not an intuitive parameter name. It certainly took me long enough to figure it out. When used on its own, "upright" makes perfect sense for scaling to 75% (of user default) for imgs in portrait orientation, but once you get to "upright=1.5" for wide images it's pretty much gibberish. I think if we introduced a more intuitive label, such as maybe "scale", we might have more success with people switching over. ("Upright" would continue to be supported, of course, but we'd have a more-easily memorized term as well.) I thought I might make a request at phabricator.wikimedia.org, but wanted to run it by here first. Would people support this, and would anyone prefer a different word than "scale"? — kwami (talk) 01:12, 15 January 2023 (UTC)
- Sounds good, for those who are still learning to write Wikisource. Of course, most editors who joined in the past few years are inserting and adjusting pictures by Visual Editor, so they have no need to learn the markup language anyway. Jim.henderson (talk) 21:19, 16 January 2023 (UTC)
- [made a Phabricator request here.]
- @Kwamikagami: can you propose this change at WP:VPR? As I have said in the phab task, the technical part of adding an alias is easy, I have "scale" ready to commit. But they may not approve it if they think there is insufficient support for this. So proposing a specific word "scale" or something else at VPR and getting consensus for it will increase the likelihood of this being approved. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 18:29, 19 January 2023 (UTC)
- Okay, copied here. — kwami (talk) 18:42, 19 January 2023 (UTC)
- For what it's worth, support! 🐶 EpicPupper (he/him | talk) 00:23, 20 January 2023 (UTC)
- Its not really a scaling parameter either and it is intended that it can be used without argument to call out an image that show be displayed/formatted as upright than lengthwise. We would need more tech support to implement a scale parameter (eg where scale=0.5 means display at 50%). Masem (t) 00:32, 20 January 2023 (UTC)
- But that is exactly what it means: "Upright=0.5" means display at 50%. I'm proposing "scale=0.5" as more intuitive phrasing for display at 50%. — kwami (talk) 00:38, 20 January 2023 (UTC)
As for the comment above that most new editors use Visual Edit and don't need to know the code, people reviewing edits will still see it, won't they? When I change pixels to upright for a wide image (say 400 or 500px to uprigt=1.5 or 2), people occasionally revert me with the edit summary that "upright" is only used for upright (portrait) images. So I suspect that a more intuitive word like "scale" would be useful even for people who use Visual Edit. — kwami (talk) 19:42, 20 January 2023 (UTC)
- If memory serves, VisualEditor doesn't support this anyway, because the future of the
|upright
parameter was unclear back when they were deciding what to put in the Media dialog box. Obviously, it hasn't been removed since then, but I'm not sure that you need to worry about VisualEditor at this stage. Whatamidoing (WMF) (talk) 21:39, 20 January 2023 (UTC)
RFC - restore "talk" from drop down
![]() |
|
Ok, so for me, there's a lot not to like about the new layout.
But someone else can start that eventual RfC : )
I just want to focus on one very specific thing: the talk link being moved to a drop down.
Hiding the talk link is a very very bad idea.
We operate on the consensus model here.
Hiding the talk link just reinforces that edit-warring is the way to go.
And no, I really don't care what some off-site discussion was - so I don't need to hear an WMF employee breezily tell me that a talk page link was determined to not be important on Wikipedia. I'm happy to engage in discussion, but don't blow us off by referring elsewhere as if this project does not matter please. (As an aside, and this goes far beyond this simple RfC - But just thought I'd mention that while I respect the WMF in general - I think it's very important - but I'm really not happy about how things seem to be being pushed through, with fewer and fewer discussions being allowed to be "open" for anyone to participate.)
Anyway, if we weigh importance, I think it's easy to agree that the talk link is more important than the watchlist link. So if space really is the issue argued, then swap them. Or maybe combine "alerts" and "notices" to save space. Or whatever other ideas people may have.
Whatever the case, un-hide the talk link. - jc37 19:30, 19 January 2023 (UTC)
RfC Discussion
- @Jc37, I'm not sure what you mean. The talk page link is just below the page title. — Qwerfjkltalk 20:37, 19 January 2023 (UTC)
- I think they mean the link to their own user talk page, which is indeed now in a dropdown (unless you have new talk page messages, in which case it's more prominent like before). Matma Rex talk 21:13, 19 January 2023 (UTC)
- @Matma Rex, I see. But people still get the big yellow notification that they have messages, so I don't see the problem. — Qwerfjkltalk 21:22, 19 January 2023 (UTC)
- anything - anything that reduces the visibility and/or ease of accessing the talk page is a bad idea. We want people to discuss. We want people to respond to talk page concerns about their editing. Not to get frustrated because they can't find the link, and thus not engage. There are innumerable reasons that hiding the talk page link is really bad. Even just from the optics of suggesting that talk pages are uninportant. I understand that this may seem an innocuous change for some, but when I consider years - decades - worth of dispute resolution, among many other things, this just really really seems an incredibly bad idea.- jc37 21:46, 19 January 2023 (UTC)
- @Jc37, so your problem is that people might get talk page message, dismiss that notification, and then not know how to find their user talk page and respond? — Qwerfjkltalk 21:59, 19 January 2023 (UTC)
- One, of several. Anything we can do to get people using talk pages, the better. We've repeatedly seen that initial talk page usage helps bridge the learning curve gap for people to turn into regular editors. It's part of why we encourage the community aspect of Wikipedia. Learning how to thread discussions on a talk page can lead to being confortable to add to lists, to add references, and just merely feeling comfortable to edit a paragraph on a page. These are called "gateways" for a reason. - jc37 22:14, 19 January 2023 (UTC)
- Most newcomers are using the Reply button, so they don't have to count colons any longer. The learning curve is essentially flat.
- The Editing team, as a result of mw:Talk pages consultation 2019, considered ways to make talk pages more visible, but it's tricky, and I don't think that they got very far. You don't want the "Talk" tab at the top to be more prominent than the article tab. You also don't want it to be more prominent than the Edit button. So at best, it's in third place. In terms of your own User_talk: page specifically, I think that Growth's Newcomer homepage work has made some difference there. Whatamidoing (WMF) (talk) 23:37, 19 January 2023 (UTC)
- I appreciate all that. I do. But all I need do is look at the default signature for editors to see that Wikipedia sees the value of a talk page link. (And yes, I'm aware that mine isn't there - user pages are important too : )
- But anyway, if it's in third place, then watchlists decidedly aren't. And while I may have done some looking around to find out the difference between notices and alerts, I doubt the average person would know, or care.
- tried and failed doesn't = push through anyway. I understand the idea of the perfect is the enemy of the good - Wikipedia is a work in progress after all. but something like this is different, we're being asked to swallow the watermelon whole, with no changebacks allwed due to fait accompli." what's done is done" and all that.
- I'm not merely complaining to the air, I've actually proposed some suggestions and welcome others. (not adding "support/oppose" sections was intentional). So if you have any ideas for a way forward, I'd be happy to hear them. - jc37 23:54, 19 January 2023 (UTC)
- I don't think that I want to get in the middle of whether the talk page or the watchlist is the more important thing to show. I imagine that most editors want both.
- But now I'm not sure that we're talking about the same thing. At the top of an article, volunteer-me sees these options:
- Article – Talk – Read – Edit – Edit source – View history – Watchlist star – More menu – Twinkle menu
- This is what I see in the new Vector 2022. Are you seeing something different? Are you not seeing the "Talk" item right next to "Article"? Whatamidoing (WMF) (talk) 21:45, 20 January 2023 (UTC)
- @Whatamidoing: I think Jc37 is referring to one's personal user talk page (
), which is in the dropdown menu for
, rather than a page's talk page (
). —Tenryuu 🐲 ( 💬 • 📝 ) 22:30, 20 January 2023 (UTC)
- @Whatamidoing: I think Jc37 is referring to one's personal user talk page (
- One, of several. Anything we can do to get people using talk pages, the better. We've repeatedly seen that initial talk page usage helps bridge the learning curve gap for people to turn into regular editors. It's part of why we encourage the community aspect of Wikipedia. Learning how to thread discussions on a talk page can lead to being confortable to add to lists, to add references, and just merely feeling comfortable to edit a paragraph on a page. These are called "gateways" for a reason. - jc37 22:14, 19 January 2023 (UTC)
- @Jc37, so your problem is that people might get talk page message, dismiss that notification, and then not know how to find their user talk page and respond? — Qwerfjkltalk 21:59, 19 January 2023 (UTC)
- anything - anything that reduces the visibility and/or ease of accessing the talk page is a bad idea. We want people to discuss. We want people to respond to talk page concerns about their editing. Not to get frustrated because they can't find the link, and thus not engage. There are innumerable reasons that hiding the talk page link is really bad. Even just from the optics of suggesting that talk pages are uninportant. I understand that this may seem an innocuous change for some, but when I consider years - decades - worth of dispute resolution, among many other things, this just really really seems an incredibly bad idea.- jc37 21:46, 19 January 2023 (UTC)
- @Matma Rex, I see. But people still get the big yellow notification that they have messages, so I don't see the problem. — Qwerfjkltalk 21:22, 19 January 2023 (UTC)
- I think they mean the link to their own user talk page, which is indeed now in a dropdown (unless you have new talk page messages, in which case it's more prominent like before). Matma Rex talk 21:13, 19 January 2023 (UTC)
- Let editors have the option to unhide the Contributions link, too. Some1 (talk) 01:32, 20 January 2023 (UTC)
- @Some1 and @Anarchyte - see Wikipedia:Village_pump_(technical)#Customizing_button_shortcuts_in_top-right_menu_area? for a userscript an editor can use to add contributions to the page top. — xaosflux Talk 01:03, 21 January 2023 (UTC)
- Support - adding the ability to choose which buttons appear outside of the user dropdown menu would be a drastic improvement. Anarchyte (talk) 08:08, 20 January 2023 (UTC)
RfC: Should Wikipedia return to Vector 2010 as the default skin?
Making dark mode more accessible
Hello, haven't edited here in a while but I feel like if we're gonna change the site layout, it might also make sense to make dark mode more accessible to users. Specifically, it should be available without needing to make an account and also at least shouldn't buried deep in the Gadgets menu, it should just be in the Appearance settings like you'd expect it to be. SemiHypercube 19:03, 20 January 2023 (UTC)
- @SemiHypercube, that's because it's a community-supported imperfect gadget. Someone said at VPT that V22 makes a WMF dark mode more likely. — Qwerfjkltalk 22:00, 20 January 2023 (UTC)
Prohibition on the locking of user talk pages
I extremely loathe how some administrators, people who are supposed to actively communicate with the rest of the Wikipedia community, become so fragile that they use their admin privileges to lock their talk pages. These are people who voluntarily signed up to run and be elected as Wikipedia admins; folks who are to aid and engage with the rest of the community for the betterment of the free encyclopedia, yet some of them instead attempt to do the opposite and actively avoid communicating with the broader Wikipedia community. I've seen one admin lock their page with a 30/500 protection, which effectively means that only the 99th percentile of Wikipedia editors can communicate with them. I've seen an editor literally create a banner stating that on their talk page, they don't want anything else beside bot comments, barn stars, and Featured/Good article announcements pertaining to any of the articles that they created. These are people who have the power to choose whether or not an article should exist, the power to block individuals, the power to rollback, the power to lock pages, and with all that power, they effectively shelter themselves from any feedback and input from the rest of the community out of what I can only assume to be a combination of mental fragility and a Russian ego.
I think that with the exception of extremely peculiar circumstances, the locking of a user's talk page should be banned. This is literally an attempt to shut down meaningful discussion about you and your role on this site for no real good reason. Any admin that locks their page should be ostracized and booted out. Knightoftheswords281 (talk) 22:29, 20 January 2023 (UTC)
- There are very real reasons why one might have a protected user talk page, such as a WP:LTA repeatedly posting oversightable information on one's talk page. Rather than leaving it to the antivandalism folks to clean up each instance of oversightable information being dumped, contacting an oversighter to oversight the information, and then repeating this process until the LTA is simply exhausted for the day, it is sometimes better to semi-protect user talk pages so that antivandalism work doesn't take so much editor time that could be spent elswhere. For that reason, I oppose a strict prohibition on protection admin user talk pages, though I agree that admins should be willing to accept feedback from IP editors and newer editors. — Red-tailed hawk (nest) 23:39, 20 January 2023 (UTC)