Wikipedia:Village pump (proposals): Difference between revisions

Browse history interactively

← Previous edit

Content deleted Content added

VisualWikitext

Inline

Latest revision as of 08:11, 12 January 2025

Table of contents
First discussion
End of page
New post

Shortcuts

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.

« Archives, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Revise Wikipedia:INACTIVITY

There is consensus against this proposal. JJP_{Mas_ter} (she/they) 17:48, 4 January 2025 (UTC)[reply]

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.

Point 1 of Procedural removal for inactive administrators which currently reads "Has made neither edits nor administrative actions for at least a 12-month period" should be replaced with "Has made no administrative actions for at least a 12-month period". The current wording of 1. means that an Admin who takes no admin actions keeps the tools provided they make at least a few edits every year, which really isn't the point. The whole purpose of adminship is to protect and advance the project. If an admin isn't using the tools then they don't need to have them. Mztourist (talk) 07:47, 4 December 2024 (UTC)[reply]

Endorsement/Opposition (Admin inactivity removal)

Support as proposer. Mztourist (talk) 07:47, 4 December 2024 (UTC)[reply]
Oppose - this would create an unnecessary barrier to admins who, for real life reasons, have limited engagement for a bit. Asking the tools back at BN can feel like a faff. Plus, logged admin activity is a poor guide to actual admin activity. In some areas, maybe half of actions aren't logged? —Femke 🐦 (talk) 19:17, 4 December 2024 (UTC)[reply]
Oppose. First, not all admin actions are logged as such. One example which immediately comes to mind is declining an unblock request. In the logs, that's just a normal edit, but it's one only admins are permitted to make. That aside, if someone has remained at least somewhat engaged with the project, they're showing they're still interested in returning to more activity one day, even if real-life commitments prevent them from it right now. We all have things come up that take away our available time for Wikipedia from time to time, and that's just part of life. Say, for example, someone is currently engaged in a PhD program, which is a tremendously time-consuming activity, but they still make an edit here or there when they can snatch a spare moment. Do we really want to discourage that person from coming back around once they've completed it? Seraphimblade ^{Talk to me} 21:21, 4 December 2024 (UTC)[reply]
We could declare specific types of edits which count as admin actions despite being mere edits. It should be fairly simple to write a bot which checks if an admin has added or removed specific texts in any edit, or made any of specific modifications to pages. Checking for protected edits can be a little harder (we need to check for protection at the time of edit, not for the time of the check), but even this can be managed. Edits to pages which match specific regular expression patterns should be trivial to detect. Animal lover |666| 11:33, 9 December 2024 (UTC)[reply]
Oppose There's no indication that this is a problem needs fixing. ⇒SWATJester ^{Shoot Blues, Tell VileRat!} 00:55, 5 December 2024 (UTC)[reply]
Support Admins who don't use the tools should not have the tools. * Pppery * _{it has begun...} 03:55, 5 December 2024 (UTC)[reply]
Oppose While I have never accepted "not all admin actions are logged" as a realistic reason for no logged actions in an entre year, I just don't see what problematic group of admins this is in response to. Previous tweaks to the rules were in response to admins that seemed to be gaming the system, that were basically inactive and when they did use the tools they did it badly, etc. We don't need a rule that ins't pointed a provable, ongoing problem. Just Step Sideways ^{from this world ..... today} 19:19, 8 December 2024 (UTC)[reply]
Oppose If an admin is still editing, it's not unreasonable to assume that they are still up to date with policies, community norms etc. I see no particular risk in allowing them to keep their tools. Scribolt (talk) 19:46, 8 December 2024 (UTC)[reply]
Oppose: It feels like some people are trying to accelerate admin attrition and I don't know why. This is a solution in search of a problem. Gnomingstuff (talk) 07:11, 10 December 2024 (UTC)[reply]
Oppose Sure there is a problem, but the real problem I think is that it is puzzling why they are still admins. Perhaps we could get them all to make a periodic 'declaration of intent' or some such every five years that explains why they want to remain an admin. Alanscottwalker (talk) 19:01, 11 December 2024 (UTC)[reply]
Oppose largely per scribolt. We want to take away mops from inactive accounts where there is a risk of them being compromised, or having got out of touch with community norms, this proposal rather targets the admins who are active members of the community. Also declining incorrect deletion tags and AIV reports doesn't require the use of the tools, doesn't get logged but is also an important thing for admins to do. Ϣere SpielChequers 07:43, 15 December 2024 (UTC)[reply]
Oppose. What is the motivation for this frenzy to make more hoops for admins to jump through and use not jumping through hoops as an excuse to de-admin them? What problem does it solve? It seems counterproductive and de-inspiring when the bigger issue is that we don't have enough new admins. —David Eppstein (talk) 07:51, 17 December 2024 (UTC)[reply]
Oppose Some admin actions aren't logged, and I also don't see why this is necessary. Worst case scenario, we have WP:RECALL. QuicoleJR (talk) 15:25, 17 December 2024 (UTC)[reply]
Oppose I quite agree with David Eppstein's sentiment. What's with the rush to add more hoops? Is there some problem with the admin corps that we're not adequately dealing with? Our issue is that we have too few admins, not that we have too many. CaptainEek ^{Edits Ho Cap'n!}⚓ 23:20, 22 December 2024 (UTC)[reply]
Oppose: I'm not seeing this as a real issue which needs to be fixed, or what problem is actually being solved. Let'srun (talk) 21:17, 28 December 2024 (UTC)[reply]
Oppose per all the good points from others showing that this is a solution in search of a problem. Toadspike [Talk] 21:57, 29 December 2024 (UTC)[reply]
Oppose The current wording sufficiently removes tools from users who have ceased to edit the English Wikipedia. Darkfrog24 (talk) 22:28, 3 January 2025 (UTC)[reply]

Discussion (Admin inactivity removal)

