Wikipedia

Wikipedia:Village pump (proposals)/Archive 200

< Wikipedia:Village pump (proposals)
Latest comment: 1 year ago by WaltCip in topic Please add downloading
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

The future of Vector 2022 and software decision-making. A meeting with Selena Deckelmann

Latest comment: 1 year ago68 comments24 people in discussion
 

Let's talk about how the process of deploying and changing Vector 2022 has gone, what the current plan is, and what may be the future of software decision-making!

For over two weeks, we've been having a discussion about the steps after the closure of the Rollback of Vector 2022 RfC. I think you may be interested in the latest response from our team posted on April 6. We invite you to that discussion, but also to a meeting with Selena Deckelmann, Chief Product & Technology Officer at the Wikimedia Foundation.

We want to hear and talk about

  • Your thoughts around the deployment of Vector 2022 on English Wikipedia and other wikis
  • What the current plan is (we would like to go over our current prototype)
  • What are the options for the future of software decision-making (a discussion about the format of RfCs in this context)

This meeting will take place on Thursday 18:30, 13 April 2023 (UTC) on Zoom (click here to join / dial by your location).  We look forward to hearing your thoughts and comments. SGrabarczuk (WMF) (talk) 23:53, 7 April 2023 (UTC)

Could you post a transcript of the discussion so that editors who are unable to attend, like myself, can read what was discussed and contribute later? BilledMammal (talk) 03:27, 8 April 2023 (UTC)
+1. EpicPupper (talk) 19:53, 8 April 2023 (UTC)
I can't help pondering if you meant "so that editors ... can read what was discussed and complain later". :-P — JohnFromPinckney (talk / edits) 19:59, 8 April 2023 (UTC)
+ 1 to BilledMammal's proposal. The whole handling of V2022's rollut and the total disregard for the Wikipedia community's opinion has been disappointing and disheartening; discussions have been futile, and I have personally lost motivation to contribute. Æo (talk) 21:08, 10 April 2023 (UTC)
They didn’t respond to this, but I’m sure they will. They always post transcripts. Snowmanonahoe (talk) 14:45, 11 April 2023 (UTC)
Thanks for the invite. It is truely discouraging to see that this high-level discussion and feedback only happens after there's noise at English Wikipedia, when most of the concerns could have been solved before deploying, just listening to the smaller projects and communities that were participating in the beta testing. There, we only had silence or even trying to canvas those who proposed how to do things better. I hope the team is now ready to solve the issues, as the problems and wrong decisions are experienced by a larger and noisier community. -Theklan (talk) 17:23, 8 April 2023 (UTC)
I mean, there were also concerns about the WMF's active canvassing of off-wiki tech people to side with their rollout in order to "win" the discussion after the rollout was being strongly opposed by the community, in direct contravention of multiple Wikipedia policies. But I suppose that's not a conversation we're ever going to be willing to address. *sips tea* SilverserenC 17:35, 8 April 2023 (UTC)
Maybe not fair to say "WMF's active canvassing", when it was one person acting against WMF instructions? —Femke 🐦 (talk) 18:25, 8 April 2023 (UTC)
Considering they didn't try to reverse it and still happily used the "consensus" numbers to argue for keeping Vector, I don't think the one person argument really holds up. It still benefited the WMF as a whole and they ran with it. The one person was just a convenient excuse. SilverserenC 18:42, 8 April 2023 (UTC)
I think you are confusing (or actively misinterpreting) the community vs WMF. The canvassing was done by a WMF staffer, and the community was informed of it. Every action after on that front (Closing the discussion, deciding if we're keeping vector or not, deciding how much we discount those !votes) are something the community did.
If you have a problem with that close, please take it up (again) with WP:AN, instead of putting the blame on WMF as a convenient target. Soni (talk) 02:41, 10 April 2023 (UTC)
That one person subsequently quit (or was asked to leave) btw. While unconfirmed that it is related to that incident, it seems likely. —TheDJ (talk • contribs) 15:27, 11 April 2023 (UTC)
All of the canvassed votes were basically ILIKEIT and from Isabelle's comments appear to have been disregarded. Plus BilledMammal has a summary that indicates the canvassing didn't really affect the outcome percentage. Aaron Liu (talk) 14:23, 12 April 2023 (UTC)
I guess we'll keep on flogging the dead horse. — Qwerfjkltalk 21:50, 8 April 2023 (UTC)
I would think we were already down to just bones. Donald Albury 21:59, 8 April 2023 (UTC)
Can we at least acknowledge the horse's existence? Someone killed it, but we're pretending it's still alive and everyone who passes by its corpse just whistles super loudly. Me flogging it means people can't tell me to stop without acknowledging the corpse is there. :P SilverserenC 22:02, 8 April 2023 (UTC)
It's a dead horse because the WMF have pulled WP:CONEXCEPT, backed up by marketing masquerading as science. But they need to understand that doing so destroys editors' confidence in the WMF's fitness for purpose, and repositions them from colleagues to opponents. Certes (talk) 22:37, 8 April 2023 (UTC)
Then perhaps we should revisit WP:CONEXCEPT. Thebiguglyalien (talk) 00:39, 9 April 2023 (UTC)
This one's out of our hands, as we have outsourced our software development and hosting to the WMF, who can release new versions at will without our consent. However, plans are afoot to amend the site CSS to restore full width as the default, and I understand that can be done without changing the MediaWiki software or its site-wide installation options. Certes (talk) 10:10, 9 April 2023 (UTC)
@Certes: Not entirely. We have a big stick that we have used once in the past, and I have been considering proposing changes to conexcept that would formalize when and how we could use it.
The stick is our control over their largest fundraising route, and in the past we have used the threat of cutting off that route to force the WMF to address issues with the fundraising messages. My thinking is that our control over this route doesn't need to be a binary on/off; for example, if we had a consensus that WP:THEYCANTHEARYOU needs to be fixed, then we can limit the number of days the WMF is permitted to fundraise in a given market on enwiki if they refuse to commit the necessary resources to doing so.
However, this is the wrong place to discuss that; if you want to discuss it further, let me know. BilledMammal (talk) 02:31, 12 April 2023 (UTC)
This year a sizeable chunk of the community opposed already-optimized fundraising banners, and now the WMF is doing layoffs of 5%. EpicPupper (talk) 02:33, 12 April 2023 (UTC)
This year a sizeable chunk of the community opposed already-optimized fundraising banners Could you link that discussion? The most recent I am aware of was the November 2022 RfC, which rejected the banners used by the WMF. BilledMammal (talk) 02:38, 12 April 2023 (UTC)
@BilledMammal I am referring to the November 2022 RfC; meant this fundraising year / cycle. Wikipedia:Fundraising/2022 banners. Lower revenue due to worse-performing fundraising directly contributed to the layoffs. EpicPupper (talk) 02:48, 12 April 2023 (UTC)
Ah, thank you. I'm not seeing it directly stated that the cause was lower revenue, but it seems like a reasonable conclusion. However, if the WMF had listened to our concerns earlier and taken the time to design banners that addressed those concerns then I don't believe we would have seen as significant a drop in revenue; banners at the end of the fundraising period were performing much closer to their historical levels than banners at the start of the fundraising period.
Part of the reason why I would want to formalize how we use this stick is to address that; to allow us to make it clear to the WMF that we intend to use the stick so that they have time to address the issue. However, as I said this is the wrong place to discuss that; if you want to discuss this further perhaps leave a note on my talk page? BilledMammal (talk) 03:23, 12 April 2023 (UTC)
That's not ideal, but it was considered less bad than having people donate in the mistaken belief that the WMF faces bankruptcy or that the money goes mainly to Wikipedia. Certes (talk) 09:27, 12 April 2023 (UTC)
It's not ideal to disrupt employees' livelihoods and force them to confront grave personal and financial decisions over an issue of banner wording, no. It certainly isn't ideal in the least. --⛵ WaltClipper -(talk) 14:46, 15 April 2023 (UTC)
They shouldn't need that many employees in the first place though. You can also see WP:CANCER. Aaron Liu (talk) 18:37, 15 April 2023 (UTC)

CANCER does not consider the vast amount of resources and spending to run an organization supporting one of the most trafficked sites in the world. EpicPupper (talk) 18:47, 15 April 2023 (UTC)

It counts though.

The modern Wikipedia has 11-12 times as many page views than it had in 2005, but the WMF is spending 33 times as much to serve up these pages to the readers. This seems reasonable given that they have improved reliability, redundancy and backups. More concerning is the fact that since 2005 the WMF has hired hundreds of extra employees and is now spending 1,250 times as much overall, which seems rather excessive considering that the actual amount of work they have to do is pretty much the same. WMF's spending has gone up by 85% over the past three years.

Aaron Liu (talk) 20:50, 15 April 2023 (UTC)
The author has zero background in administration or management. As the movement grows, the WMF must took; it is taking on many novel initiatives like the Community Wishlist Survey, Universal Code of Conduct, and Movement Charter. EpicPupper (talk) 21:18, 15 April 2023 (UTC)
Problem is, Wikipedia's activitypopularity isn't growing, at least not in the past 8 years. Aaron Liu (talk) 21:26, 15 April 2023 (UTC)
(correction: the WMF must too, not took)
Measuring success by simple pageviews is shallow at best and deceptive at worst. EpicPupper (talk) 22:06, 15 April 2023 (UTC)
Some of us don't want the WMF to divert its resources to a Universal Code of Conduct or a Movement Charter, and see those outputs as a way to mop up excess money rather than a sign of success. I am a volunteer editor, not part of a "movement" which implies support for the WMF's opinions and political views. Certes (talk) 22:29, 15 April 2023 (UTC)
I'm measuring how much money needed to maintain servers, which is usually proponent to traffic. Plus, as Certes said, the amount of projects is growing quite fastly concerningly, especially when a source of income is Wikimedia project sties' donation drives, which do have a finite userbase. Aaron Liu (talk) 01:52, 16 April 2023 (UTC)
It is inappropriate to engage with the community on this topic via zoom. It is especially galling that after all of the criticism of the incompetence of the engagement prior to vector 2022 you have continued to put announcements in these hidden away areas that nobody checks.
Stop approach the community reaction as a problem to be managed in order to smooth the rollout of something you've already decided to commit to. Shinanoki (talk) 23:27, 9 April 2023 (UTC)
hidden away areas that nobody checks this page has 3,623 watchers. CentralNotices have also been published. EpicPupper (talk) 23:42, 9 April 2023 (UTC)
Also note re It is inappropriate to engage with the community on this topic via zoom: as linked in the original post above, an on-wiki discussion has been up for over two weeks and is still open. EpicPupper (talk) 23:44, 9 April 2023 (UTC)
3,623 people is nobody and entirely comprised of irrelevant people.
If you are an editor then by definition your opinion on vector 2022 is irrelevant, you have the tools to fix the problem.
The only people who matter are non-editing users and effectively none of those people watch these sorts of spaces.
Wikipedia knows how to get in contact with its users in a general sense, its what it does for fundraising and did with SOPA/PIPA. Anything less in terms of outreach is irremediably lacking in legitimacy for these sorts of basic changes. Shinanoki (talk) 08:14, 10 April 2023 (UTC)
While I personally support the launch of Vector 22, specially for the width and the less scrolling thanks to the TOC sidebar, I don't like the form it was launched with a minority winning over a majority several times. For me this doesn't raise trust in consensus nor the closers of the discussions. And several scripts do not work with Vector 2022 the way they did with Vector 2010. That this one is now hidden in a drop down menu, I'd say hampers a bit the work of some reviewers. At least I feel less encouraged to review a page. For future decisions I suggest you collaborate also with the script developers. The scripts are also a part of wikipedia.Paradise Chronicle (talk) 13:10, 10 April 2023 (UTC)
Ehh, I believe it this one, which doesn't work well anymore for the reviewers. Sorry, for the confusion.Paradise Chronicle (talk) 13:17, 10 April 2023 (UTC)
Uups, well it seems it was this one, as the other one I have not installed. Maybe it's also another one, who knows? Found out as I was looking for a solution with its developer. Anyway, before the launch I had a button at the toolbar header with page curation, now it's gone. And it's not the only by script installed button that is somewhere else.Paradise Chronicle (talk) 07:19, 11 April 2023 (UTC)
Just a note that scripts are not officially supported parts of the software stack. That is WHY they can exist and why the page that allows you to add them, literally has a BIG RED "User scripts are not centrally supported and may malfunction or become inoperable due to software changes." notice. All script editors had 3 years to prepare and engage during the beta fase. —TheDJ (talk • contribs) 15:33, 11 April 2023 (UTC)
Thats quite an answer. So the WMF had three years to prepare and yet Vector22 still had such an opposition and apparently really easy to solve flaws? Then also, the script developers are volunteers and the WMF developers are paid. I'd argue its for the paid staff to adapt. At least this could be considered in the Software decision-making talk with Selena Deckelmann.Paradise Chronicle (talk) 16:22, 11 April 2023 (UTC)
No. thats not how any of this works. In ANY normal website user scripts don't even exist. The community gets this freedom with the EXPLICIT condition that it is not supported. The alternative is that you don't get it at all. —TheDJ (talk • contribs) 08:55, 12 April 2023 (UTC)
Also, I'm pretty sure that WMF employees fixed about as many (abandoned) scripts as the community developers fixed themselves. So the WMF employees are already doing what you are screaming at them to do. User scripts are simply problematic (which is why no other website allows such a thing). —TheDJ (talk • contribs) 09:03, 12 April 2023 (UTC)
Several of the user scripts I had installed worked differently until the launch of Vector 22 and some stopped to work entirely. It's my personal point of view that this cold be improved if decision-making in software is at stake.Paradise Chronicle (talk) 08:17, 15 April 2023 (UTC)
Every actually new skin breaks scripts. Unless v22 includes a clone of v10, some scripts will break, just like every skin change before. Aaron Liu (talk) 13:21, 15 April 2023 (UTC)
The proposals village pump is probably the most public place they could’ve posted this. What would’ve been better? Snowmanonahoe (talk) 14:49, 11 April 2023 (UTC)
I think they mean putting bits in the zoom call - whether that be announcements, reasoning, or consultations in the call that's not in the text I don't know. Nosebagbear (talk) 15:07, 11 April 2023 (UTC)
Like I said if they sincerely want to reach the population that is actually impacted by the default skin, they know how to do this and have demonstrated it. Its to insert a big splashy notice at the top of whatever page you're viewing.
Nobody who just uses wikipedia as an encyclopedia and isn't an editor ever visits the village pump. They're also the only people who need to be reached. Shinanoki (talk) 19:47, 11 April 2023 (UTC)
The Village Pump isn't just an acceptable place to propose changes but the expected place. Just as citizens in a community have to vote or participate in town meetings to have a say in governance, Wikipedians have to participate at the village pump (that's why it's called that). And as a general rule, WP:Single purpose accounts such as yourself generally aren't given much weight in these discussions. Thebiguglyalien (talk) 19:50, 12 April 2023 (UTC)
It is normally the place to propose changes, but this is an atypical case with disproportionate impact on people who just use wikipedia as an encyclopedia. No normal user ever visits this place.
And you can talk about single purpose accounts and its normally a sensible heuristic but if a decision generates accounts because people now need them to make wikipedia not look like trash and themselves shift from their typical heuristic of "people are probably by and large handling things reasonably behind the scenes" into advocacy then its a pretty absurd thing to point to that as evidence to discount their views. Shinanoki (talk) 15:05, 13 April 2023 (UTC)
As stated, a CentralNotice visible to everyone was up for quite some time. EpicPupper (talk) 22:46, 13 April 2023 (UTC)
No CentralNotice constitutes visibility for this sort of thing Shinanoki (talk) 05:54, 14 April 2023 (UTC)
Feel free to leave a suggestion about what you think would be best! EpicPupper (talk) 15:47, 14 April 2023 (UTC)
As I have said, if outreach was being taken seriously then it deploy the tools used when its perceived as important to get a hold of non-editors: the top of page notice used for fundraising. Shinanoki (talk) 19:09, 14 April 2023 (UTC)
That’s… what a CentralNotice is. Snowmanonahoe (talk) 19:38, 14 April 2023 (UTC)
Okay, let me rephrase. The special case of CentralNotice where it is delivered to all readers over and over again such that nobody fails to register that "yeah, wiki is doing another fundraiser" vs the general case.
I never saw a banner for Vector 2022 and I don't know anyone who did. Shinanoki (talk) 20:06, 14 April 2023 (UTC)

@SGrabarczuk (WMF) can speak to the specifics of the CN config. EpicPupper (talk) 20:21, 14 April 2023 (UTC) https://meta.wikimedia.org/wiki/Special:CentralNoticeBanners?filter=DesktopImprovements m:CentralNotice/Calendar/Archive Aaron Liu (talk) 20:32, 14 April 2023 (UTC)

Holding the discussions on-wiki. Any discussion that takes place off-wiki, whether it is in a zoom call or a movement forum, will exclude the majority of editors. BilledMammal (talk) 02:24, 12 April 2023 (UTC)
It is inappropriate to engage with the community on this topic via zoom. Exactly! I was thinking we should all sail to the point in the Atlantic ocean exactly half way between the UK and US coastlines and wave signs written in red on a green background at each other between our boats, co-ordinating the whole meetup over an invite-only IRC channel where all the messages you send can contain nothing but WP policy shortcuts. small jars tc 21:14, 11 April 2023 (UTC)
We'd probably get more done that way. — Qwerfjkltalk 21:24, 11 April 2023 (UTC)
Is it possible to have two meetings, so that editors that are unable to attend due to time-zone issues or other commitments can do so? I have an exam at that time, for example, so can't attend even if I'd like to so having an afternoon session at 18:30 as well as a morning session (say, 11:00) on Thursday or Friday would be welcome. — Ixtal ( T / C ) ⁂ Non nobis solum. 14:52, 11 April 2023 (UTC)
SGrabarczuk (WMF), will we be able to read a summary of the discussion at some point? — Ixtal ( T / C ) ⁂ Non nobis solum. 15:00, 14 April 2023 (UTC)
Thank you to everyone who came to our meeting yesterday. We had an interesting discussion. For those who couldn't make it, we're posting notes with anonymized volunteers' comments. SGrabarczuk (WMF) (talk) 20:43, 14 April 2023 (UTC)
Thanks for the update. Sorry that I didn't take part, but I sort of didn't believe votes coming from editors would be considered. Sure, no democracy, Conexcempt, but run your tools through Wikipedia and see how many times a minority won against a majority and this repeatedly. My experience is that you one can cite as many policies you one wants, if a majority is against it the idea, the policy won't be considered. As said before, I am not so much against the launch, but more the process of the launch and concerned over the trust in consensus and the closers of discussions.Paradise Chronicle (talk) 08:37, 15 April 2023 (UTC)
 
I'm the person who asked about nailing down an API. Let me give some examples of where I was going. The first example is the attached screenshot. There's two different javascript things running. One (User:DannyS712/DiscussionCloser.js, IIRC) adds the "Close" link. The other is some WMF-supplied widget that adds the "subscribe" link. They both work, but obviously used slightly different methods to insert the links. Probably just different CSS; I haven't looked under the covers. In any case, there should be a standardized way to attach a link to a page section, so it not only gets formatted uniformly, but also continues to work as skins get updated.
The second example is the discussion at WP:VPP#RfC: Removing "Clear the watchlist" from main watchlist screen. There are a whole bunch of things which we expect will appear on every page, in every skin.
For example, I'd expect that somewhere there will be someplace that displays what categories a page belongs to. Looking at the (legacy Vector) generated HTML, I can see that there's a <div id="catlinks" class="catlinks" data-mw="interface">. Looking at the Vector 2022 HTML, I'm pleased to see there's a div with exactly the same id and class, and drilling down a bit, I even see some deeper structural similarities like id="mw-hidden-catlinks". So, that's great that those things didn't break, but the next step would be to have a commitment that this isn't just happenstance, but it is the way categories are marked up. That'll give script authors a fixed target to code against.
As an example of how not to do it, I've got some script installed which adds a useful link after every IP address. I'm assuming the author of the script looked at a few pages, saw how IP addresses were marked up, and wrote some jquery pattern to find them. Unfortunately, it works on some pages and not others, which I assume means some pages mark up IP addresses one way, and some do it another way. Having a definitive "this is how you mark up an IP address" standard would keep everybody in sync. And more importantly, if somebody does it wrong, it would give you someplace to point to and say, "Hey, look, it says here you're supposed to be doing X, and you're doing Y; fix your code to make it do X". -- RoySmith (talk) 19:36, 15 April 2023 (UTC)
Hi @RoySmith we've been intentionally standardizing markup. You are right when you point out the category markup is consistent. However there's no guarantee right now that it won't in future if code contributors change. The only thing that is considered stable is adding a link to categories. e.g. 
mw.util.addPortletLink('mw-normal-catlinks','#', 'hello')
will work now, and in future because we have an API built to support gadget developments.
Regarding "a commitment that this isn't just happenstance" - as I said on the call, my hope is we can establish some set of guidelines around this, which is why I've been working on mw:Recommendations_for_gadget_developers_on_Wikimedia_wikis and mw:User:Jdlrobson/Stable_interface_policy/frontend. Without both of these there can be no commitment from either side. A frontend policy would specifically force frontend developers to think about gadget support ("MediaWiki developers MUST regularly review popular gadgets to evaluate missing APIs using the global-search tool. ") AND the recommendations page would provides a means for community members to request APIS where none is available (see "Wiki-based code developers SHOULD NOT assume that certain HTML structures and classes that are used now will be used in future and are encouraged to request explicit APIs for absent use cases.")
In the example of your link after the IP address, that's not currently an API and the HTML can change at any point so there's no guarantee your code will not be breaking in future.
If this all sounds good (or even problematic) please let me know on the corresponding talk pages. Even a short note of support there would be helpful at this point :) but improving the document format or wording is also appreciated. We would really like to get something in place that makes gadget development easier on both parties as it's not fun for anyone involved when a popular gadget breaks. Jdlrobson (talk) 00:18, 18 April 2023 (UTC)
Latest comment: 1 year ago3 comments2 people in discussion