Making administrative actions can be helpful to show that the admin is still up-to-date with community norms. We could argue that if someone is active but doesn't use the tools, it isn't a big issue whether they have them or not. Still, the tools can be requested back following an inactivity desysop, if the formerly inactive admin changes their mind and wants to make admin actions again. For now, I don't see any immediate issues with this proposal. Chaotic Enby (talk · contribs) 08:13, 4 December 2024 (UTC)[reply]
Looking back at previous RFCs, in 2011 the reasoning was to reduce the attack surface for inactive account takeover, and in 2022 it was about admins who haven't been around enough to keep up with changing community norms. What's the justification for this besides "use it or lose it"? Further, we already have a mechanism (from the 2022 RFC) to account for admins who make a few edits every year. Anomie ⚔ 12:44, 4 December 2024 (UTC)[reply]
I also note that not all admin actions are logged. Logging editing through full protection requires abusing the Edit Filter extension. Reviewing of deleted content isn't logged at all. Who will decide whether an admin's XFD "keep" closures are really WP:NACs or not? Do adminbot actions count for the operator? There are probably more examples. Currently we ignore these edge cases since the edits will probably also be there, but now if we can desysop someone who made 100,000 edits in the year we may need to consider them. Anomie ⚔ 12:44, 4 December 2024 (UTC)[reply]
I had completely forgotten that many admin actions weren't logged (and thus didn't "count" for activity levels), that's actually a good point (and stops the "community norms" arguments as healthy levels of community interaction can definitely be good evidence of that). And, since admins desysopped for inactivity can request the tools back, an admin needing the bit but not making any logged actions can just ask for it back. At this point, I'm not sure if there's a reason to go through the automated process of desysopping/asking for resysop at all, rather than just politely ask the admin if they still need the tools.
I'm still very neutral on this by virtue of it being a pretty pointless and harmless process either way (as, again, there's nothing preventing an active admin desysopped for "inactivity" from requesting the tools back), but I might lean oppose just so we don't add a pointless process for the sake of it. Chaotic Enby (talk · contribs) 15:59, 4 December 2024 (UTC)[reply]
To me this comes down to whether the community considers it problematic for an admin to have tools they aren't using. Since it's been noted that not all admin actions are logged, and an admin who isn't using their tools also isn't causing any problems, I'm not sure I see a need to actively remove the tools from an inactive admin; in a worst-case scenario, isn't this encouraging an admin to (potentially mis-)use the tools solely in the interest of keeping their bit? There also seems to be somewhat of a bad-faith assumption to the argument that an admin who isn't using their tools may also be falling behind on community norms. I'd certainly like to hope that if I was an admin who had been inactive that I would review P&G relevant to any admin action I intended to undertake before I executed. DonIago (talk) 15:14, 4 December 2024 (UTC)[reply]
As I have understood it, the original rationale for desysopping after no activity for a year was the perception that an inactive account was at higher danger of being hijacked. It had nothing to do with how often the tools were being used, and presumably, if the admin was still editing, even if not using the tools, the account was less likely to be hijacked. - Donald Albury 22:26, 4 December 2024 (UTC)[reply]
And also, if the account of an active admin was hijacked, both the account owner and those they interact with regularly would be more likely to notice the hijacking. The sooner a hijacked account is identified as hijacked, the sooner it is blocked/locked which obviously minimises the damage that can be done. Thryduulf (talk) 00:42, 5 December 2024 (UTC)[reply]
I was not aware that not all admin actions are logged, obviously they should all be correctly logged as admin actions. If you're an Admin you should be doing Admin stuff, if not then you obviously don't need the tools. If an Admin is busy IRL then they can either give up the tools voluntarily or get desysopped for inactivity. The "Asking the tools back at BN can feel like a faff." isn't a valid argument, if an Admin has been desysopped for inactivity then getting the tools back should be "a faff". Regarding the comment that "There's no indication that this is a problem needs fixing." the problem is Admins who don't undertake admin activity, don't stay up to date with policies and norms, but don't voluntarily give up the tools. The 2022 change was about total edits over 5 years, not specifically admin actions and so didn't adequately address the issue. Mztourist (talk) 03:23, 5 December 2024 (UTC)[reply]
obviously they should all be correctly logged as admin actions - how would you log actions that are administrative actions due to context/requiring passive use of tools (viewing deleted content, etc.) rather than active use (deleting/undeleting, blocking, and so on)/declining requests where accepting them would require tool use? (e.g. closing various discussions that really shouldn't be NAC'd, reviewing deleted content, declining page restoration) Maybe there are good ways of doing that, but I haven't seen any proposed the various times this subject came up. Unless and until "soft" admin actions are actually logged somehow, "editor has admin tools and continues to engage with the project by editing" is the closest, if very imperfect, approximation to it we have, with criterion 2 sort-of functioning to catch cases of "but these specific folks edit so little over a prolonged time that it's unlikely they're up-to-date and actively engaging in soft admin actions". (I definitely do feel criterion 2 could be significantly stricter, fwiw) AddWittyNameHere 05:30, 5 December 2024 (UTC)[reply]
Not being an Admin I have no idea how their actions are or aren't logged, but is it a big ask that Admins perform at least a few logged Admin actions in a year? The "imperfect, approximation" that "editor has admin tools and continues to engage with the project by editing" is completely inadequate to capture Admin inactivity. Mztourist (talk) 07:06, 6 December 2024 (UTC)[reply]
Why is it "completely inadequate"? Thryduulf (talk) 10:32, 6 December 2024 (UTC)[reply]
I've been a "hawk" regarding admin activity standards for a very long time, but this proposal comes off as half-baked. The rules we have now are the result of careful consideration and incremental changes aimed at specific, provable issues with previous standards. While I am not a proponent of "not all actions are logged" as a blanket excuse for no logged actions in several years, it is feasible that an admin could be otherwise fully engaged with the community while not having any logged actions. We haven't been having trouble with admins who would be removed by this, so where's the problem? Just Step Sideways ^{from this world ..... today} 19:15, 8 December 2024 (UTC)[reply]

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.

Collaboration with PubPeer

Dear all, Over the past few months, I have been in contact with the team managing PubPeer - a website that allows users to discuss and review scientific research after publication, i.e. post-publication peer review - to explore a potential collaboration with Wikipedia. After reviewing some data regarding citations (e.g., the DOIs cited in English (20%), Spanish, French, and Italian Wikipedia), they agreed, in principle, to share data about papers with PubPeer comments that are also used as sources in Wikipedia. From our calculations on a sample of 20% of the citations in enwiki, we estimate that there are around 5,000 unique DOIs cited in Wikipedia that may have PubPeer comments. This message is intended to brainstorm some possible ways to use this data in the project. Here are some of my initial ideas:

Create a bot that periodically (weekly? monthly?) fetches data about papers cited in Wikipedia with PubPeer comments and leaves a note on the Talk page of articles using these sources. The note could say something like, "There are PubPeer comments related to articles X, Y, Z used as sources in this article."
Develop a gadget that replicates the functionality of the PubPeer browser extensions.

Let me know your thoughts on these ideas and how we could move forward. --CristianCantoro (talk) 00:02, 29 December 2024 (UTC)[reply]

How would this be valuable to Wikipedia? Izno (talk) 00:45, 29 December 2024 (UTC)[reply]

PubPeer is a post-publication peer review forum. Most of the discussions over there report issues with papers. Knowing that a paper that is used as a source has comments on PubPeer is very valuable, IMHO, as It would be useful for editors to evaluate the quality of the source and decide if it makes sense to keep using it. Paper retractions are also reported on PubPeer (see an example), and the PubPeer extension marks retracted papers in red. Basically the idea is to replicate the functionality of the PubPeer extension for editors that don't have it. Furthermore, PubPeer IDs are registered in Wikidata. --CristianCantoro (talk) 18:14, 29 December 2024 (UTC)[reply]

But we cite information from reliable sources. I don't see why we'd want a list of people saying they don't think a publication is good, we'd want those sources addressed, surely? Lee Vilenski ^{(talk • contribs)} 18:28, 29 December 2024 (UTC)[reply]

I think the point is that an article with a lot of PubPeer commentary is quite likely not to be a reliable source. – Joe (talk) 20:55, 29 December 2024 (UTC)[reply]

@Lee Vilenski, PubPeer is exactly a forum where issues with papers are raised, and the authors also have the opportunity to address the concerns. While a source such as a well-established scientific journal is generally reliable, we do not know anything about the quality of a specific paper. To me, knowing that there are comments on PubPeer about a paper is valuable because, in general, those comments are not just about "I like/dislike this paper;" instead, they usually raise good points about the paper that I think would provide valuable context to a Wikipedia editor who is trying to determine whether a given paper is a good source or not. PubPeer is regularly used by the community of "scientific sleuths" looking for manipulated or fabricated image and data as you can read in this press article: "A once-ignored community of science sleuths now has the research community on its heels" (there are many other examples) --CristianCantoro (talk) 21:26, 29 December 2024 (UTC)[reply]

This does seem like it could be very useful for users interested in the quality of research. I think a gadget highlighting DOIs would be most useful, but using a bot to tag affected pages with a template that adds them to a maintenance category (like this one) would also be a great idea. Toadspike [Talk] 22:35, 29 December 2024 (UTC)[reply]

I think this is a great idea. A bot-maintained notification and maintenance category would be a great starting point. As for a gadget, there are already several tools aimed at highlighting potential reliability issues in citations (e.g. User:SuperHamster/CiteUnseen, User:Headbomb/unreliable) so I think it would be better to try and get PubPeer functionality incorporated into them than start a new one. – Joe (talk) 10:13, 30 December 2024 (UTC)[reply]

Respectfully, I don't really think that collaborating with a website and using its number of user-generated comments to decide of the reliability of our sources is the best idea. While being informed of comments that have been made on the articles could be helpful, placing every article whose source have PubPeer comments in a maintenance category amounts to saying these sources are automatically a problem to be fixed, and that shouldn't be a call left to commenters of another website. Chaotic Enby (talk · contribs) 11:57, 30 December 2024 (UTC)[reply]

Why not? I don't think there's any realistic prospect of doing it internally. – Joe (talk) 12:32, 30 December 2024 (UTC)[reply]

Putting an article in a maintenance category because a user-generated review website made comments on a source is clearly not the level of source assessment quality we're striving for. Plus, there's the risk of things like canvassing or paid reviews happening on that other website, as they don't have the same policies that we do, but impact the (perceived) article quality here by tagging these sources as problems to be fixed. Chaotic Enby (talk · contribs) 12:39, 30 December 2024 (UTC)[reply]