I mean, the title explains what this means, but I just think that it would be nice to customize all of the different colors. This isn't critical, but it would be kind of nice. Thanks for taking the time to read this. Rushpedia (talk) 15:31, 20 April 2023 (UTC)

@Rushpedia Have you considered using a Browser extension or a User script in commons.js or vector.js for it? This link explains how to do what you want, I think. Soni (talk) 15:37, 20 April 2023 (UTC)
Sadly, I can't use any extensions like that because my school will restrict any extension unless it's allowed by the administrators. As for JavaScript, I'm going to try it once I'm done with school today. I hope it will work. Thanks a lot! Rushpedia (talk) 16:54, 20 April 2023 (UTC)

New font: many important buttons are missing on mobile

Latest comment: 1 year ago1 comment1 person in discussion
  Moved to Wikipedia:Village pump (technical)
 – Nardog (talk) 11:39, 24 April 2023 (UTC)

Add "Ban April Fool's Day Pranks" to perennial proposals list

Latest comment: 1 year ago31 comments18 people in discussion

I have been editing Wikipedia since 2005, and I'm never proud of the pedia on April 1. The willful abuse of our systems for vandalism prevention completely breaks down on this calendar day. All of a sudden it's like "festival" (from Return of the Archons) where every unthinkable crime becomes more than thinkable, it becomes actionable. Yesterday a portion of our core content policy was nominated for deletion. This is neither humorous nor good fun, no matter what day of the year on which it occurred. In my opinion, sysops the community should not allow or forgive these sorts of pranks in anyspace anyday on Wikipedia. If next year I was committed to combatting this vandalism correctly applying policy and guideline, I would expect my mop to be under discussion afterwards (or perhaps on the day). This is an uncomfortable situation for the community to put a good faith protector of the pedia to be in. But actually changing that situation is not what I propose here. What I do propose is adding my argument (along with the many many previous ones decrying our yearly abandonment of policy and guidelines) to perennial proposals. BusterD (talk) 18:20, 2 April 2023 (UTC)

  • Support as proposer. BusterD (talk) 18:20, 2 April 2023 (UTC)
  • Well hmmm... If I'm reading it right, you would 1) like to ban April Fools nonsense, but 2) recognize that that is not going to happen because too many people like April Fools nonsense, so instead of finding some way around to that to stop it some other way, you're giving up. And suggesting we stop wasting time every year on something that's not going to happen. Correct?
    Are you sure you're on the right website, lol. No, this is very commendable. It's just not something you see every day here or anywhere. I agree with you on on the not-wasting-time angle, and also I guess on the merits, that it's cheerless enough here without giving the no-fun crowd another win (I guess; I'm not really up on the details of what happens here on April 1). So, support. Herostratus (talk) 21:45, 2 April 2023 (UTC)
    My suggestion may look a bit pointy. Since we're not going to do anything about such disruption, we should probably file such attempts to stop it appropriately. Maybe I'm misreading the room. If administrators are not allowed to combat clear and intentional vandalism for a 24 hour period, perhaps we should all decide to take the entire day off. BusterD (talk) 22:45, 2 April 2023 (UTC)
    BusterD are you not of the body? -- RoySmith (talk) 22:52, 2 April 2023 (UTC)
    This is precisely the question under discussion. Who is of the body? What behaviors does the community desire? Is "The Purge" to be our model for behavior one day a year? No law at all? Because that's where this is heading. BusterD (talk) 23:02, 2 April 2023 (UTC)
    The "law" in question is WP:Rules for fools, which has been hashed out in a series of RfCs. You'd be well within your rights to warn or block anyone who doesn't stick to the rules, and I think the community at large would support you in that. (GeneralNotability made a good block this year which seems to have gone unchallenged.) The MfD you mention was transcluded in the wrong place and not tagged as humour; that was worth a warning. If admins are unwilling to admin for fear of pushback, that's a problem in need of discussion, so I don't agree with the thrust of your proposal, which is to simply give up on the idea that April 1st rules can be enforced. Sojourner in the earth (talk) 05:24, 3 April 2023 (UTC)
    Listing a proposal to ban April 1 jokes on Wikipedia:Perennial proposals is not, in my view, giving up on enforcing limits on April 1 jokes. It's just capturing some of the frequently raised points in the various past discussions on a complete ban, so any future discussion can pick up from there. isaacl (talk) 06:22, 3 April 2023 (UTC)
    Just a neutral observation: WP:Rules for fools is is an information page, not one of Wikipedia's policies or guidelines. Please never ban or block anyone for not heeding one of our over 300 information pages that the user probably isn't even aware exists. Thanks. CapnZapp (talk) 08:13, 3 April 2023 (UTC)
    The information in question is a summary of global community consensus as hashed out in the three heavily-attended RfCs linked to in the lead. And that consensus essentially boils down to "don't be disruptive", so not knowing about that particular page doesn't excuse anything. Sojourner in the earth (talk) 09:26, 3 April 2023 (UTC)
  • Taking the day off might work. I don't think you're misreading the room, and I sympathise, though you might be a little near the fringe. I'm not really in the have-no-fun-at-all camp, but when I find myself reverting this kind of thing, I'm reaching for the block button. Fools take note for next year. -- zzuuzz (talk) 22:59, 2 April 2023 (UTC)
  • Support inclusion as a recurring viewpoint that has not been widely adopted. On that issue: I think most people would agree that total anarchy and a total fun ban are both nonviable. We have Wikipedia:Rules for Fools, and I think it's entirely reasonable to consider violations as conduct issues. Maybe even toughen it up a bit. Thebiguglyalien (talk) 23:34, 2 April 2023 (UTC)
    Please accept that most users have likely no idea this information page even exists. CapnZapp (talk) 08:17, 3 April 2023 (UTC)
    One page. For one day out of the year. It's not that difficult to direct them to it, and once directed, they should know - much like notices for editing in a contentious topic. --⛵ WaltClipper -(talk) 17:34, 3 April 2023 (UTC)
    WP:Rules for Fools doesn't really introduce any new "rules" of its own rather than just reminding editors of relevant policies. Not knowing that Rules for Fools exists is no excuse for edit warring or BLP violations. Thebiguglyalien (talk) 17:58, 3 April 2023 (UTC)
    Perhaps we could edit the sitewide edit notice so that it displays a link to that page on April 1st? 192.76.8.84 (talk) 14:00, 7 April 2023 (UTC)
  • Support I agree almost entirely with both parts of this statement: this clearly is a perennial proposal, with lots of re-proposals of it findable in the archives of Wikipedia talk:April fools and Wikipedia talk:Rules for Fools, but clearly doesn't have consensus, even though I personally have become more in favor of it every year. * Pppery * it has begun... 23:43, 2 April 2023 (UTC)
  • It's just an informational page—if you think it will be helpful to add, go ahead! (If someone objects for some reason, the change can be reverted and it can be discussed then.) isaacl (talk) 01:07, 3 April 2023 (UTC)
  • I've been around longer than the proposer, & IMHO there will always be pranks pulled on April 1st, no matter what policy is set. Some pranks will actually be good ideas (e.g., nominating articles for DYK, GA, & FA that have a hook with a humorous twist), some not so good (anyone else remember the time WP:AfD was nominated as a Featured Article on the basis that "it's had a lot of work, more than any other article, so maybe it's time we consider it for this honor"?). So maybe this should be filed under perennial proposals, unless someone can come up with a new twist. I'll admit that a proposal along the lines of "Any editor who repeats a prank on April 1st that has been pulled in the past will be sanctioned" has a certain appeal: at the least, it'll slow down the pranksters by forcing them to do their homework & be more creative. -- llywrch (talk) 06:52, 3 April 2023 (UTC)
  • Given how tame April Fools has been recently (getting less and less disruptive from year to year; I don't think anyone has changed the "delete" button to something else in more than a decade) it may be time to stop talking about banning the pranking. But I don't think this proposal will do anything substantial, so strong meh. —Kusma (talk) 10:01, 3 April 2023 (UTC)
    Surely it getting tamer is actually a reason to be against such a change, since it would be provoking disagreement over less of an issue? Nosebagbear (talk) 16:36, 3 April 2023 (UTC)
  • Support —CX Zoom[he/him] (let's talk • {C•X}) 18:58, 3 April 2023 (UTC)
  • Support adding "Add "Ban April Fool's Day Pranks" to perennial proposals list" to the perennial proposals list JeffUK 23:19, 3 April 2023 (UTC)
Meta-nonsense. Open at your own risk.
The following discussion has been closed. Please do not modify it.

Proposal to ban using Musicstax as a source

Latest comment: 1 year ago2 comments2 people in discussion

It became a widespread trend on Wikipedia to use the Musicstax as a source for describing a pop song. Unfortunately, every time I see it, the website is wrong in describing a key and a BPM number. I contacted the Musicstax owner and he said it fetches the data from Spotify. The Spotify’s API gives you the ability to extract several audio features of a song[1] though it is not clear how Spotify assigns BPM numbers and keys parameters: Key is something that "integers map to pitches using standard Pitch Class notation and BPM is overall estimated tempo". I propose to stop this trend although I have no better sources that authors could use instead. Dignitee (talk) 13:50, 25 April 2023 (UTC)

@Dignitee, these things are handled over at RSN. See the last bullet point under Additional notes at the top of that page for instructions. 199.208.172.35 (talk) 14:41, 25 April 2023 (UTC)

Infobox for Colleen Ballinger

Latest comment: 1 year ago1 comment1 person in discussion

Should the biography article of Colleen Ballinger have an infobox? This topic still appears to be contentious so each one has to be resolved via RfC. Community input is appreciated. Thanks! - Nemov (talk) 19:35, 27 April 2023 (UTC)

Proposal to subdivide Category:Wikipedia pages about contentious topics

Latest comment: 1 year ago4 comments2 people in discussion

As I posted at Category talk:Wikipedia pages about contentious topics: With nearly ten-thousand articles in this category, I wonder if perhaps we can divide out some subcategories for specific large groups of contentious topics, such as those falling under American politics or COVID-19 editing restrictions. Right now this massive category has precisely one subcategory, Category:Pseudoscience articles under contentious topics procedure. My intent is to create additional subcategories for a dozen or so major areas of contentious topics, and subcategorize the contents accordingly. This will allow category watchers of the subcategory to see very clearly when a page is added or removed from that specific subcategory. I bring it here because I don't know if anyone is watching the category talk page, and this will be a reasonably involved task of several thousand edits, probably carried out under AWB-assisted manual review. If there is any reason I'm missing as to why this is a bad idea, please let me know. Cheers! BD2412 T 21:08, 24 April 2023 (UTC)

(Note: I think it may be possible to effect this change by creating a subcategory structure reliant on existing parameters in the template that identifies contentious topics, but I have some trepidation about editing that heavily used template in an attempt to create such a change). BD2412 T 21:28, 24 April 2023 (UTC)
Yes, I think editing the core template would be a good idea, and that advertising this discussion there would be a good idea also. Izno (talk) 02:39, 29 April 2023 (UTC)
@Izno: I will give that a try. BD2412 T 19:29, 29 April 2023 (UTC)

Creating an infobox policy on biographies

Latest comment: 1 year ago33 comments10 people in discussion
This proposal was, after discussion at WP:VPI, replaced by the below proposal.

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.

Currently there's no policy for the inclusion or exclusion for infoboxes on biographies. A few years ago there was a great deal of contentiousness around this topic so arbitration was required. The current process for infobox disagreements is for there to be a RfC created. Over the last six months there have been 10 or more RfCs on this topic. Reviewing the last three RfCs (Wolfgang Amadeus Mozart, Jenny Lind, and Rod Steiger), there does appear to be growing community consensus to include infoboxes on biographies.

My question for the community is there a policy we can adopt that can prevent further RfCs on this topic? As it stands now, it's simply a matter of preference since there is no guideline. An infobox isn't required on every article, but on biographies with more than 20kb of readable prose it appears the community supports an infobox.

I'll start this discussion with two options:

1) Maintain the status quo
2) Create a policy on inclusion requirements for infoboxes

I look forward to hearing what the community thinks about this topic and perhaps we can agree on a path forward. Thanks! - Nemov (talk) 03:20, 30 April 2023 (UTC)

It might be time to start work-shopping a proposed guidance (I'd suggest WP:VPI). These RfCs have repetitive arguments and seem to end in the same outcome, so this seems to be a good candidate for MOS guidance. Galobtter (talk) 07:02, 30 April 2023 (UTC)
@Nemov: How about we start by discussing this at WP:VPI, like Galobtter said? We'll develop the proposal and then move it here for !voting. Nythar (💬-🍀) 13:10, 30 April 2023 (UTC)
Sure, I'm less knowledgable about how the Village Pump process works so thanks for help. Do you want to kick it off there? Nemov (talk) 13:20, 30 April 2023 (UTC)
@Nemov: The new proposal is right here: Wikipedia:Village pump (idea lab)#Establishing a biography infobox_policy. Nythar (💬-🍀) 13:39, 30 April 2023 (UTC)
  • In favour of making infoboxes a requirement for biographies of a certain size. Tim O'Doherty (talk) 15:15, 1 May 2023 (UTC)
    Size is a bad metric to use - and a rather arbitrary one. Whether there is sufficient information of use for an IB is not determined by the size of an article. - SchroCat (talk) 16:21, 1 May 2023 (UTC)
    Not size in bytes, but in readable prose. Not even really in word count, number of paragraphs, or sections. Shouldn't be a firm size, but there should be something that says "if an article is bigger than a stub, it should have an infobox". I think start class is where we should reasonably be expecting one. Tim O'Doherty (talk) 16:49, 1 May 2023 (UTC)
    Not even then. I’ve written two biographies recently that are long enough for FAC, where I intend to take them next, but they don’t hold enough information for an IB. Trying to force a box on the basis of an arbitrary metric is a poor way to address an issue that doesn’t exist. - SchroCat (talk) 18:04, 1 May 2023 (UTC)
    I don't know which biographies you're referring to, but skimming your contributions, I've picked out two biographies that are of decent length with no infobox and made mock-ups for each. Here they are. If I can knock up a pair of short infoboxes in a few minutes, I'm confident you can spend some time creating ones for FA candidates. Tim O'Doherty (talk) 18:57, 1 May 2023 (UTC)
    One of them is the correct article, but a crap IB. No known date of birth, no confirmed nationality and ”known for” (the crappest parameter available for use). I’ll pass on something that doesn’t help man not beast. That’s an example of forcing in an IB that doesn’t help the reader, but ticks an editor’s need to fill the gap with a box, regardless of use. - SchroCat (talk) 19:06, 1 May 2023 (UTC)
    Just to illustrate that even a short article can produce an infobox. Not all articles are on 19th century thieves that have negligible information on their personal lives. Even any of Lugnuts' 20-word stubs succeed in that, e.g. Sophie Papps. Tim O'Doherty (talk) 19:13, 1 May 2023 (UTC)
    Oh, any article can have an IB, but even if they are just shoved in there to fit some arbitrary metric, doesn’t mean it should be, or whether it’s of any use. There are shorter articles that would benefit from an IB, but deciding whether one should be included solely on the basis of size is mindless. - SchroCat (talk) 19:41, 1 May 2023 (UTC)
    Agree to disagree then. Even a short infobox is better than no infobox. I don't see any downside to putting vital information into an easy, quick, and accessible place. Tim O'Doherty (talk) 19:44, 1 May 2023 (UTC)
    I think you need to actually think what “vital information” means. Either way, in the Dando article, the ‘easy, quick and accessible place’ where there is ‘vital information’ is the lead. It’s present in all articles and doesn’t present dubious factoids without context or nuance. So no, no infobox is far better than a crap or misleading infobox. - SchroCat (talk) 19:52, 1 May 2023 (UTC)
    Not all the important info is in the lead. I had to read down a bit to find the "British or American" bit. In any case, the point wasn't about creating an infobox for Edward Dando; it was about proving that you can make infoboxes out of relatively little. You're welcome to have a crack at Dando's IB if you want, you're obviously far more knowledgable about him than I. But remember, we're not creating IBs for isolated cases. Tim O'Doherty (talk) 20:19, 1 May 2023 (UTC)
    Not all information is important. Does it matter if he is British or American? The fact that he was active in London is more of a point, not his nationality. Would his story change if he was German or French or Outer Mongolian?
    The fact it is possible to make an IB out of little doesn’t mean we should make an IB out of very little. It should only happen if there is a benefit to the reader, and the example you provided was of no benefit, raising more questions than it answered. There are shorter articles that are better fitted to an IB than Dando, but putting a metric like article size certainly isn’t a useful one. SchroCat (talk) 20:30, 1 May 2023 (UTC)
    My final word is this: I disagree. Your assertion that "it raises questions" might be true, but people read the prose for that, as a visit to an article isn't spent exclusively on the infobox. An infobox is meant to accompany the text, not to overshadow it. Putting "British or American" is correct as far as the information in the article goes. People generally don't read infoboxes looking for nuance, so apart from in the extremely odd case that we don't know which side of the Atlantic someone came from (and even in that case) it seems fine to me. Tim O'Doherty (talk) 21:08, 1 May 2023 (UTC)
    You are, of course, perfectly entitled to disagree, but you’ve still not demonstrated a need to show two unknown nationalities when his nationality isn’t important. We could add his height, (because we know it is correct), but what benefit would it be? As little as his unconfirmed nationality, I think. The other article I’ll take to FAC shortly has no date of birth, no date of death and no nationality, but I’m sure someone would think that a box of zero information in the top right of the article is a genius idea. Still, I’m sure someone else active here will accuse me of all manner of bad faith, being anti something and needing to ‘drop the stick’ just for having a more flexible approach for something that has no concrete research to confirm any beneficial use, just what some editors think may be “A Good Thing”. - SchroCat (talk) 21:27, 1 May 2023 (UTC)
    If you wish to contribute, we're attempting to come up with a policy to present as a proposal. Thanks! - Nemov (talk) 19:07, 1 May 2023 (UTC)
    @SchroCat thanks for moving my comment. You can dial back the snark. That's where the reply UI placed my comment when I hit "reply." You can channel that snark towards the programmers. Thanks Nemov (talk) 20:03, 1 May 2023 (UTC)
    It’s up to you to make sure you place your comment appropriately. That’s not snark, it’s trying to ensure you do things properly. My flexibility with you disappeared with your ongoing untruths and dismissal of people whose opinions differ with yours simply because they have the temerity to hold an opposing opinion to you. If you can avoid lies, smear and dismissals, I’ll consider rewording what you consider snark. - SchroCat (talk) 20:24, 1 May 2023 (UTC)
    Facinating as always, but I'm not going to be goaded into a fruitless back and forth with you. Thanks! Nemov (talk) 20:41, 1 May 2023 (UTC)
    There’s nothing fascinating about a discussion with you. I’m not goading or after a back and forth, but I don’t like people spreading untruths and smears, so knock off the uncivil comments and insinuations in future or ANI will be where you end up.
    Oh, and in future, don’t ever copy my comments from one thread to another before you close your own RfC. - SchroCat (talk) 20:55, 1 May 2023 (UTC)
  • Maintain status quo. Ignoring WP:OWNERSHIP, an article's primary author usually has a better understanding of what the article needs than drive-by editors. If the reader wouldn't benefit from an infobox, I see no need to have one. The infobox on Wolfgang Amadeus Mozart is "nice" only because as editors we're used to seeing infoboxes everywhere. Realistically, it adds nothing (except a convenient place to put his signature). The quality of articles like Joseph Grimaldi is not detracted because there is no box. Compare this with Barack Obama or John F. Kennedy. While these infoboxes still primarily mimic the leads, they hold exact dates and details that a reader would benefit from seeing immediately upon opening the article. Some biographies, especially historical obscurities, lack such pertinent facts. Anarchyte (talk) 13:34, 2 May 2023 (UTC)
    I understand that argument, but this isn't really about opposing or supporting infoboxes. It's a question of editor's resources being consumed on RfCs. If "drive-by editors" commenting on RfC is a problem, perhaps a policy could be placed giving the primary author more weight? While I do favor infoboxes generally, I'm fine with any solution that prevents more RfCs. Nemov (talk) 13:47, 2 May 2023 (UTC)
    I'm also by no means anti-infobox. Certain types of articles (software, video games, companies, events, etc) should almost always have one after they reach a certain level of complexity. Biographies are different however, and while I can appreciate the desire to stop RfCs, I think they're the best option we've got. Argue each article on the merits rather than add an additional level of bureaucracy. I know we sometimes introduce moratoriums on move requests, so perhaps that could be a way to prevent people from starting the same infobox discussion every six months. Anarchyte (talk) 14:38, 2 May 2023 (UTC)
    What's the problem with RfCs? "editors' resources being consumed"? You don't have to comment on them - you can just ignore them - no-one is under any compunction to take part in any RfC. The main IB-related RFCs on biographies are confined to the liberal arts, because that is where they provide no benefit. People who have posts, ranks or positions to record (politicians, military, clergy, etc) or those with a statistical career summary (sportspeople) are not in question - I don't think I have ever seen anyone remove a box on those, or voice an opinion that they shouldn't have a box (someone may think that, but I've never seen it), but liberal arts are unsuited to a list of factoids, which is why some people think them pointless there, while supporting them elsewhere. Having a metric-driven approach based on arbitrary criteria is entirely the wrong way to deal with something that isn't a problem, except for the activists that go round opening and challenging articles that they don't like the look of. - SchroCat (talk) 15:18, 2 May 2023 (UTC)
  • Require infoboxes Infoboxes are simply the way of the future. They provide essential details that most people want, they translate from English Wikipedia into 100 other languages, they sync all the Wikipedias with Wikidata for fact-checking and quality control at scale, they put Wikipedia information as structured data into virtual assistants and AI chatbots which are the way of the future, and it is easier to have "required infoboxes" as a default rule than to focus on exceptions. Even though I argue for a rule requiring infoboxes, I can tolerate exceptions, but those exceptions should still acknowledge that there is a default rule that applies and that exceptions are not the norm. Right now for a few exceptions, like 10 out of 1,000,000 articles, there has been mass wasted labor and attention in the discussion. Setting a rule is practical attention to scale and what works in 99.99% of cases, and exceptions beyond that are okay just so long as everyone knows the rule that infoboxes are required. Bluerasberry (talk) 16:30, 2 May 2023 (UTC)
    Even though I see what you're saying, and I probably agree that seems to be where things are heading, I do think it's funny to see infoboxes—which have existed since, uh ... 2004/2005?—be described as "the way of the future". Brave new world! --Jerome Frank Disciple (talk) 18:08, 2 May 2023 (UTC)
  • Make infoboxes a strong recommendation for biographies above any size that can physically fit them. Overwhelmingly common on biographies— this is a brute fact, citing enclaves that are deliberately policed to block infoboxes doesn’t change that. Standardization would prevent these debates from coming up again and again, wasting massive amounts of time and energy. Dronebogus (talk) 18:11, 2 May 2023 (UTC)

You know this isn't where people are !voting, right? And again, size as the determining factor? That's not the best decider of whether there should be a box or not. - SchroCat (talk) 18:15, 2 May 2023 (UTC)

  • I don’t see a need for formal guidelines on this. Basically, this falls under WP:Consensus. The current consensus is that we should include an infobox on most articles. However, if there is a local consensus to omit an infobox at a specific article, it is permissible to omit it. Does this mean that sometimes we must have an extensive discussion (and even the occasional argument) to determine what the local consensus actually is? Yes. That’s OK. Sometimes reaching consensus is messy. Blueboar (talk) 18:31, 2 May 2023 (UTC)
The discussion above 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.

Upgrade WP:SNOW Clause

Latest comment: 1 year ago20 comments13 people in discussion
Procedural close – this proposal was very recently rejected by the community, and there's no indication that anything has changed since then. Extraordinary Writ (talk) 05:24, 3 May 2023 (UTC)

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.


Should the snowball essay be upgraded to some status such as a guideline? It currently says that it is an Explanatory Essay, and that it has not been thoroughly vetted by the Wikipedia community. I think that it has been thoroughly vetted by the Wikipedia community, because deletion discussions are often snow-closed. The guidelines for speedy keep, which are guidelines, distinguish between speedy keep and an early close (for a keep) under the snowball clause.

I am posting this mainly as a result of a Deletion Review in progress. After six days and 16 hours on an AFD, there had been five Keep !votes and no Deletes except the nominator. See Wikipedia:Articles for deletion/Christopher W. Shaw. A non-admin then closed the AFD as a Snow Keep. The nominator-appellant is questioning the close, saying that, although 10 minutes early is an example of a technicality, eight hours is not a technicality, and the Snow clause is only an essay. It looks to me like a valid early close under the Snow clause, but the appellant is saying that the snow clause isn't an effective clause or something like that. I think that, at a minimum, Oncorhynchus mykiss is in order. So should the Snowball essay be upgraded to a guideline? Robert McClenon (talk) 02:19, 30 April 2023 (UTC)

Why SNOW is toxic
OK, so why? Well, for one, it's sometimes used to quash discussions that should not be quashed. My last involvement with SNOW was an admin -- respected admin, former arb -- shutting down a lively, well attended, cogent discussion about some important policy thing (it was Main Page talk IIRC). Basically 50/50, so nothing was going to come of it, but hella people were making their (mostly cogent, interesting, worth reading to grow and learn) points, the admin shut it down after a day -- this was not even an RfC, but just a discussion -- on the (true) basis "It's been talked to death forever, nothings going to change, you're wasting your time." Still believes it's his right to do that, too.
Well guess what? People get to decide how to spend their time. OK? Another person doesn't get to tell me "I'm the judge of how you're going to spend your time on this Earth, at least the part I can control, now go something I'd rather you do". This is not why we have an admin corps. This is not how you nurture a volunteer organization like this.
Yeah one instance, but you see it a lot more than that. And what is the benefit? What is the benefit. How does it benefit the project. It doesn't. Why does an AfD have to be shut down after two days because it's running 5-0. It takes no more time to resolve it at its normal expiry. And, you know, maybe I want to come in with an opposing view. Maybe it won't change anything. Maybe my argument will be so much stronger it wins the day (in theory; AfD is not supposed to be a vote -- remember?) Even if not, maybe the things I point out will change the trend. It's pretty rare, but I've seen AfD that are 5-0 after two days turn into 6-5 after seven. Or maybe I just want to have my say, add my voice.
Anyway, if it's 5-0 after two days maybe it'll end 5-0 after seven. Often will. People will mostly stop joining the discussion, If it's a slam dunk, it'll be decided. There's no hurry. Something editors remind each other re content. "We want to get it right, not fast; there's no hurry".
What bringing in WP:SNOW in does is make life easier for the administrator. "I'm here now, I might as well close this now so I don't have to worry about it later". But admins have plenty of time to close AfD. I've been assured of this. I mean I'd think you can go thru the expired list actually faster than picking up random 2-day-old ones. You might save five seconds or something. Maybe.
One reason that frosts me is that you can never ever invoke WP:IAR here. In fact people will jeer at you if do. Except for WP:SNOW. SNOW says up top "This is an explanatory essay about... Wikipedia:Ignore all rules policy." And it is contrary to the rules. So you have 1) the one essay that successfully invokes IAR, , and 2) it makes life a little easier for admins (and also... well... adds another tool to the admin toolbox, unspoken). That is... a really bad look. Even if you don't think it's bad, it looks bad. Feels bad. That matters.
It's an invitation to corruption, too. I've seen it -- rare, but not zero times -- "Well, it's 5-0 to delete, and I personally think it should be deleted, so I'll SNOW it before the other side gets a chance to swing it the other way". You do not want your organizations structure and polices to leave any foothold for corruption. Why would you want to do that.
And I mean, SNOW's nutshell is like "...don't follow a process all the way to its scheduled end, just for the sake of doing so...". Well but of course you should. Why would you not? Jeepers H. Creepers. In meatspace we're not like "Well, everybody knows Smith is going to win by a landslide, and hardly any more voters are coming, let's close the polling place early". "The guy's slam-dunk guilty, let's skip the trial." Because even if that's true it doesn't look good. It doesn't feel good. It makes people feel unimportant when you do that. This is a volunteer organization. The essay WP:Process is important has lots more paragraphs in this vein. Lots more. It's long and well argued. Read it if you like, and maybe you won't agree, but it's a reasonable argument; it's not madness or idiocy. Because it isn't, it should basically nullify most all invocations of SNOW, which is, after all, against the rules, per the invocation of IAR at the top. Or there should be offer of a discussion in each case over whether SNOW should be invoked. Which just defeats the purpose.
And jeez, I see that SNOW flat out says that if you speedy delete an article, but realize (or are informed) that it doesn't meet any of speedy-deletion criteria, enh, whatever, who cares. Good grief, this is poor advice indeed. Toxic. We have WP:PROD.
And if there's a great honken wordy head-banging 5-page RfC or AfD that's not likely to change anything, people can skip it. It just takes a glance. Or skip the hard parts. Nobody's required to read R fC or AfD at all. But if they want to waste their time palavering over it, well, I waste hella time puttering around with my other hobbies too. So? Pointless blowing off steam and at least imagining that I might be heard (like here!) might help me feel better about my real work, writing content. Maybe I'm a scaramouch, but it's not the encyclopedia anyone can edit except scaramouchi. Lot of different people here.
Sure, it's not like using SNOW isn't, on the technical merits, OK most of the time (altho no great gain). It's that on net, it is time-wasting (when a SNOW is objected to and has to be talked about, deletion reviews, these type discussions, whatever), sometimes depressing or maddening or disempowering to some, and actually lowkey insulting. It's a net negative. Admins shouldn't use it. And editors should look side-eye at anyone who does.
And per OP, wait, people have to go to deletion review to overturn a SNOW? Great Hera. Objection to a SNOW should trigger automatic revoke. SNOW itself says so ("If an issue is 'snowballed', and somebody later raises a reasonable objection, then it probably was not a good candidate for the snowball clause"). If the objection was not reasonable -- ie, madness -- it's disruptive behavior and that's for ANI (SNOW says this). And by the way, the whole second half of SNOW (the part nobody reads) basically kind of says not to use SNOW if any human person could possibly object, who is not brain-damaged or a troll, which is almost all cases anyway.
FWIW MetaWiki's "Snowball" page is the opposite of ours, is says "Don't close discussions early; we don't do Snowball closures on Meta-Wiki" and "Remember, a discussion is not a vote. Even a long list of 'supports' does not preclude the appearance of a single and important objection. An important comment giving deeper insights can often change the whole course of a discussion". Maybe MetaWiki has different needs, or maybe they're poltroons, I don't know. But just saying. Herostratus (talk) 05:00, 1 May 2023 (UTC)
  • Support upgrading to guideline - Some of my RfCs or RMs have been SNOW closed. I feel no acrimony towards the closers nor towards WP:SNOW. Its purpose is for editors to exercise common sense and avoid pointy, bureaucratic behavior, which is what we need more of on Wikipedia. Tim O'Doherty (talk) 08:59, 1 May 2023 (UTC)
  • Please would the closer take account of the very recent discussion we've had on the same topic, so we don't have to copy/paste our contributions from one to the other.—S Marshall T/C 10:38, 1 May 2023 (UTC)
    Closer? There's no closer here. It's not even a formal RfC. Do not not not try to force a change like this down the community's throat without a well-advertised, well-attended, long-lasting WP:CENT RfC. Because that is how you get shitshows. I mean, you'd want a major, major change like this to be thoroughly discussed and vetted by the larger community including editors who maybe don't lurk on these type boards. Right? Right? After all, if this is such a good idea, you'll have no trouble get most everyone to support it. correct? Getting wide consensus -- say 75% of a group of 100-200 editors in support -- would settle the matter clearly and satisfactorily once and for all, right? You're not afraid that it wouldn't work out they way you like, are you? Because that would be a really really poor reason for not doing it right. Herostratus (talk) 12:40, 1 May 2023 (UTC)
    Sure, buddy, and "no change" is what I'm trying to achieve here. We've just had this conversation and isaacl has linked it. I personally said: Oppose. SNOW isn't a rule. It's a decision to disregard the rules when a closer feels it's in the best interests of the encyclopaedia to do so. There is no need to change this. The community largely agreed with me and the closer said: There is clear consensus not to promote to a policy or guideline. So, no, I am not not not trying to force a change like this down anyone's throat. I'm trying to ensure that it doesn't get forced down anyone's throat!—S Marshall T/C 14:38, 1 May 2023 (UTC)
    Oh. Well that's very different. Never mind. Herostratus (talk) 21:55, 1 May 2023 (UTC)
  • Seems unnecessary. If there are objections to the use of WP:SNOW because it is not a guideline, you can just use the policy WP:NOTBURO. —Kusma (talk) 13:24, 1 May 2023 (UTC)
    Well, but WP:NOTBURO doesn't really say much the same as SNOW. The real thrust of the rule is IMO given in "Do not follow an overly strict interpretation of the letter of policies without considering their principles. If the rules truly prevent you from improving the encyclopedia, ignore them."
    But using SNOW to quash a discussion does ignore an important principle, which is to allow full community discussion of important things. Breaking that rule doesn't improve the Wikipedia. It's just a convenience. Having an article kept after seven days instead of two changes nothing, improves nothing. NOTBURO is not really in play when you're talking about cutting short discussions. You could possibly add a clause to that effect I suppose. Herostratus (talk) 22:49, 1 May 2023 (UTC)
    Having an article kept after seven days instead of two changes nothing, improves nothing. Have you seen the big fat ugly {{Article for deletion}} template? Getting rid of that early certainly does improve things. And so does telling people off for wasting others' time by starting bad AfDs. Yes, community discussion is important, but there needs to be something worth discussing. A vexatious litigant has no right to wikilawyer their way into keeping an AfD open for any amount of time; if they do not bring a discussion-worthy argument, shutting down the discussion early improves Wikipedia. Overall, ignoring process is an important defence against Wikipedia turning into a bureaucracy, and our noticeboards turning into courts of law. —Kusma (talk) 08:13, 2 May 2023 (UTC)
  • I don't see anything in the status quo that needs changing. The community in most cases uses WP:SNOW appropriately, and the exceptions can be addressed case by case.--Wehwalt (talk) 13:44, 1 May 2023 (UTC)
  • No per WP:CREEP. I have no disagreement with editors trying to move problem issues forward, but based on the unsuccessful and quite recent RFC, there's zero chance this gets upgraded at this time. I'm not seeing anything compelling (other than perfectly reasonable argument like that from Herostratus) which would cause me to change my mind. BusterD (talk) 08:45, 2 May 2023 (UTC)
  • No It's fine as an explanatory essay, it supplements other PAGs like WP:NOTBURO and WP:IAR and others, but it doesn't need to be upgraded. As an essay, it is fine to cite it as an explanation as to why one is ending a discussion outside of norms, but it doesn't need any kind of official sanction. --Jayron32 12:44, 2 May 2023 (UTC)
  • No per CREEP. SNOW is just an expression of common sense that doesn't need to be a formal guideline. 331dot (talk) 12:59, 2 May 2023 (UTC)
  • — Qwerfjkltalk 19:49, 2 May 2023 (UTC)