I believe the proposal is to add the talk page to a category (because it's attached to a talk page message), and not to do any tagging, so this would be pretty much invisible to readers. It would just be a prompt for editors to assess the reliability of the source, not a replacement for source assessments. PubPeer is also not really a "review" website but a place where people (in practice mostly other scientists) can comment on potential errors and misconduct in scientific papers, so the risk of abuse, while present, seems very slight. Who would benefit from it? – Joe (talk) 14:06, 30 December 2024 (UTC)[reply]

That does make sense, thanks. I thought there could be cases where competing research teams might try to use it to discredit their opponents' papers, especially if it leads to visible Wikipedia messages, but if it is only a category on the talk page that is invisible for the readers, that sounds like a quite sensible idea. Chaotic Enby (talk · contribs) 17:45, 30 December 2024 (UTC)[reply]

Hi @Chaotic Enby, the idea is to have the information readily available in the talk page, and that would make our editors' life easier. In the end, it is just a matter of having some links in the talk page that an editor can check, if they want. Furthermore, I second the comment above from @Joe, PubPeer is very much used to report serious flaws with studies: a study from 2021 analyzed around 40,000 posts about 25,000 publications and found that "more than two-thirds of comments are posted to report some type of misconduct, mainly about image manipulation.". Take a tour on PubPeer and see for yourself. --CristianCantoro (talk) 15:40, 30 December 2024 (UTC)[reply]

I often cite scientific studies when I'm writing Froggy of the Day. It sounds like it would be remotely possible to make a bot or tool that could flag sources that have > howevermany comments on Pub Peer.

I often think about Wikipedia's mission to curate rather than create knowledge in terms of the sugar vs fat debate in nutrition. At the time Wikipedia was founded, the prevailing idea was that fat was more fattening in sugar with respect to human beings gaining or losing weight. In the years since, much of that was found to have been a promotional campaign by the sugar industry. It is not Wikipedia's place to contradict established scientific information even when individual Wikipedians know better but rather to wait until newer and better reliable sources are published. Such a tool could help us do that more quickly. Darkfrog24 (talk) 22:38, 3 January 2025 (UTC)[reply]

I think some sort of collaboration might be useful, but I don't want talk page notices clogging up my watchlist. Perhaps something that can complement existing userscripts that highlight source reliability would be good. voorts (talk/contributions) 00:39, 4 January 2025 (UTC)[reply]

Appearance setting to hide all inline notes from articles

While disabled by default, enabling it would hide all those [1][2][3], [a][b][c] and even [citation needed][original research?] inline notes from all articles, which makes reading Wikipedia more clearer, especially when reading about controversial topics. Those citation notes can be a distraction for some, so that's why i am proposing such a feature like this. 176.223.184.242 (talk) 12:37, 30 December 2024 (UTC)[reply]

Adding sup { display: none !important; } to your user CSS should do the job! (see also WP:CSSHIDE) Chaotic Enby (talk · contribs) 12:49, 30 December 2024 (UTC)[reply]

Yep. I'd oppose making it a default setting, though. I don't want to dictate to the IP how they should use Wikipedia or discount their experience, but those notes are vital for information literacy. If the IP is reading about controversial topics without them, they're risking exposing themselves to misinformation. Sdkb ^talk 17:18, 30 December 2024 (UTC)[reply]

Agreed! If anything, it is far more vital to have those inline references/citations when reading controversial information. This is even more critical for tags like citation needed/OR/etc because without them the reader is likely to take the statement as generally accepted fact instead of with the grain of salt that should be applied when such a tag has been added. TiggerJay (talk) 17:31, 30 December 2024 (UTC)[reply]

This reminds me of proposals made long ago to move all maintenance templates to the talk pages so that readers wouldn't be exposed to how messy and unreliable article content actually is. Donald Albury 19:57, 30 December 2024 (UTC)[reply]

I'd personally advise against enabling this, IP. Things tagged with [citation needed] may be just flat-out wrong. Cremastra 🎄 u — c 🎄 19:57, 31 December 2024 (UTC)[reply]

What about a third option to keep citation needed tags while hiding actual citations?

Show all inline notes
Show only inline maintenance notices
Hide all inline notes

176.223.186.27 (talk) 21:58, 1 January 2025 (UTC)[reply]

To build on what Donald Albury is saying, I think the readers should be reminded of how messy Wikipedia is. I just added a citation this afternoon, not only because I want the article's regulars to find an additional source but also because I want the readers to see the tag and know that the content is not sufficiently sourced at this time. (I believe in general that people should be more vigilant about assessing the reliability of what they read, and not only here on the Wiki.) If anyone does donate their time and trouble to make a way for readers to opt out of seeing ref tags and maintenance tags, I would oppose making it the default. Darkfrog24 (talk) 22:31, 3 January 2025 (UTC)[reply]

Transclusion of peer reviews to article talk pages

Hello,

First time posting here.

I would like to propose that peer reviews be automatically transcluded to talk pages in the same way as GAN reviews. This would make them more visible to more editors and better preserve their contents in the article/talk history. They often take a considerable amount of time and effort to complete, and the little note near the top of the talk page is very easy to overlook.

This also might (but only might!) raise awareness of the project and lead to more editors making use of this volunteer resource.

I posted this suggestion on the project talk page yesterday, but I have since realized it has less than 30 followers and gets an average of 0 views per day.

Thanks for your consideration, Patrick (talk) 23:07, 2 January 2025 (UTC)[reply]

I don't see any downsides here. voorts (talk/contributions) 01:55, 4 January 2025 (UTC)[reply]

Support; I agree with Voorts. Noting for transparency that I was neutrally notified of this discussion by Patrick Welsh. —TechnoSquirrel69 (sigh) 21:04, 6 January 2025 (UTC)[reply]

This is a great idea, it's weird that it isn't done already. Toadspike [Talk] 21:13, 6 January 2025 (UTC)[reply]

Remove Armenia-Azerbaijan general community sanctions

Opening this discussion is itself a violation of GS/AA, as SimpleSubCubicGraph is not extended-confirmed. Initial response from community members with standing to discuss these topics has been unanimously opposed so I see no reason to leave this open. _signed,Rosguill ^talk 01:25, 4 January 2025 (UTC)[reply]

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 believe Armenia and Azerbaijan sanction is now outdated and useless. I propose that the sanction on the two nations be removed permanently unless another diplomatic crisis happens between the two countries. My reasons are: A recent statement was made by Armenia offering condolences to Azerbaijan which has almost never happened, I believe that Armenia and Azerbaijan related pages blanket protection of Extended Confirmed should be lowered to Autoconfirmed protection, with the exception of the wars between the two sovereign nations. Additionally, relations are getting better between the two countries. For nearly 30 years, relations were rock bottom, diplomats were not found in Azerbaijan nor Armenia and tensions were at an all time high. However ever since the 2020 war the two nations have started to make amends. This first started with the peace deal ending the war between the two nations. Turkey whom is a staunch ally of Azerbaijan has started to resume direct flights from Yerevan, the capital of Armenia and Istanbul, the largest city in the Republic of Turkiye. In 2023, Armenia and Azerbaijan entered into extensive bilateral negotiations as well as a prisoner exchange between the two countries, and Armenia supported Azerbaijan for being the host of the UN climate change forum. Finally, last year the two countries solved many border issues and created a transport route between the two countries which is a symbol of peace. The two nations are much better off now than they were just 4 years ago and can be seen as having a cooperative/reconciling attitude. That is why I propose an amendment that will immediately downgrade all protections (from ECP to ACP) for all Armenia-Azerbaijan related pages. SimpleSubCubicGraph (talk) 00:31, 4 January 2025 (UTC)[reply]

Notified: Wikipedia:Administrators' noticeboard. voorts (talk/contributions) 00:53, 4 January 2025 (UTC)[reply]
Oppose. This statement does not provide an adequate or relevant reason for vacating WP:GS/AA's ECR remedy. Community sanctions are related to the conduct of editors on Wikipedia, not the conduct of international affairs. Since page and editor sanctions are regularly issued pursuant to GS/AA and CT/A-A, there is still a clear need for ECR. voorts (talk/contributions) 00:46, 4 January 2025 (UTC)[reply]
@Voorts Response Well I believe that the editors that cause edit conflicts and wars are mostly Armenian, Azerbaijani, or Turkish. They feel patriotic of their country and their side and have vilified the other side in their head, but with calming geopolitical tensions I believe that these editors will no longer feel the need to edit war on wikipedia. Its the same reason why you do not see British people edit warring on the page for the United States of America over the loss in the Independence War. Geopolitical relations between Great Britain and the United States of America are good. SimpleSubCubicGraph (talk) 00:52, 4 January 2025 (UTC)[reply]
But you do see Armenian/Azerbaijani people edit warring on pages about Armenia/Azerbaijan still. JJP_{Mas_ter} (she/they) 00:56, 4 January 2025 (UTC)[reply]

To add further context, you're correct that we don't have any sanctions regarding the US War of Independence. However, we do have sanctions regarding other historical topics, including anti-Semitism in Poland around World War II (WP:APL) and The Troubles (WP:CT/TT). As such, just because country leadership may communicate a lack of conflict doesn't mean editors on Wikipedia immediately edit within policy and treat each other with civility. Significa liberdade (she/her) (talk) 01:24, 4 January 2025 (UTC)[reply]
Per Voorts, GS/AA is enacted in response to the actions of editors. Real world diplomatic activity is not directly relevant. CMD (talk) 01:01, 4 January 2025 (UTC)[reply]

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.

ITN Nominators

I believe we should add a small section which includes all of the nominators who have made it onto In The News. I think this would be just a polite way of saying thank you for your proposal. SimpleSubCubicGraph (talk) 05:15, 4 January 2025 (UTC)[reply]

I will just note that we do not do that for nominators for any other elements on the main page. We don't use bylines in Wikipedia. Anyone who cares enough about who did what for an article can examine the page history. Donald Albury 15:16, 4 January 2025 (UTC)[reply]

Disagree, that would just incentivize many people to try to get their name on the Main Page for millions of readers to see, leading to more competition and less constructive contributions. Chaotic Enby (talk · contribs) 15:51, 4 January 2025 (UTC)[reply]

A small section where? Obviously not on the main page, as the previous replies have been assuming. But if someone wanted to maintain some sort of list at Wikipedia:In the news/Contributors and link it from WP:ITN, 🤷. We have Wikipedia:List of Wikipedians by number of DYKs that is something similar for DYK. Anomie ⚔ 16:01, 4 January 2025 (UTC)[reply]

That would be a much better idea indeed! Chaotic Enby (talk · contribs) 16:20, 4 January 2025 (UTC)[reply]

I agree! SimpleSubCubicGraph (talk) 18:18, 4 January 2025 (UTC)[reply]

Draft:In the news/Contributors I created a page if anyone wants to edit it. SimpleSubCubicGraph (talk) 18:21, 4 January 2025 (UTC)[reply]

The use of AI-generated content

As of late, the use of AI has caused controversy. As it currently stands, the only thing we have on AI generated content is WP:LLM which is more of an essay and not a policy/guideline.

This lack of AI-generated content guideline is baffling considering the increasing prominence of AI in our daily lives. We don't have any form of guideline for such.

As such I wanted to bring up that there should be a guideline and recommend a few things:

1. As someone who uses a second language, I heavily rely on AI assistance, however, I do not believe all the content on Wikipedia should be AI-generated as such, I recommend the limitation of AI generated content which is as follows:

a. While Wikipedia does not prohibit Wikieditors from using large language models to plan their contributions, the Wikieditor must personally check and take responsibility for every word and every fact.

b. It cannot be used in talk pages or any form of communication. This is because AI-generated content with headlines are a mess already, and we don't need clutter on the talk pages. Plus existing guidelines require competence and communication is a social skill that is important anyways.

c. If it is AI-generated or any form of it is, in the edit summaries, it must be disclosed. This should not be used against the editor in any form unless somehow it becomes an issue.

2. You are responsible for making sure the content generated by AI follows the guidelines and policies. You cannot make the old "oh but AI generated it, not me, so I'm not responsible." excuse. This clause is being added to avoid that excuse from causing headaches that could already be avoided in the beginning.

Many of the ideas that already exist at WP:LLM I can see also being part of the guideline. What are your thoughts on making an official policy on this. This means that the policy would rely on other policies and if the policies change, it must keep in mind about the AI policy.

As it currently stands, essays and information pages are not POLICIES & GUIDELINES so we desperately need one for the sanity of everyone here working on Wikipedia.

Pinging @Giant Snowman as I find he would be interested in adding some stuff regarding the creation of this policy.

Sincerely,
Reader of Information (talk) 01:06, 6 January 2025 (UTC)[reply]

By byte count, 71.38% of WP:VPP is currently taken up by discussions about AI. Why don't you join one of those discussions? Anomie ⚔ 02:20, 6 January 2025 (UTC)[reply]

In this case, that wouldn’t be possible as what I’m requesting is a formal policy and guideline that actually explains what AI use is allowed and what isn’t.

From what I understand, the other threads are asking for clarification on if AI is allowed in a certain circumstance NOT a guideline.

Cheers,
Reader of Information (talk) 11:17, 6 January 2025 (UTC)[reply]

what I’m requesting is a formal policy and guideline That's two separate things and...where is the proposal? Selfstudier (talk) 11:22, 6 January 2025 (UTC)[reply]

Whoops! I thought that it was obvious that was what I meant when I said “I recommend a few things… as follows:”. That is my fault and I’m glad I was able to clarify!

Cheers,
Reader of Information (talk) 11:31, 6 January 2025 (UTC)[reply]

A guideline won't happen without those threads being solved. I would recommend not using AI for second-language writing, translate in small chunks if needed, and it's likely closer to what you want to say. CMD (talk) 11:30, 6 January 2025 (UTC)[reply]

I disagree. I can write in English easily when it’s what I’m expressing in terms of what I’m thinking that’s easy.

However, whenever I write something with a lot of guidelines, I end up tensing up and my brain cannot create it completely from scratch without having random words in front of it. If random words are written already and all I need to do is revise it so it makes sense, that’s where I am able to be successful. I do this to avoid WP:MADEUP as that’s not what the Wikipedia project is for. That’s how I’m able to make constructive edits that contribute to Wikipedia as a whole. That’s also how I avoid the misuse of AI as it’s a godsend for me as someone who always tenses up when I’m writing something within guidelines and restrictions.

Of course I believe I need to clarify, I completely revise the text to the point none of the words from the AI is in the final version.

Cheers,
Reader of Information (talk) 11:41, 6 January 2025 (UTC)[reply]

That doesn't address my suggestion, which was using translation software that isn't designed to generate extra content. The idea that "none of the words from the AI is in the final version" is not believable, English is varied but generally there are some standard common words. CMD (talk) 11:44, 6 January 2025 (UTC)[reply]

Oh! I COMPLETELY misunderstood. I don’t translate it whatsoever. The only way I translate anything is through DeepL or Google Translate. If it’s worth anything my first language is sign language so you can’t really translate that language with the use of AI.

Cheers,
Reader of Information (talk) 11:51, 6 January 2025 (UTC)[reply]

Thank you, that's very helpful clarification. I'd like to know more, I'll take to the user talk. CMD (talk) 11:58, 6 January 2025 (UTC)[reply]

I'd broadly support a proposal like this. If I'm being (very) nitpicky, I'd say we shouldn't include must contain no words that were initially created by the AI, as this implies literally every word needs to be re-written, which might not be feasible (nor would it significantly impact AI-generated detector tools in the case of simpler phrases). — Czello ^(music) 11:46, 6 January 2025 (UTC)[reply]

What would an alternative be? I’m more than open to a different way of applying it. Reader of Information (talk) 11:51, 6 January 2025 (UTC)[reply]

Whoops, I need to reclarify what I meant. I meant to say:

Do you have any suggestions on an alternative for that part of the policy? I’m open to any ideas.

Cheers,
Reader of Information (talk) 11:52, 6 January 2025 (UTC)[reply]

"While Wikipedia does not prohibit Wikieditors from using large language models to plan their contributions, the Wikieditor must personally check and take responsibility for every word and every fact." How's that? If someone's little brother etc. gets into their account and violates policy, the person who holds the account is held responsible. Of course, that always involved the assumption that the user was lying about a little brother... Darkfrog24 (talk) 13:11, 6 January 2025 (UTC)[reply]

That seems reasonable to me. I’ll edit it to include that. Reader of Information (talk) 13:15, 6 January 2025 (UTC)[reply]

Isn't that already the case? LLMs do not exempt anyone from the responsibility of their edits. Chaotic Enby (talk · contribs) 23:51, 6 January 2025 (UTC)[reply]

Can someone here move this to idea lab, it’s clear this needs more improvement and is not ready to be implemented as I previously thought. Reader of Information (talk) 13:17, 6 January 2025 (UTC)[reply]

As I've previously discussed, I think any guidance should not refer to specific technology, which changes rapidly and has many uses. isaacl (talk) 15:53, 6 January 2025 (UTC)[reply]

I'm sympathetic to this argument but in reality we do this all the time. This isn't a perfect analogy (i.e., if you nitpick it, then I am probably already aware of what you are nitpicking) but WP:RSN and by extension WP:RSP are both extremely useful resources about any given media outlet, and also something that lags behind how reliable they are now, as opposed to when someone brought them up.

(that is, if it wasn't just wrong from the outset; there are one or two cases where I literally know the guy employed as a fact-checker at publications people claimed were unreliable for not fact-checking) Gnomingstuff (talk) 18:36, 7 January 2025 (UTC)[reply]

We have an information page regarding AI usage on Wikipedia, see Wikipedia:Artificial intelligence. Some1 (talk) 02:07, 9 January 2025 (UTC)[reply]

The original poster was suggesting that there be a guideline on AI; since that's an info page, I don't think it fits the bill w/r/t what OP was looking for. —pythoncoder (talk | contribs) 05:20, 9 January 2025 (UTC)[reply]

Pythoncoder explained it well. Sorry. I didn’t see this message. My apologies. Reader of Information (talk) 11:15, 9 January 2025 (UTC)[reply]

The community held an RfC back in October 2023 regarding the promotion of WP:LLM to policy status, but it failed to gain consensus: Wikipedia talk:Large language models/Archive 6#RfC: Is this proposal ready to be promoted?. (There was another similar RfC afterward, but unfortunately, I can't remember what it was called.) To quote the close: The most common and strongest rationale against promotion ... was that existing P&Gs, particularly the policies against vandalism and policies like WP:V and WP:RS, already cover the issues raised in the proposals.

I think the best approach now would be for editors to initiate community-wide RfCs focused on specific uses of AI on Wikipedia, such as what I did with Wikipedia:Village pump (policy)#BLPs, and work on integrating the consensuses of those RfCs into the existing policy pages themselves (the RfC consensus of that discussion, for example, is currently reflected in WP:BLP, WP:NOR, WP:IMAGEPOL). I would also suggest adding the RfCs to Wikipedia:Artificial intelligence#Discussion timeline to make it easier for readers and editors to find and read past AI-related discussions and their outcomes. Some1 (talk) 12:41, 9 January 2025 (UTC)[reply]

I disagree with that statement in all honesty.

I can be empathetic to the idea of having it into existing policies, but should we be really putting it into already existing policies and then making it more confusing for people looking for the AI aspect’s when it could be in just one page. I don’t know, as logistically, it doesn’t add up in my opinion. Reader of Information (talk) 13:55, 9 January 2025 (UTC)[reply]

Sure, the issues raised are covered but its covered for normal human interaction not AI, AI is whole different ball game and it’s advancing to the point where it might even pass off as human eventually. Reader of Information (talk) 13:57, 9 January 2025 (UTC)[reply]

Emptying Category:Wikipedians

Hello, I am bringing a proposal here as I have received conflicting advice at the original discussion (perhaps due to an incorrect usage of {{edit request}} by me?). I propose the category is either unmarked as a container, or the existing top-level user pages are sorted/removed (with possible exception of historical users?). Tule-hog (talk) 20:28, 6 January 2025 (UTC)[reply]

This comes up periodically when someone notices the container cat filling up with new users.

Just follow the normal process of removing the users. Leave them a note to add themselves to some more appropriate subcat, if you wish. - jc37 20:43, 6 January 2025 (UTC)[reply]

Perhaps important context is that the categorization of Wikipedians is a minefield that has led to a lot of spilled ink and anger. If you dig in the archives you can find the discussions. Spending a lot of times to make those categories look nice does not help us achieve our goal of writing an encyclopedia, and therefore it may be considered a waste of time by some. See also Category:Wikipedians who retain deleted categories on their userpages. {{edit request}} is for when you can't make the edit so someone else has to do it for you (e.g. if you need an admin to edit a page you can't edit because it has been protected). Polygnotus (talk) 20:48, 6 January 2025 (UTC)[reply]

Did we finish the encyclopaedia? If nit surely there's some reader-facing makework we could do? HJ Mitchell | Penny for your thoughts? 20:51, 6 January 2025 (UTC)[reply]

How are we ever supposed to finish when you keep writing new articles? You are part of the problem! I propose we get rid of all articles, except horse, and then we replace the content with a single sentence. Polygnotus (talk) 20:57, 6 January 2025 (UTC)[reply]

Sections

I noticed that some sections are written like: == xxxxx == and some are written like ==xxxxx==. Some have gaps and some do not. Won't it be better if it was standardized? I prefer the one without gaps because it should save space. TrueMoriarty (talk) 06:47, 10 January 2025 (UTC)[reply]

Such a proposal is infeasible, as we have over 6 million articles in a mix of both styles. Although a script would probably handle 90% of them there'd be heaps of edge cases among the remaining ones to consider. Also that's assuming that editors would actually agree on a single style; given our track record with such things I think that's unlikely. novov talk edits 09:03, 10 January 2025 (UTC)[reply]

Yes, or shall we have an inconclusive discussion that lasts for months and involves hundreds of editors? Phil Bridger (talk) 09:14, 10 January 2025 (UTC)[reply]

What else is Wikipedia for?--3family6 (Talk to me | See what I have done) 14:25, 10 January 2025 (UTC)[reply]

That means only 700,000 articles would be left. New editors can fix the others as a beginner's task.

TrueMoriarty (talk) 12:20, 10 January 2025 (UTC)[reply]

So Wikipedia adopts a novitiate/apprenticeship system? I like the idea of that, so long as it's not mandated at all but voluntary. I don't think this particular task would be of any help or use, though. It really doesn't matter.--3family6 (Talk to me | See what I have done) 14:25, 10 January 2025 (UTC)[reply]

Istruggletothinkofabiggerwasteoftime,thoughofcourseweshouldalldoourparttosavespace.– Joe (talk) 09:15, 10 January 2025 (UTC)[reply]

Joe, where should I send the the 0.00000004 cents that it would cost for you to use spaces? Phil Bridger (talk) 09:21, 10 January 2025 (UTC)[reply]

This would fall under WP:COSMETICEDIT, because the spaces (or lack thereof) has no change in visual output. It's not worth our time to fix something that has no real effect on pages, flooding watchlists and annoying people in the process. Also, ironically, the heading for this thread is written with spaces. —k6ka 🍁 (Talk · Contributions) 12:52, 10 January 2025 (UTC)[reply]

That is likely because as far as I've seen most of the software and scripts add spaces. CMD (talk) 13:59, 10 January 2025 (UTC)[reply]

It's potentially worth making a call on what's considered ultimate best practice, just so that the software and scripts can be aligned. But agreed that this is far too cosmetic to be worth changing, even within something like the GENFIX set. Sdkb ^talk 23:03, 10 January 2025 (UTC)[reply]

Good Article visibility

I think it would be a good idea to workshop a better way to show off our Good, A-class and Featured articles (or even B-class too), and especially in the mobile version, where there is nothing. At present, GA icons appear on the web browser, but this is it. I think we could and should be doing more. Wikipedia is an expansive project where page quality varies considerably, but most casual readers who do not venture onto talk pages will likely not even be aware of the granular class-based grading system. The only visible and meaningful distinction for many readers, especially mobile users, will be those articles with maintenance and cleanup tags, and those without. So we prominently and visibly flag our worst content, but do little to distinguish between our best content and more middling content. This seems like a missed opportunity, and poor publicity for the project. Many readers come to the project and can go away with bad impressions about Wikipedia if they encounter bad or biased content, or if they read something bad about the project, but we are doing less than we could to flag the good. If a reader frequents 9 C-class articles and one Good Article, they may simply go away without even noticing the better content, and conclude that Wikipedia is low quality and rudimentary. By better highlighting our articles that have reached a certain standard, we would actually better raise awareness about A) the work that still needs to be done, and B) the end results of a collaborative editing process. It could even potentially encourage readers who become aware of this distinction to become editors themselves and work on pages that do not carry this distinction when they see them. In this age of AI-augmented misinformation and short-attention spans, better flagging our best content could yield benefits, with little downside. It could also reinject life and vitality into the Good Article process by giving the status more tangible front-end visibility and impact, rather than largely back-end functionality. Maybe this has been suggested before. Maybe I'm barking up the wrong tree. But thoughts? Iskandar323 (talk) 15:09, 11 January 2025 (UTC)[reply]