The discussion above 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.

Proposal to establish single go-to close review location

Latest comment: 1 year ago21 comments13 people in discussion

Over at the Idea Lab, BilledMammal (talk) brought up the possibility of establishing a single go-to location for close reviews (maybe something like WP:Village pump (close reviews)?) rather than having separate pages for deletion reviews and move reviews where the same editors always comment. This idea was backed up by myself and Jayron32 (talk), so I've decided to make a proposal here so we can discuss this further. 100.7.44.80 (talk) 16:39, 26 April 2023 (UTC)

I would support this. Tim O'Doherty (talk) 17:19, 26 April 2023 (UTC)
  • Support. I would say it's about time. We are not so clogged up with deletion reviews and move reviews that they require separate boards to keep track of them, and combining them would increase the population of "regulars" looking over closes of both kinds. Adding merge review to the function of such a combined board would be an easy step. BD2412 T 17:52, 26 April 2023 (UTC)
I am not a fan of this. We'll end up with a smaller audience to review RFC closures when we should have as many eyes on such discussions as possible. There's not so many of them at AN that they're clogging up the board, so I don't see a reason to move them to another location. ScottishFinnishRadish (talk) 17:56, 26 April 2023 (UTC)
My impression from looking at close reviews from the past few years at AN are that most don't get much participation, even though there are more active editors watching that page than any village pump; it is possible that changing the forum would encourage participation. However, if RfC's are a sticking point then they could be excluded from the proposal; we would lose the halo effect their inclusion would bring but I still think the general idea is a good one that would encourage broader participation in reviews. BilledMammal (talk) 19:00, 26 April 2023 (UTC)
I concur. 100.7.44.80 (talk) 20:50, 26 April 2023 (UTC)
  • Oppose - I'm not positive on the basis that BD2412 is saying that the population of regulars who looking over all the closes would increase if we created a new board - on several grounds. DRV has 1300 page watchers, while it's hard to make any decent prediction on what a new board might have at the onset. I am both interested and qualified to engage in deletion reviews. A merge or move review - rather less so. Putting everything together might get people to look at reviews outside their wheelhouse - or it might mean even fewer look at their current ones. I've no objection to the creation of merge review (or adding it as a move review aspect), but this scale of change doesn't have an issue to warrant it. Nosebagbear (talk) 09:43, 27 April 2023 (UTC)
    Regarding the number of watchers at DRV, I don't find it relevant because we create a new page for each day; these 1300 (150 active) editors might be interested in participating in the discussions, but unless they actively seek them out, rather than relying on their watchlist, they won't find them. BilledMammal (talk) 20:51, 27 April 2023 (UTC)
  • Oppose - I'm landing here because otherwise my comment is too complicated. Deletion and move reviews are both part of more complex processes with fairly rigid rules (both the overall processes and the review process specifically), and both processes often require an administrator to push buttons both during and after the review. I don't see how it would be constructive to lump these in broadly with reviews of more general discussion closes, and in fact I think it would end up driving reviewers away. However, I would support a common review venue for challenges of regular discussion closes, like RFCs. I do think it's a good idea to move these away from AN[I] - directing that they be done on the administrators' noticeboard both implies that they do require an admin and also reduces participation from editors who don't want to put their names on the drama boards. Perhaps something like the feedback request service could be created for general close reviews as well, to attract more participation. Ivanvector (Talk/Edits) 21:19, 27 April 2023 (UTC)
    If we hold an RfC on this I wonder if it will be worth while asking individually which types discussions should be included at the board? It seems that there is general support for including some discussions there, but it is not clear which ones the broader community will support. BilledMammal (talk) 21:23, 27 April 2023 (UTC)
    If that's the case, then hold an RfC on this we definitely should. 100.7.44.80 (talk) 23:49, 27 April 2023 (UTC)
  • Moral support but oppose as proposed - A specific forum away from WP:AN (which is explicitly an admin's forum a privileges admin views) might be a good idea for RFC reviews but simply grouping everything into a single forum will remove the specialist approach the DELREV and move-reviews require. FOARP (talk) 10:40, 28 April 2023 (UTC)
  • Idea lab it first to standardize what the proposal actually wants to achieve. A vague RfC of "we want to change this, but can't agree on what it should look like" will turn into a trainwreck quick. Curbon7 (talk) 03:07, 29 April 2023 (UTC)
  • Oppose because then we will need a new review board, to review the closes of the reviews of the closes. --Rschen7754 03:56, 29 April 2023 (UTC)
  • Comment, several people have mentioned wanting more eyes at deletion review. I was (mistakenly) under the impression that Minions discussed deletion at AfD, and DRV was where Admins look at whether administratively someone messed up in closing an AfD. I didn't know that more eyes were even allowed, let alone welcomed, at DRV. It is possible others have made the same mistake. Elemimele (talk) 11:28, 2 May 2023 (UTC)
    • @Elemimele: So, your impression of how admins work at Wikipedia is pretty wrongheaded. There are no spaces and no activities walled off from non-admins except for the use of the specific toolset (blocking, deleting, protecting, granting advanced permissions, etc.) that admins have. EVERY editor in good standing is allowed, and openly invited, to participate in any discussion in any part of Wikipedia. Admin privileges only extend as far as the actual use of the extra tools they have, but everything you can technically do at Wikipedia, including participating in discussions at all of the Admin noticeboards, you are encouraged and invited to participate in. --Jayron32 12:50, 2 May 2023 (UTC)
      @Jayron32: yup, you're quite right, I had the wrong idea, and I keep finding I've misunderstood things. I shared my misunderstanding here in case I'm not alone. I do appreciate the helpful nature of the WP community in explaining such things. Thank you! Elemimele (talk) 09:05, 3 May 2023 (UTC)
  • Oppose for now as premature. This feels undeveloped, and needs to probably spend some time and energy at WP:VPIL being more fully fleshed out as to the details. --Jayron32 12:47, 2 May 2023 (UTC)

Article link on Talk: archive pages to point to actual Article

Latest comment: 1 year ago12 comments7 people in discussion

At the top of every archive page from a Talk: page (eg Talk:BBC/Archive 8) there are two links: the Talk link (which always points to the current page, and is therefore redundant), and the article link (in this case Article, which actually points to BBC/Archive_8) which is and always will be a redlink (at least, I assume there is no point in creating that page).

I suggest that it would be better, if it is indeed possible, to make the Article link on Talk:/Archive pages point to the original Article (in this case, to BBC), as that will be more helpful and relevant to anyone viewing the archive page. -- Verbarson  talkedits 09:22, 25 April 2023 (UTC)

@Verbarson I get your point, but MediaWiki doesn't intelligently know what kind of content a subpage is. For example you could have Example/Sub_page which would have a corresponding Talk:Example/Sub_page. A more complex real life example would be A/B and Talk:A/B. The talk page will think its parent page is Talk:A which is nonsense. I think a less drastic change would be to use {{Archives}} or something else that appropriately links to the actual article page ~ 🦝 Shushugah (he/him • talk) 21:25, 25 April 2023 (UTC)
Verbarson, I went to see what you were talking about, but couldn't immediately see the links at the top of every archive page. It turns out, it's because I am using the MonoBook skin. Look at the page in MonoBook or Vector 2010 or even Minerva Neue and I believe you will see what you want. Only Vector 2022 and Timeless screw up the links this way. In all cases, the links at the earlier archives (e.g. Archive_7) are as you expect; they have {{talkarchivenav}} on them, which the Archive_8 page does not. I don't know if the solution is a fix to the two skins or just to add the archive template to such "disagreeable" pages. — JohnFromPinckney (talk / edits) 05:22, 26 April 2023 (UTC)
I think Verbarson is talking about the article tab at the top of the page; it has nothing to do with the archivenav template. That's red in every skin, and always has been as far as I can remember. – Joe (talk) 06:38, 26 April 2023 (UTC)
You're right, Joe. I guess Vector 2022 is just so "in-your-face" to me that I saw the red there but not in "my" MonoBook. — JohnFromPinckney (talk / edits) 06:56, 26 April 2023 (UTC)
The easiest way to do this would be to create BBC/Archive_8 as a redirect to BBC, though I imagine there would be objections to creating so many redirects for such a minor UI improvement. – Joe (talk) 06:40, 26 April 2023 (UTC)
Such redirects have repeatedly been deleted at RfD, and any change may require consensus. —CX Zoom[he/him] (let's talk • {C•X}) 08:11, 26 April 2023 (UTC)

Thank you to all contributors. I have explored the other skins, and other archive pages, to better understand the situation. It seems, as I expected might be the case, that the Article tab at the top of all pages is generated by an automatic process that does not currently make exceptions for archives; that is, it assumes that if there exists a page Talk:BBC/Archive 8 then there must be a corresponding page BBC/Archive 8. Unfortunately, Talk:Archive pages do not conform to this assumption.

I have become aware, through this thread, of differences between Talk:Archive pages that include {{talkarchive}} (adds a text box explaining the nature of the page), those that include {{talkarchivenav}} (adds the text box and a set of links to other archive pages), and those that have neither. I assume that these differences have arisen due to different archiving processes?

I think that {{talkarchivenav}} is a helpful and desirable facility. Therefore I would like to amend my proposal to:

  • All Talk:Archive pages should be standardised to include {{talkarchivenav}} (which might be automated using a bot?)
  • The text box generated by {{talkarchivenav}} should be amended to include a link to the current Article (it already links to the current Talk page), thus achieving the goal of my original suggestion, which was to allow linking from any Talk:Archive page to (the current state of) the relevant article.

-- Verbarson  talkedits 10:06, 26 April 2023 (UTC)

I generally agree with you...but a number of edge cases come up...e.g non conventionally named Archive pages (dates) instead of numeric sequence...make it difficult for the template or a bot to know how to tag a page. I'd encourage you to be a bold WP:GNOME in the meantime and add whatever useful Archives templates you want. They're useful for searching on the main talk page too. ~ 🦝 Shushugah (he/him • talk) 11:20, 26 April 2023 (UTC)
@Shushugah True, but it's probably OK if the edge cases don't work ... as long as most cases do work. David10244 (talk) 10:11, 3 May 2023 (UTC)
I know exactly what this is about, and have had the same idea quite a few times. Essentially, what it is is this: the "article" or "Page" tab at the top of the page next to the "talk" tab just replaces "Talk:________" with "______", or "Wikipedia talk:" with "Wikipedia:". But, as has been said before, there are a lot of archive styles, and it would be very hard to come up with something that covered all of them without bringing up false positives. One thing that does occur to me as plausible is using whatever we have for the parentheses thing: if you go to an article like "John Smith (author", and it's a redlink, the text will automatically say something like "Did you mean John Smith (author)?" and link you there. It seems to me like we could come up with some regex to see if the page had Archive.{0,1}[0-9]{0,5} in its title, and if so, give a link to the title with said pattern stripped. jp×g 01:39, 6 May 2023 (UTC)
Would it be possible to create a 'Root page' link by (a) removing the 'Talk:' or ' talk' part (as described above, or however it is currently done behind the scenes) and (b) removing all sub-page names following any '/'? This would turn Talk:BBC/Archive 8 into BBC. It could be a gadget or a bit of JS, not necessarily a standard feature, so those installing it would recognise that it may not work on some pages, nor be necessary on others. -- Verbarson  talkedits 19:14, 6 May 2023 (UTC)

Please add downloading

Latest comment: 1 year ago7 comments6 people in discussion

In the mobile app, please add downloading, so that you can view articles offline. 78.163.113.64 (talk) 21:38, 5 May 2023 (UTC)

I don’t really know if this is the right forum. At the very least you should put this by idea lab (see tabs up top); as it stands your proposal is half-baked (at best) Dronebogus (talk) 00:34, 6 May 2023 (UTC)
I think you should see WP:BITE; "half-baked (at best)" does not seem to me like an appropriate or proportionate way to respond to someone making an earnest suggestion in good faith. For what it's worth, if this isn't already implemented, I suspect it would take about fifteen seconds (literally just addding a sidebar item that's a formatted URL to the API endpoint for parsed page text). jp×g 01:13, 6 May 2023 (UTC)
Well, it is. I’m being honest. Biting would be “this sucks” or “you should know better.” Dronebogus (talk) 17:15, 6 May 2023 (UTC)
I appreciate you feel that way, but others may not (and given that the feature is already supported, based on the descriptions in the iOS and Android app stores, the suggestion seems reasonable enough). For future cases, more specific feedback on what aspects you feel are lacking would be a more engaging response, while still being honest. isaacl (talk) 17:45, 6 May 2023 (UTC)
Newbies who arrive at the Village Pump to ask a question or make a suggestion need to be provided with more substantive guidance as far as what to do and where to go next, particularly since that was their first contribution to Wikipedia. No, the Village Pump isn't the same thing as the Teahouse, but the reason they made it here to begin with was because they were directed to it by Wikipedia signage. In your haste to be the first person to respond with "wrong forum", you might have unwittingly given them a poor first impression of how editors on Wikipedia respond to newbies. ⛵ WaltClipper -(talk) 12:46, 8 May 2023 (UTC)
I think this may already be in there? Add the article to your reading list. — xaosflux Talk 00:40, 6 May 2023 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_200&oldid=1155424384"