With the big caveat that I'm very new to the GA system in general and also do not know how much technical labor this would require, this seems like a straightforwardly helpful suggestion. The green + sign on mobile (and/or some additional element) would be a genuinely positive addition to the experience for users - I think a textual element might be better so the average reader understands what the + sign means, but as it stands you're absolutely right, quality is basically impossible to ascertain on mobile for non-experts, even for articles with GA status that would have a status icon on desktop. 19h00s (talk) 16:43, 11 January 2025 (UTC)[reply]

While GA articles have been approved by at least one reviewer, there is no system of quality control for B class articles, and no system to prevent an editor from rating an article they favor as B class in order to promote or advertise it. A class articles are rare, as Military History is the only project I know of that uses that rating. Donald Albury 17:16, 11 January 2025 (UTC)[reply]

I totally agree we should be doing more. There are userscript that change links to different colours based on quality (the one I have set up shows gold links as featured, green as GA, etc).

If you aren't logged in and on mobile, you'd have no idea an article has had a review. Lee Vilenski ^{(talk • contribs)} 20:15, 11 January 2025 (UTC)[reply]

A discussion was held on this about two years ago and there was consensus to do something. See Wikipedia talk:Good Article proposal drive 2023#Proposal 21: Make GA status more prominent in mainspace and Wikipedia:Good Article proposal drive 2023/Feedback#Proposal 21: Make GA status more prominent in mainspace. Thebiguglyalien (talk) 04:20, 12 January 2025 (UTC)[reply]

@Thebiguglyalien: Is that feedback discussion alive, dead, or just lingering in half-life? It's not obviously archived, but has the whole page been mothballed? So basically, there's community consensus to do something, but the implementation is now the sticking point. Iskandar323 (talk) 04:57, 12 January 2025 (UTC)[reply]

Basically, most of the progress made is listed on that feedback page and the project has moved on from it. There were a few options, like the visibility one, where it was agreed upon and then didn't really go anywhere. So there are some ideas there, but we'd basically need to start fresh in terms of implementation. Thebiguglyalien (talk) 05:16, 12 January 2025 (UTC)[reply]

Tracked in Phabricator
Task T75299
You're barking up exactly the right tree, Iskandar323. Regarding showing the icons on mobile, that's a technical issue, which is tracked at phab:T75299. I highlighted it to MMiller (WMF) when I last saw him at WCNA, but there's ultimately only so much we can push it.
Regarding desktop, we also know the solution there: Move the GA/FA topicons directly next to the article name, as was proposed in 2021. The barrier there is more achieving consensus — my reading of that discussion is that, while it came close, the determining factor of why it didn't ultimately pass is that some portion of editors believed (wrongly, in my view) that most readers notice/know what the GA/FA symbols mean. The best counterargument to that would be some basic user research, and while ideally that would come from the WMF, anyone could try it themselves by showing a bunch of non-Wikipedian friends GAs/FAs and asking if they notice the symbols and know what they mean. Once we have that, the next step would be running another RfC that'd hopefully have a better chance of passing. Sdkb ^talk 06:50, 12 January 2025 (UTC)[reply]
It's great that I've got the right tree, since I think that's a village pump first for me. It seems that the proposer of that original 2021 discussion already did some basic research. Intuitively, it also seems just obvious that an icon tucked away in the corner, often alongside the padlocks indicating permission restrictions, is not a high visibility location. Another good piece of final feedback in the GA project discussion mentioned earlier up this thread by TBUA is that the tooltip could also been improved, and say something more substantial and explanatory than simply "this is a good article". On the subject of the mobile version and the level of priority we should be assigning to it, we already know that per WP:MOBILE, 65% of users access the platform via mobile, which assuming a roughly even spread of editors and non-editors, implies that 2/3 of contemporary casual visitors to the site likely have no idea about the page rating system. Iskandar323 (talk) 07:31, 12 January 2025 (UTC)[reply]

RSS feed for Portal:Current events

An admin suggested that I make this a proposal here so here it is:

Unlike other Main page sections such as On this day (RSS) or Featured article (RSS), daily entries from Portal:Current events do not yet have an RSS feed. This has been requested several times on the Portal's talk page over the years, but never gained traction: 2006, 2010, 2013, 2020.

Adding a feed via MediaWiki's FeaturedFeeds extension should be relatively straightforward (for an admin with access to extension settings):

Create the feed page under MediaWiki:Ffeed-currentevents-page ("currentevents" would be the feed's name). Requires admin access.
Add the following as the page's source: Portal:Current events/{{#time:Y F j|-1 day}} (This should set yesterday's current events to today's feed entry.)
Configure the new feed in Wikipedia's FeaturedFeeds settings (adapting from extsting settings from other existing feeds like On this day). I'm not sure exactly what access is required here, or whether this can only be done by a WMF staff member.

I may be biased, but I don't see any good reason not to provide Current events as an RSS feed: it simply gives users another way to access this fantastic content using their favorite feed reader. Thoughts? Robinmetral (talk) 08:09, 12 January 2025 (UTC)[reply]