Jump to content

Wikipedia:Village pump (idea lab)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by CMBJ (talk | contribs) at 20:22, 5 July 2023 (AI add-on for illustration: answering the first point). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, note:

Before commenting, note:

  • This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
  • Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61

CSD for LLM written articles requiring WP:TNT

We're having more and more articles that are clearly written by large language model with fake sources. I just deleted Voice acting in India as a G3 hoax, as it was made up by a language model, and then a bunch of fake sources were added. Should we have a CSD specifically to cover LLM creations, or is G3 sufficient? ScottishFinnishRadish (talk) 17:27, 12 June 2023 (UTC)[reply]

I think it’s too early in the LLM era to state definitively that articles created by (or with the assistance of) LLMs cannot be valid. Models are improving in capability very rapidly. We should monitor this and be vigilant, but in the meantime, I think G3 (and possibly A11) should suffice. Barnards.tar.gz (talk) 18:43, 12 June 2023 (UTC)[reply]
We already have a draft WP:LLM policy which strongly discourages their use.
There's two main issues with them:
1. LLMs are completely unaware of Wikipedia policy and are thus very likely to commit copyright infringement, say something libelous about a living person, rely on sources we wouldn't consider acceptable, or violate NPOV.
2. LLMs are very likely to hallucinate completely false info and even fake citations. Loki (talk) 18:52, 12 June 2023 (UTC)[reply]
Not sure. Could you describe the scale of the problem in more concrete terms? Loki (talk) 18:52, 12 June 2023 (UTC)[reply]
The scale? No idea. I noticed this one because the editor's user page was on my watchlist from some warnings I left them a year ago. I know others have found LLM created articles as well. It's also an issue that's going to get worse. ScottishFinnishRadish (talk) 22:26, 12 June 2023 (UTC)[reply]
I think the LLM-written articles that we need to worry about are the ones where the use of an LLM is not obvious. That would not then be a valid CSD reason. Phil Bridger (talk) 19:29, 12 June 2023 (UTC)[reply]
This is the problem. LLM detection tools are prone to both false positives and false negatives. Often, they themselves use LLMs. Policies like these tend to be based on the obvious cases, but the reason those cases are obvious is because they flagrantly violate some other existing policy. What happens when it's unclear? Gnomingstuff (talk) 15:22, 13 June 2023 (UTC)[reply]
I think any new article filled with fake sources, regardless of what tools might have been used to create it, should be subject for deletion, and G3 as a blatant hoax seems like a suitable criterion. Not having any sources at all is a trickier issue, since traditionally deletion discussions are based on whether or not the subject meets English Wikipedia's standards for having an article, rather than the current state of the article. isaacl (talk) 20:51, 12 June 2023 (UTC)[reply]
That's why I specifically called out a TNT situation. It's likely Voice acting in India is a notable enough topic, but what was there was irredeemably tainted. G3 somewhat applies, but CSD is normally pretty tightly interpreted. If there's consensus that G3 covers it, in happy with that, but it seems like it might be stretching in some situations. ScottishFinnishRadish (talk) 22:24, 12 June 2023 (UTC)[reply]
When you asked "Should we have a CSD specifically to cover LLM creations," did you mean just LLM creations that had fake sources? If not, then the question would be when the current state of an article should be deemed irredeemable as a starting point. Personally I would prefer to focus on the characteristics of the article that make it irredeemable, regardless of what tools may have been used to create it. isaacl (talk) 23:06, 12 June 2023 (UTC)[reply]
I should have repeated it in my main question, but as the section heading says, specifically for TNT situations. There's nothing worth keeping when an article is a hallucinatory essay written by an algorithm. ScottishFinnishRadish (talk) 23:28, 12 June 2023 (UTC)[reply]
If an article warrants deletion due to no redeeming characteristics, it doesn't matter if it was written entirely by hand or with the assistance of a program. I'm not sure there's a good way to define that in a clear-cut manner in the nature of the speedy deletion criteria, though. isaacl (talk) 23:44, 12 June 2023 (UTC)[reply]
We delete bad content rather than taking an ad hominem (ad machina?) approach, but it's useful to have some way of finding pages that smell of AI so they can be judged, not on author but on article quality (or lack of it). Certes (talk) 00:01, 13 June 2023 (UTC)[reply]
(ad machinam) Folly Mox (talk) 23:04, 13 June 2023 (UTC)[reply]
How large is the problem quantifiably? Are the number of articles created that this criterion would apply to large enough that AfD would be stressed? Tazerdadog (talk) 22:22, 12 June 2023 (UTC)[reply]
AfD is already stressed. Aside from that, is AfD the venue to bring an article that was created with no effort by an algorithm with no real sources? Editor time is the most valuable resource in Wikipedia, so anything that avoids waste is important. ScottishFinnishRadish (talk) 22:31, 12 June 2023 (UTC)[reply]
When we say "editor time" in this context, we often mean "people who don't really create content". We don't seem to care much about wasting the time of the editors who created the articles.
I see two relevant possibilities:
  • The accurate identification: The article was created by an LLM, and was correctly identified as being a problematic article.
  • The false accusation: The article was not created by an LLM, but someone wants to get rid of it (for any reason, including a genuine mistake about its origin).
In the first case, AFD might waste the AFD respondents' time; in the second case, CSD would definitely waste the content creator's time. The question is: Whose time do we want to waste?
Since whether a page was created by an LLM is not uncontroversial, and CSD is supposed to be for uncontroversial deletions, I don't think we can stick to the principles of CSD and also have CSD for articles that one editor claims, usually without indisputable evidence, that its origin involved LLM. WhatamIdoing (talk) 04:10, 14 June 2023 (UTC)[reply]
By editors we should mean editors, rather than splitting the community based on personal opinions. Wasting the time of any editor on articles that took seconds to create and are likely full of AI hallucinations, is time that they could have spent on improving the encyclopedia. -- LCU ActivelyDisinterested transmissions °co-ords° 20:09, 14 June 2023 (UTC)[reply]
How do you know that a given article "took seconds to create"? Just guessing based on how fancy the result looks? WhatamIdoing (talk) 12:32, 25 June 2023 (UTC)[reply]
Do we have any tools (bots?) for checking that the source URLs in new articles exist? Of course, sources that don't exist may be valid (RS deleted an ephemeral news item) or good-faith errors (mistyped URL); and sources which exist may be invalid (unreliable source cited, either wilfully or in error); but a check that they exist might flag up some LLM content in a useful way. Certes (talk) 23:53, 12 June 2023 (UTC)[reply]
I suppose there's IABot, which can analyze a page and then tag everything as a dead link. Snowmanonahoe (talk · contribs · typos) 23:56, 12 June 2023 (UTC)[reply]
I wonder if it could wave a red flag in a suitable venue if it finds a new article full of dead links. Certes (talk) 23:58, 12 June 2023 (UTC)[reply]
Not a bad idea. Snowmanonahoe (talk · contribs · typos) 23:59, 12 June 2023 (UTC)[reply]
Not a bad idea but an imperfect one, since LLMs can also hallucinate print sources (or, worse, spit out the name of a real book that has absolutely nothing to do with the "fact" it stated). Gnomingstuff (talk) 15:29, 13 June 2023 (UTC)[reply]
There was no consensus for a new CSD at WT:CSD a month ago or four months ago. So I support G3 for this. No one wants to waste hours fixing LLM outputs that took a second to add, and no one wants to come to Wikipedia to read raw LLM outputs when they can get the same shitty output directly from the LLM. Many LTAs will delight in adding this stuff. If we don't clamp down on that spam, many editors & readers will give up on Wikipedia altogether, and its newfound perception of reliability among the press will wither away. See also broken windows theory: if vandals add raw LLM outputs and notice that nothing is done about it, they'll be emboldened, and if readers notice these articles, they might join in on the "fun". To respond to WAID, I'll repeat what I said at WT:LLM: right now, it's mostly easy to tell and uncontroversial (for example, see this unanimous MfD), so this isn't an issue. DFlhb (talk) 12:49, 14 June 2023 (UTC)[reply]

Pronouns for Individuals

I think that in the biography section of Individuals it should list their pronouns, therefore making it easier for someone to search how someone identifies without going to check across the page. wookiepedia added that feature and it really helps CatdemonBlahaj (talk) 21:09, 14 June 2023 (UTC)[reply]

What would you consider appropriate sourcing for such statements? AndyTheGrump (talk) 21:26, 14 June 2023 (UTC)[reply]
WP:ABOUTSELF allows any source published by the individual themselves to be reliable sources.
Maybe this can be useful for people whose pronouns are not immediately obvious from the picture/prose. A parameter in the Infobox would be a nice place for it. Carpimaps talk to me! 14:33, 18 June 2023 (UTC)[reply]
I like the idea in theory, but I would note that info boxes and lead paragraphs are targeted by vandals much more than the rest of the prose. Wikidata has personal pronoun (P6553), so there is precedent on other projects for recording the information. ⁓ Pelagicmessages ) 02:34, 24 June 2023 (UTC)[reply]

Merging help forums Teahouse and Help desk

Is there any reason why WP:Teahouse and WP:Help Desk are two different forums? They essentially achieve the same thing (asking about "how to use or edit Wikipedia"). I think this is an unnecessary split of volunteers and is confusing for beginners. I would like to propose a merge, but I want to know if I missed anything. Carpimaps talk to me! 14:28, 18 June 2023 (UTC)[reply]

The key question is what do the participating volunteers think? The help desk and teahouse have different approaches and so may interest different types of volunteers. isaacl (talk) 15:43, 18 June 2023 (UTC)[reply]
Help Desk volunteers are people who are willing to answer the question "how do I create an article" twice a day, Teahouse volunteers are people who are willing to answer it more than twice a day.[Humour] -- Random person no 362478479 (talk) 16:11, 18 June 2023 (UTC)[reply]
They are intended for different audiences: the Teahouse for complete beginners, the Help Desk for people who know their way around Wikipedia in general, but have questions on details. Looking at the questions asked in both this separation seems to work to a certain degree. Of course some questions end up in the "wrong" place, but in general Teahouse questions do seem to tend to be on a more basic level. I don't know whether or not there really is an issue that new users are too intimidated to ask at the Help Desk. As a still relatively new user I asked my first question at the Teahouse, but I would have had no issues asking it at the Help Desk. In general I don't have the impression that people asking elementary questions at the Help Desk are treated poorly, but of course it is possible that this is only due to the fact that they don't pop up all the time. One thing I noticed is that Help Desk questions tend to get more answers than Teahouse questions and while that can sometimes be explained by the nature of the question that is not always the case. On the question of merging the two I have no strong opinions one way or the other. -- Random person no 362478479 (talk) 16:26, 18 June 2023 (UTC)[reply]
As a regular at both venues, I oppose a merge per my short answer over at WT:HD. —Tenryuu 🐲 ( 💬 • 📝 ) 03:30, 19 June 2023 (UTC)[reply]
Oppose per random. Dronebogus (talk) 13:15, 23 June 2023 (UTC)[reply]
I already withdrawn this on the Help desk talk page. Ca talk to me! 15:41, 23 June 2023 (UTC)[reply]

New design

Hey everyone, I suggest considering that the Template:village pump has been the same for years, a more modern and attractive design should be considered for it. 𝔹𝕒𝕣𝕗𝕚𝕣𝕥𝕒𝕝𝕜 18:37, 19 June 2023 (UTC)[reply]

Do you have a proposal for a design ? —TheDJ (talkcontribs) 21:13, 19 June 2023 (UTC)[reply]
More importantly, is this important? Dronebogus (talk) 13:13, 23 June 2023 (UTC)[reply]

A Wikipedia Museum

in my opinion i think that if what vandals did were archived in some way it would be good.

i think that when people see that Wikipedia doesn't tolerate vandal it will discourage people from becoming vandals. showing the horrors of what vandals did would put into peoples minds the idea that vandalism of Wikipedia is bad and shall not be tolerated .

i would like to hear your opinions on the mater

Pastalavist (talk) 18:43, 19 June 2023 (UTC)[reply]

Oppose. We should WP:DENY recognition to vandals. I think it unlikely the proposed target audience of "potential vandals" will see it. There are already numerous ways good-faith/curious readers can learn about the damage vandalism can do and that it is not acceptable. DMacks (talk) 18:52, 19 June 2023 (UTC)[reply]
yo think of it as glorification i think of it as learning about the dangers of vandalism Pastalavist (talk) 18:58, 19 June 2023 (UTC)[reply]
the "yo" was meant to be you
sorry Pastalavist (talk) 18:59, 19 June 2023 (UTC)[reply]
A Wikipedia Museum could be valuable, but it should not curate vandalism per WP:DENY. A collection of landmark discussions that those with institutional memory consider to have been important in shaping the current culture and policy could be a nice thing to have. @Graham87 and Iridescent:, do you know of any such collection? Folly Mox (talk) 19:00, 19 June 2023 (UTC)[reply]
it should not curate vandalism. rather it should curate anti-vandalism Pastalavist (talk) 19:02, 19 June 2023 (UTC)[reply]
Every contribution to Wikipedia is archived, except for deleted pages and deleted revisions. It is its own museum, but of course it is far too large and complex to be appreciated in one visit. There are various attempts to curate the history and guide the visitor. A few pages such as Wikipedia:List of hoaxes on Wikipedia document specific types of vandalism, but generally it is something we prefer not to celebrate or encourage. Certes (talk) 19:19, 19 June 2023 (UTC)[reply]
thank you certes for giving me clarity Pastalavist (talk) 19:26, 19 June 2023 (UTC)[reply]
@Folly Mox: There's an old page at Wikipedia:History of Wikipedian processes and people, Wikipedia:Milestones (for earlier years especially), and the Historical archive for some really out-of-the way pages. For more recent news there's the Signpost archives which go back almost uninterrupted to 2005. Curating a history of Wikipedia would be difficult because different people's ideas of what is and is not historically significant vary wildly and the importance of a particular page/discussion might not become apparent until much later. To this end I made a personal Wikipedia timeline which might interest some here. Graham87 04:23, 20 June 2023 (UTC)[reply]
Thank you User:Graham87; I knew you were the right person to ask. Very interesting and educational. Folly Mox (talk) 05:37, 20 June 2023 (UTC)[reply]
OP blocked as NOTHERE. Doug Weller talk 18:39, 25 June 2023 (UTC)[reply]

question re policy for BLP items

opening section

Miners below the age of 10 [Joke]
EUser talk:EEng#s
umm, this photo seems somewhat non-relevant, but why not. does wikipedia have an inline tag for "humor"? --Sm8900 (talk)

I have a question about usage of WP:BLP. we currently have articles on two minors below the age of ten, highlighting their royal status as members of a royal family. these two individuals have had absolutely no voice in whether these articles should be established or not. their parents have publicly distanced themselves from the referenced royal family.

I am wondering if BLP can be used to preserve the privacy of individuals who have not reached adulthood, and hopefully please remove the articles until they reach adulthood. I am sincerely trying to consider the long-term well-being of these two minors. eventually they will presumably gain access to the Internet, once they are old enough to do so. furthermore, they do not currently reside in the country where they would have royal status.

I don't feel that wikipedia should be increasing these minors' public visiblity, before they've had a chance to decide what public role they wish to have, if any. can anything be done to help with this situation? I'm truly open to any ideas. I recognize that our policy may or may not apply. thanks. --Sm8900 (talk) 19:56, 21 June 2023 (UTC)[reply]

You might try asking on WP:BLPN too. You are very vague about the details, so it's hard to tell, but for instance your description applies to the children of Prince Harry, Duke of Sussex. In that case, they are for better or worse subjects of intense media attention, and they are naturally going to be the subject of editors' interest; I can't think of any policy-based reason that we shouldn't have an article on them (which isn't to take a position on whether we morally should, just to say that current BLP policy allows it!), and I don't know that without a strong policy based reason you would be able to find consensus to delete or even merge these articles. There is an essay, WP:MINORS, which basically says "be even more careful editing about living children than even other living subjects", but even that doesn't suggest that we shouldn't have articles on notable minors. Caeciliusinhorto-public (talk) 12:06, 22 June 2023 (UTC)[reply]
There's also WP:BLPREQUESTDELETE which says that if a relatively unknown person requests deletion of their article, a no-consensus discussion can be closed as delete; even if we took that to include parents requesting deletion on behalf of their minor children I don't know whether e.g. Harry & Meghan's kids would count as "relatively unknown"... Caeciliusinhorto-public (talk) 12:08, 22 June 2023 (UTC)[reply]
@Caeciliusinhorto-public ok. let's expand the usage of "relatively unknown." because in fact no one knows these kids. in any way. they have made no public statements. even their own grandfathers don't know them! and one of those grandfathers is the basis for any supposed royal status! their utter absence of any public role, actions or statements, does in fact extend this protection to them. Sm8900 (talk) 14:27, 22 June 2023 (UTC)[reply]
  • I don’t think there is a “one size fits all” rule for this. In the case of children of royalty, I would say that (as a minimum) they should be discussed in the article about their Royal parent… but whether and when they would deserve a separate article is a more difficult question. Blueboar (talk) 12:24, 22 June 2023 (UTC)[reply]
the points above from all of you are all notable. however, for me the problem is that these kids literally haven't done anything at all in any public role at all... except, ya know, be born, and live in Montecito. shouldn't there be some way to take down an article on a minor, if it is based on a public role that they do not and probably will not ever actually assume in any practical way?
In other words, the minute that one of them actually makes any public statement, or takes any action, or even visits their supposed home country for literally the first time, (other than as infants), then maybe we could consider if any article is warranted or justified. --Sm8900 (talk) 14:05, 22 June 2023 (UTC)[reply]
Well, you are welcome to nominate the articles for deletion at WP:AFD, but I suspect the consensus will be to keep. People do tend to think Royals are notable just for existing, and there are sources that have discussed them. Your best arguments would probably be “privacy of a minor”, and “merge” into article on parents. Good luck. Blueboar (talk) 14:21, 22 June 2023 (UTC)[reply]
thanks @Blueboar! in 10 or 15 years, the press coverage may have melted away. these kids may be trying to get on with their own normal adolescent lives. meanwhile, do we really need an entire wikipedia article on them? what happens when they try to go to their first house party in montecito, and just want to chill with their preteen friends? haven't we all been there at some point in our lives? do we really have any basis or reason to put this albatross of an article onto them? your reply above is helpful. Sm8900 (talk) 14:25, 22 June 2023 (UTC)[reply]
I’m not the one you have to convince. Blueboar (talk) 17:45, 22 June 2023 (UTC)[reply]
true enough. and by the way, I was serious when I said your comment is truly helpful. Just wanted to clarify that so noone will misconstrue my meaning, or think I was being ironic in any way. thanks, @Blueboar. Sm8900 (talk) 14:09, 23 June 2023 (UTC)[reply]

Section break for comments

  • This is an area where I am definitely in disagreement with current Wikipedia policy. Current policy makes no distinction according to the age of anyone mentioned on Wikipedia. It should. I don't have the time to undertake the process for such a change myself, but I would certainly support any reasonable proposal made in that direction. Phil Bridger (talk) 17:50, 22 June 2023 (UTC)[reply]
    that's an excellent point. i may formulate something, and then post it on the tab for policy here at village pump, Sm8900 (talk) 02:28, 23 June 2023 (UTC)[reply]
    how this?
    proposed text:
    I would like to propose a new rule to be added to BLP; the proposed rule is that any minors who have made no public actions and have done nothing notable on their own, should not have any article created about them based on the public role of their parents.
    does that make sense, @Phil Bridger? what else can or should be added, to fully address this? Sm8900 (talk) 02:55, 23 June 2023 (UTC)[reply]
    This whole thing is smacking of WP:GREATWRONGS. It’s not our problem what the media choses to cover, and we can’t arbitrarily kill notable articles because we think their existence morally objectionable. What about Abu Ghraib torture and prisoner abuse? I don’t think the victims approved of the “coverage” they received, but we can’t, and shouldn’t, delete that article because of that. Dronebogus (talk) 13:12, 23 June 2023 (UTC)[reply]
    @Dronebogus, thanks for your point, but I see this differently. this is an unnecessary intrusion into the private lives of two young people, who have done absolutely nothing to warrant any such intrusion. and, just to posit one possible but purely specualtive scenario, the first time that one of those kids has to see that article printed out and taped to their school locker, the burden of guilt will fall upon our entire community here at wikipedia. these are just two innocent children growing up in montecito, who just want to have a nice life. I would like to allow them to do so. we are talking about an innocent child's future here, two of them.
covering current public issues is one thing. but these two children's titles are nothing but a miniscule fraction of a footnote to an obscure molehill lost in the mists of history. it's likely these entries will be deleted in a few decades, but only after some degree of discomfort to the two individuals. I would like to spare these decent youngsters any discomfort whatsoever. we can include their titles in the entries for their parents. that is fully sufficient to cover any supposed encyclopedic relevance for these titles. If I can help a young person to have a better chance to live their life in peace, I'd be glad to take any steps available.
by the way let me just say I do truly appreciate your taking the time to reply and to discuss this. we disagree somewhat, but I do appreciate your input. thanks. Sm8900 (talk) 14:02, 23 June 2023 (UTC)[reply]
Saying they’ll probably be deleted in 20+ years is WP:CRYSTAL. In fact literally everything here is basically WP:CRYSTAL with a side of appealing to guilt. Dronebogus (talk) 17:52, 23 June 2023 (UTC)[reply]
there's no basis for applying rules and policies to a good-faith post at the Idea Lab; doing so might in fact be a case of Wikipedia:JUSTDONTLIKEIT. Sm8900 (talk) 18:23, 23 June 2023 (UTC)[reply]
Um… no, rules and policies should be considered when developing new ones. Idea lab isn’t for back-slapping and thumbs-upping. Dronebogus (talk) 18:26, 23 June 2023 (UTC)[reply]
Idea lab is for positive collaborative brainstorming. it is fine to disagree and express differing views, but any debate should be based on the content of the ideas themselves. if someone is offering a proposal for a new idea, or a new item or a new approach, et cetera, then of course it runs somewhat outside of existing policies or existing established procedures, to some degree; if it did not, then there would not be a need to present it at idea lab for discussion, would there? Sm8900 (talk) 21:02, 23 June 2023 (UTC)[reply]
@Dronebogus, that principle was rejected very many years ago, when we developed the WP:BLP policy. Phil Bridger (talk) 21:58, 23 June 2023 (UTC)[reply]
What principle? I’m confused which comment you’re replying to Dronebogus (talk) 22:41, 23 June 2023 (UTC)[reply]
The principle that "it’s not our problem what the media choses to cover, and we can’t arbitrarily kill notable articles because we think their existence morally objectionable". I think I got the indentation right, but I apologise if it was not. Phil Bridger (talk) 20:32, 24 June 2023 (UTC)[reply]
I did not know that. What is the principle we’re working with here? Dronebogus (talk) 22:43, 24 June 2023 (UTC)[reply]
the principle is "we have the prerogative as a community to delete or remove notable articles, because we think their impact on affected individuals is highly detrimental and unethical." the underlying context for this is that this principle already exists to some degree within WP:BLP, in some form. Sm8900 (talk) 13:32, 26 June 2023 (UTC)[reply]
@Phil Bridger, I would suggest the word " greatly unethical" as perhaps more accurate than "morally objectionable." Sm8900 (talk) 13:34, 26 June 2023 (UTC)[reply]
I agree that there should be stricter criteria for BLPs of minors; not sure of the right criteria yet, have to think on it. Should be something that establishes why we have a stand-alone BLP for Blue Ivy Carter but not North West. Schazjmd (talk) 14:31, 23 June 2023 (UTC)[reply]
Has North West won a grammy? Blue Ivy has won an individual grammy, which clearly makes her independently notable. Dronebogus (talk) 17:54, 23 June 2023 (UTC)[reply]
I didn't question her notability or disagree with her having a stand-alone article. However, there's lots of media coverage of North, but we don't have an article on her (which, again, I agree with). I was saying that I think we should come up with minor-BLP criteria that supports having an article on Blue Ivy and not on North West, that it's not just about the two royal children. Schazjmd (talk) 18:00, 23 June 2023 (UTC)[reply]
  • Personally I would support much stronger protections for BLPs of minors (and minor-BLP content in other articles), even something far more drastic than suggested so far, such as requiring prior community approval on BLPN for article creation. (I am assuming, perhaps incorrectly, that just excluding such content entirely would be a non-starter.) The potential harm to the subject should weigh pretty heavily against the generally extremely minimal benefit to the project and its users. I have no great ideas about policy wording, but the WP:BLPMINOR essay might be worth a look. It might also be worth considering carefully borrowing concepts from privacy law, as WP:BLP already does in places. -- Visviva (talk) 19:30, 1 July 2023 (UTC)[reply]

Do we need to make categories more accessible and/or deprecate “navigational” lists?

Recently I’ve sent a bunch of “X by Y” listcruft articles to AfD. They’re poorly maintained and do not provide anything a category, which is automatically curated, doesn’t. But it’s been stated that, besides WP:NLIST giving clearance for lists about seemingly any notable topic, categories are not accessible on mobile. I think making categories more accessible is obviously a good thing and we should do it. I also think we should subsequently deprecate purely “navigational” lists that effectively duplicate categories. Thoughts? Dronebogus (talk) 13:06, 23 June 2023 (UTC)[reply]

Do any readers actually use categories? Or are they just there to give a few editors something to do? I would like to see the results of any research that has been conducted into this subject. Phil Bridger (talk) 22:04, 23 June 2023 (UTC)[reply]
This would be trivial to figure out if there were logs available showing flows of how people got from one wiki page to another. Tracing these flows is a standard feature of analytics tools, so it should shouldn't be hard to implement. Not much more than logging HTTP Referer data. I have no idea if these logs exist, or if they do, if they're publicly accessible. RoySmith (talk) 22:37, 23 June 2023 (UTC)[reply]
Do tou mean Shouldn’t be hard to implement? Dronebogus (talk) 22:39, 23 June 2023 (UTC)[reply]
Yeah. Fixed. RoySmith (talk) 22:41, 23 June 2023 (UTC)[reply]
@RoySmith You can access that data at toolforge:wikinav, though it is frequently semi-broken. 192.76.8.66 (talk) 23:53, 23 June 2023 (UTC)[reply]
Cool, thanks. RoySmith (talk) 23:54, 23 June 2023 (UTC)[reply]
@RoySmith I forgot to mention that you can also download the data from https://dumps.wikimedia.org/other/clickstream/readme.html 192.76.8.66 (talk) 15:21, 24 June 2023 (UTC)[reply]
@RoySmith Unfortunately I don't think the clickstream data includes anything identifiable as categories; it only identifies mainspace to mainspace links. There is an other-internal grouping but it's not clear if this is only interwiki links or if it would count project/category space links as well, and in any case it's not broken down further.
However we can get pure visitor counts using the usual pageviews tool - eg category:Living people gets about 1400/day. Category:Brazil averages 4, Category:2023 deaths averages 782 (though skewed by a big spike in early January), Category:Donald Trump averages 7, Category:Chemical elements averages 40 (with some intriguing usage patterns). A bit of a random selection, but you get the idea - viewer numbers look pretty low in the context of articles in those categories, so clickthroughs from them are unlikely to be significant.
One major factor here is likely to be that all desktop readers see categories, but mobile readers don't unless they're logged in. As a result, over 80% views across those sampled categories are from desktop users, while they only make up about a third of all views across the project. Andrew Gray (talk) 17:56, 24 June 2023 (UTC)[reply]
A quick addendum to that: I pulled down the full pageview file to sample it for one month. There were 7.75bn pageviews on enwiki in May 2023. 37.4m of those were category pages, or approximately 0.5% of the total.
Other namespaces for context -
  • File: (linked prominently from articles) is about the same at 0.5%
  • Wikipedia: is about 0.2%
  • Talk: is 0.1%
  • Help: is 0.05%
  • User: is 0.035%
  • User_talk: is 0.02%
  • Wikipedia_talk is about 0.005% (though even this small-sounding share is still ~13.5k views/day)
So Category: is reasonably well used by the standards of non-main namespace categories, but it's still pretty low throughput, and given the very large number of categories the averages are very low - about 21.5 hits/month, less than one per day.
A bit of poking around suggests there are some extremely active categories skewing the averages - the top is Category:Office_365 with ~350k hits and a strange pattern over time - May 2023 was actually on its downslope. Andrew Gray (talk) 19:37, 24 June 2023 (UTC)[reply]
And one last interesting number: lists are used 5-6x as much as categories. 2.8% of all traffic was to an article (or a redirect) with "list of" in the title. Portals are much less used - 0.04% of hits were in portal space, though the recent cleanup of portals has had a substantial effect there; it was almost twice as much in 2019. Andrew Gray (talk) 21:35, 24 June 2023 (UTC)[reply]
Great number work Andrew Gray. Very interesting also. The forum for Wikipedia guidance (WP talk) then can be said to be used by 1 in 50,000 editors. That is telling. Makes one feel sort of special I guess. Regards, Thinker78 (talk) 00:02, 27 June 2023 (UTC)[reply]
I can anecdotally say that I've always found categories to be the most useful tool to get a sense of "here's what Wikipedia has on this topic", even long before I was an editor. Thebiguglyalien (talk) 03:12, 24 June 2023 (UTC)[reply]
Categories, which can be very useful for browsing, do have very few views. But I think it is because people don't know about them or their use. One option to make them more visible is to have their own heading in articles, to let people know about them in the table of contents. I did this in John F. Kennedy, although I don't know if it's gonna stick or gonna be reverted. Also, it's unclear if the experiment will attract more views. I suspect it may. Regards, Thinker78 (talk) 07:37, 24 June 2023 (UTC)[reply]
Thinker78 This is an interesting idea. It's always bothered me a little that the navboxes and categories are technically placed in the bottom section by virtue of being at the end of the article. I wouldn't mind if this became the norm. I do expect someone to come along and remove it, but I'd be interested to see if it generates increased traffic. Thebiguglyalien (talk) 01:27, 25 June 2023 (UTC)[reply]
That is a very clever ideas Thinker78 Dronebogus (talk) 14:30, 25 June 2023 (UTC)[reply]
Lists and categories are very different and serve different purposes. Lists can contain detailed information and images whereas categories are simply a set of links. Therefore, lists should not be deprecated. Regards, Thinker78 (talk) 07:22, 24 June 2023 (UTC)[reply]
My anecdatum is that I don't personally find categories useful, since they represent only one piece of information and no other context. In desktop with navigation popups enabled they're all right, but on mobile they're just an alphabetised list of article titles with no other information. And if I'm already in desktop mode I'll probably just use a navigation template instead. That said, I don't object to there being multiple ways to index articles on related topics. Yes, List of etc articles don't auto update, but even outdated lists are more useful in my experience due to the additional context they're able to provide, as well as the ability to include non-article list items, whether they're section links or list items that fail N but pass NLIST. I would want a software change such that category view displays an article's short description following its title before I'd support removing the list articles. Folly Mox (talk) 20:06, 24 June 2023 (UTC)[reply]
To make manually curated lists without in-depth information even more redundant, one idea could be to have a toggle to display short descriptions of the articles on category pages. —Kusma (talk) 15:41, 25 June 2023 (UTC)[reply]
Because they are API-accessible, categories are used a fair bit by bots. Bots may explain some of the high use categories. Several of my bots navigate via categories. Whereas the lists are used by the humans. Hawkeye7 (discuss) 21:53, 26 June 2023 (UTC)[reply]
Can you provide examples of purely “navigational” lists that effectively duplicate categories? And you only want to deprecate such lists as opposed to all lists or navigational lists? Regards, Thinker78 (talk) 00:48, 27 June 2023 (UTC)[reply]
List of female superheroes was just kept. It duplicates Category:Female superheroes with minimal difference Dronebogus (talk) 01:34, 27 June 2023 (UTC)[reply]
The list had 8,000 views in May and the category had less than 100. Regards, Thinker78 (talk) 05:28, 27 June 2023 (UTC)[reply]
That’s because the category is largely a container for other categories. It has less than 50 entries but contains subcats with over 200. Dronebogus (talk) 19:35, 27 June 2023 (UTC)[reply]

I've never used categories to search and I'd have to research to even know how to use them. IMO newer search capabilities has made them obsolete. To use such a thing you need to do at least two things: 1. learn the system, architecture, data rules, and "how to use it" type stuff. 2. Be dependent / try to guess subjective decisions that the person making the classification made. This was fine when more modern methods were non-existent or weak, but that era has passed. Same for portals. Sincerely, North8000 (talk) 00:13, 24 June 2023 (UTC)[reply]

Categories have also this characteristic: it's like looking specifically for a book. You find the book among other books of maybe the same topic. But at the end of the book you find a list of other related books that might interest you that may have a different flavor than the search results. Consider categories and search different niches. Regards, Thinker78 (talk) 07:50, 24 June 2023 (UTC)[reply]
Phooey - to learn how to edit categories you might have to learn a little, to use them you just have to click. They are extremely useful for the things they are good for - I've no idea what "newer search capabilities" might mean - I'm a big fan of WP searches, but often they are a very blunt instrument. I hardly ever look at lists, and ones without commentary are generally useless and should be discouraged. Johnbod (talk) 02:40, 25 June 2023 (UTC)[reply]

Lists can be useful, as items which may not have enough for their own article, but do provide part of the story of the lists reason, and can then have a small synopsis. List of supermarkets can give a picture of the history of their development, including ones that have faded from history and have little available refs now for an article. Getting rid of lists and just making categories would lose this.Davidstewartharvey (talk) 16:24, 24 June 2023 (UTC)[reply]

It used to bother me that we had categories, and lists, and dab pages, and set indexes, and maybe a few other things. I still don't understand how a set index is different from a dab page, but I don't let it bother me any more :-) RoySmith (talk) 16:36, 24 June 2023 (UTC)[reply]
Oh, yeah, portals. How could I forget portals? RoySmith (talk) 16:37, 24 June 2023 (UTC)[reply]
What about those “Outline of…” articles? What’s the point of those? Dronebogus (talk) 00:35, 25 June 2023 (UTC)[reply]
Link? Regards, Thinker78 (talk) 01:51, 25 June 2023 (UTC)[reply]
Type "outline of" into a search box and see what you get. For example, Outline of academic disciplines or Outline of the Russo-Ukrainian War RoySmith (talk) 02:08, 25 June 2023 (UTC)[reply]
I didn't know about those. Regards, Thinker78 (talk) 02:58, 25 June 2023 (UTC)[reply]
@Thinker78 There's a surprisingly large number of these. A db query is showing 1353. RoySmith (talk) 14:44, 25 June 2023 (UTC)[reply]
I think the idea is that they are for top-down navigation of a subject area, something I never do. I would be happy to see all of these go. —Kusma (talk) 14:37, 25 June 2023 (UTC)[reply]
You mean outlines, or “all of the above”? Because we definitely should not purge all lists, categories, and dab pages (I honestly don’t know what a set index is). Dronebogus (talk) 14:40, 25 June 2023 (UTC)[reply]
As far as I can tell, a set index is something that looks exactly like a dab page except that if you edit it to make it comply with MOS:DAB, you get yelled at. RoySmith (talk) 14:47, 25 June 2023 (UTC)[reply]
Maybe we need to discuss getting rid of those… Dronebogus (talk) 14:48, 25 June 2023 (UTC)[reply]
I mean outlines. Lists and categories have their uses. Unlike navboxes on articles with more than two navboxes. —Kusma (talk) 15:33, 25 June 2023 (UTC)[reply]
Yes, I certainly wouldn't mourn the loss of all "outline of" pages, and I suspect most people wouldn't miss them at all. Apparently some people do look at them, though: Outline of ancient Greece averaged 23 views per day last year, which isn't much compared to Ancient Greece's 3520 views per day, but there are plenty of less-viewed articles! (I also wouldn't mourn the loss of portals, or the distinction between set indexes and dabs, while we are at it...) Caeciliusinhorto-public (talk) 11:14, 26 June 2023 (UTC)[reply]
I agree that portals are pretty much obsolete but didn’t want to suggest deleting them without view statistics. Dronebogus (talk) 18:34, 26 June 2023 (UTC)[reply]
I suspect you would find deleting portals to be an uphill battle. There's a lot of history. See WP:ENDPORTALS and WP:Arbitration/Requests/Case/Portals. I personally don't see much distinction between outline pages and portals; they're both human-curated guides to our coverage of a topic. But they both do seem to have their advocates, and I don't see how either is doing any harm, so meh. RoySmith (talk) 21:33, 26 June 2023 (UTC)[reply]
Portals, I can live with. They’re quaint and outdated, but I guess kinda serve as “the main page” for a given wikiproject to show off its work, so I get why people are attached to them. Outlines on the other hand just seem to exist to serve as yet another dust-collecting, poorly maintained internal link farm for users to (not) “navigate” with. Dronebogus (talk) 23:42, 26 June 2023 (UTC)[reply]
Someone did do a lot more work designing portals than categories though. Regards, Thinker78 (talk) 01:50, 25 June 2023 (UTC)[reply]
David: I don’t want to get rid of all lists, just lists that are simply collections of bare entries with no context Dronebogus (talk) 00:39, 25 June 2023 (UTC)[reply]
You have AfDs for that. Regards, Thinker78 (talk) 01:53, 25 June 2023 (UTC)[reply]
Which I have done, but failed in since “navigational lists” of bare links are as it is totally fine. Which brings us full circle. Dronebogus (talk) 14:31, 25 June 2023 (UTC)[reply]
Then that may just mean there is no consensus about doing away with the lists you want to get rid of. Regards, Thinker78 (talk) 00:49, 26 June 2023 (UTC)[reply]
That consensus is fine by current policy, but I started this discussion to see if consensus is against that policy itself. Dronebogus (talk) 18:36, 26 June 2023 (UTC)[reply]
What policy? Regards, Thinker78 (talk) 00:04, 27 June 2023 (UTC)[reply]
WP:NLIST + whatever people are talking about when they cite “navigational list” as a reason to keep something Dronebogus (talk) 00:08, 27 June 2023 (UTC)[reply]
  • It's categories that should be deprecated and rethought. They typically fail WP:V because they don't support citations. And their tree structure is quite arbitrary and dysfunctional, which results in constant confusion and dispute.
To provide a better generic search facility, categories should be replaced by a system of attributes. For example, for biographies you need a set of attributes such as nationality, sex, occupation, century and so forth. Then if you wanted a list of 19th-century, female, French flutists, you specify the desired attributes and a search tool would compile it. Wikidata is working along these lines and its flexible database structure is far better suited to the task than the category tree.
Pending better integration with Wikidata, I reckon that infoboxes would provide a good basis for a restructured facility. These provide a standard set of attributes for a class of articles and they have already been added to lots of articles. So, for example, if you wanted a list of battles with casualties greater than 100,000, say, infobox entries would be a reasonably systematic basis for generating it. Creating categories for such numeric thresholds would be unworkable.
Andrew🐉(talk) 12:30, 27 June 2023 (UTC)[reply]
Does anyone actually use Wikidata, even compared with categories? Dronebogus (talk) 19:26, 27 June 2023 (UTC)[reply]
Plus I think deprecating categories is fairly radical considering most if not all wikis use them as a fundamental backbone. Dronebogus (talk) 19:30, 27 June 2023 (UTC)[reply]
Yes, most wikis use them, but as a fundamental backbone? Without seeing evidence I rather doubt that. How many readers would notice if categories suddenly disappeared? Phil Bridger (talk) 20:31, 27 June 2023 (UTC)[reply]
Categories are not fundamental because they were added in 2004–5 after Wikipedia had been running for several years. They are just an alternative way of assisting navigation per WP:CLN and so could be removed completely without great difficulty. Andrew🐉(talk) 00:01, 28 June 2023 (UTC)[reply]
Though as mentioned that’s unlikely to go anywhere because people do, in fact, use them. Dronebogus (talk) 00:06, 28 June 2023 (UTC)[reply]
And killing categories would kneecap quite a few bots Dronebogus (talk) 19:32, 27 June 2023 (UTC)[reply]
Bots serve humans, not vice versa. Phil Bridger (talk) 20:31, 27 June 2023 (UTC)[reply]
It's certainly true that if we flipped a switch tomorrow and made all the categories go away suddenly, that would break a lot of stuff for no good reason. On the other hand, it's reasonable to say "Categories are deprecated. All new bots should use XXX instead, and existing bots should be migrated to use XXX by such-and-such a date". I'm not saying we should do that, but from the software engineering point of view, breaking changes are made all the time, and that's how you mitigate the carnage. RoySmith (talk) 21:28, 27 June 2023 (UTC)[reply]
I don't think categories should be deprecated because they serve a different niche. Browsing is a different action than searches. When you go to certain libraries, you can browse through books to see what interests you. Another thing is asking the librarian to search for certain topic and provide you the books. I did this in the Library of Congress regarding fairy tales expecting big books and the librarian handed me a couple of very small books. I was very disappointed. I like browsing and searching. Also, Google picks and chooses what it shows you when you search. I don't like that. Regards, Thinker78 (talk) 04:47, 28 June 2023 (UTC)[reply]
I don't understand the logic here. You say that you don't like that Google picks and chooses what it shows you, but how is that any different from a category? Somebody chose which articles to put in that category, and that's what you see. The same is true for all of the navigational tools we're discussing. When you go to a library and ask the librarian to bring you books on fairy tales, you're asking them to perform a curated search for you. The value they add is that they're familiar with the library's collection, and the tools for searching it, and also an added layer of human judgement about what you're probably looking for.
I also like browsing. Just walking up and down the stacks in a library or the aisles in a bookstore exposes me to all sorts of interesting material I might never find by doing a database search. But even then, I'm depending on the judgement of some human who decided how to shelve the books. RoySmith (talk) 14:12, 28 June 2023 (UTC)[reply]
True but you see literally the category instead of relying on the unknown parameters someone else used to conduct a search with your input terms. We don't know what code Google uses to find pages. But we know what a category says. Regards, Thinker78 (talk) 20:54, 28 June 2023 (UTC)[reply]

Okay, at this point I’m seeing a general consensus against deprecating navigational lists, which is all I was looking for. Deprecating set indexes, outlines, portals, and categories were all brought up but if someone wants to discuss those I’d recommend starting a new thread— though deprecating portals was brought up and rejected in the recent past and I highly doubt there would be a consensus to depreciate categories, which are still relatively well-used (roughly 0.5 of traffic, same as files and higher than most non-mainspace pages) even if it’s minuscule next to articles. Dronebogus (talk) 22:26, 27 June 2023 (UTC)[reply]

There is plenty of overlap between categories, list articles (including SIAs), outlines, portals, Wikidata and disambiguation pages. Each medium has its strengths and weaknesses. Ideally, we'd have one type of page which offered the best of all worlds, but we lack the technology for that and it's probably impossible even with unlimited resources. If one of those types is clearly inferior to another in every way then let's get rid of it, but I don't think that's the case. Categories can be hard to discover (at the bottom of the page near the licence terms no one reads, or worse still in a collapsed navbox beside the portal link) and sometimes hard to use due to size and unintuitive organisation into subcategories. They're for experienced and patient readers and editors rather than the casual visitor, but I think they still have a useful role. As a gnome, I use categories almost daily for finding problems to solve. Certes (talk) 23:30, 27 June 2023 (UTC)[reply]
I'm late to the party, but Certes has summed it up well; each of these mechanisms has its own strengths, and its own users. I would not be surprised to find that the vast majority of "real" readers arrive via a web search engine, bypassing categories and lists. Within Wikipedia, I suspect the only things that really matter are wiki-links (to reach related concepts) and dab-pages (when Google has failed to be specific). Technically, categories are better than lists because they're better curated (we have flocks of wikitaxonomists who dedicate their lives to fiddling about with categories, while curation of lists tends to be nothing more than the occasional skirmish between the dedicated enthusiasts of a particular list and a disgruntled deletionist wondering about the point of List of blue-green things shown on Tuesdays on Netflix, or the notability, sourcing and inclusion criteria for List of cars with sexy design features). But ultimately the problem is that most non-specialist readers neither know nor care that categories exist. I'd keep both them and lists, in hopes that someone, somewhere, finds it all useful. Elemimele (talk) 16:37, 29 June 2023 (UTC)[reply]
You kind of hit the nail on the head as to my frustration with lists. Nobody actually works on these things until someone nominates them for deletion and a bunch of inclusionists (I wouldn’t even say “enthusiasts of a particular list”) spring into action. Dronebogus (talk) 22:13, 29 June 2023 (UTC)[reply]

Automatic inflation adjustment?

There is a Wikipedia-style website (a personal blog) where currency values are automatically adjusted for inflation as time goes on.

Dollar amounts are written like [$10](2022-01-01), then in the future users can view the original (nominal) amount as well as the inflation-adjusted (real) amount for the current year.

(The pandoc module that the above website uses is open source here, no rights reserved).

This future-proofs articles and makes them more informative. Should Wikipedia adopt this? Chrett (talk) 19:10, 25 June 2023 (UTC)[reply]

@Chrett, we already have {{inflation}}, which implements this functionality in articles where authors think it appropriate. —Kusma (talk) 19:23, 25 June 2023 (UTC)[reply]

{{redirect}} and similar templates generate a hatnote atop an article or section, such as "Telegram" redirects here. Would it be helpful to include a link to that redirect, e.g. "Telegram" redirects here.? That might encourage editors to create an article on the subtopic, or at least to visit and categorise or otherwise improve the redirect. The top of the article already has a small link when arriving via that redirect, e.g. (Redirected from Telegram), but there are other ways to reach the target article, and the link is normally off the top of the screen when arriving at a section or other anchor. Certes (talk) 13:35, 26 June 2023 (UTC)[reply]

It seems to be formatted at Module:Redirect_hatnote#L-66. Curiously, the latest discussion at Template talk:Redirect actually talks of unneeded linking. --Joy (talk) 14:20, 26 June 2023 (UTC)[reply]
We don't usually want readers to click on such a link, so we should not include it other than the tiny one at the top. —Kusma (talk) 20:03, 26 June 2023 (UTC)[reply]
Thanks for the replies. I've set up local JavaScript to link the title for me. I find it helpful, but if others don't then let's not change things. Certes (talk) 22:06, 26 June 2023 (UTC)[reply]
It would be nice if you could specify a parameter such as link=yes for the section cases. --Joy (talk) 19:29, 27 June 2023 (UTC)[reply]

The Education Resource of Debate in Talk for Controversial Articles

There is sometimes almost emotional debate in the Talk sections of some articles. The Donald Trump article is a very good example. This could be an educational resource for education outreach programs at Wikipedia because it presents how ideas can be discussed with proper references in terms of what is said and how it said. The education resources are how a biography of a living person (BLP) is to be written on Wikipedia and a variety of other resources as well. Starlighsky (talk) 15:25, 26 June 2023 (UTC)[reply]

Wikipoints (suggestion)

I have an idea in which auto-confirmed users get points based of their contributions. When you look at edit history on articles or your contributions list, they always have that either red or green (+11) (-1) thing. What if we had like a points system (called Wikipoints) about that and you start off with the amount of edits you have? You can share your points on your user page (perhaps a userbox) or compete with other users if you like. You can always gain and lose some points by thanking someone on an edit (gain), or vandalize/sockpuppetry/any other thing frowned upon in Wikipedia (loss). A little bit like the automated Wikipediholism test. Just a fun little idea between users and its only between auto-confirmed users, and above, which would persuade others to join Wikipedia. 。 🎀 𝒫𝓊𝓇𝓅𝓁𝑒𝓁𝒶𝓋𝑒𝓃𝒹𝑒𝓇𝓂𝒾𝒹𝓃𝒾𝑔𝒽𝓉𝓈 𝟣𝟩 🎀 。 (talk) 18:20, 26 June 2023 (UTC)[reply]

Strong oppose. Doing something like this would make Wikipedia akin to a social network, which it isn't. The point system is going to get gamed very, very quickly. The additions and subtractions refer to how many bytes have been added or removed in the editor's revision, and serves as a quick-glance as to what the editor could have possibly done in their edit. —Tenryuu 🐲 ( 💬 • 📝 ) 21:52, 26 June 2023 (UTC)[reply]
hmm..... how many points do I get for a topical navbox? ok, how about a period navbox? this idea sounds like it might be interesting. however, I can't really see any actual or practical way for us to implement this, though. Sm8900 (talk) 22:10, 26 June 2023 (UTC)[reply]
Wow, hold your horses, this is the idea lab and AFAICT the OP isn't suggesting that the byte differences be directly converted to points. Some opt-in, non-competitive (and preferably externally hosted) gamification that rewards some bragging rights is not necessarily a bad idea for editor retention, though like Sm8900 I can't imagine a way that doesn't require so many caveats (not reflective of contribution quality, etc.) that it ceases to be rewarding. Nardog (talk) 22:20, 26 June 2023 (UTC)[reply]
I know the OP isn't saying that byte changes should be converted into a point system. The proposal for a point system is going to result in a lot of edits that try to garner as many points as possible, and I can already think of a few ways to exploit it depending on the rules set out, which has the unfortunate side effect of lowering encyclopedia quality. —Tenryuu 🐲 ( 💬 • 📝 ) 04:36, 27 June 2023 (UTC)[reply]
Oppose Ehhh, no. I think bold!opposing in idea lab is fine for very bad, totally unworkable ideas that should be nipped in the bud, and this is one of those. Assuming perfectly good faith of course, but Tenryuu is right. Dronebogus (talk) 23:50, 26 June 2023 (UTC)[reply]
How would the points work? Removing bad content will result in negative count in the edit history, but we should reward that, not penalize it. However, I will say that we don't want to gamify Wikipedia, we have enough issues with WP:GAMING and WP:EDITCOUNTITIS RudolfRed (talk) 00:27, 27 June 2023 (UTC)[reply]
Anything that incentivises quantity over quality leads inevitably to shoddy work. Folly Mox (talk) 01:15, 27 June 2023 (UTC)[reply]
As a fun little thing I see the appeal, but I also think this idea needs some more time in the oven before it's ready.
E.g. I'd kinda like a userbox that counts the number of times I've been thank'd. That seems neat. Loki (talk) 01:18, 27 June 2023 (UTC)[reply]
Worth noting that en.wiki already has a point system through the Wikipedia:WikiCup. This is voluntary, and points are checked rather than being automatic. Feel free to participate! CMD (talk) 05:15, 27 June 2023 (UTC)[reply]
  • Idea. ok, I have an idea. how about a set of whimsical cumulative point amounts, that can be awarded like Barnstars? such as " User ___ hereby awards you 10,000 points for helping people get along." maybe? thinking.... Sm8900 (talk) 06:34, 27 June 2023 (UTC)[reply]
I've made about three or four major navboxes, and no one has given me a barnstar or any recognition at all. so that seems like the other extreme from this idea. so this proposal seems like it might have a little bit of positive value. Sm8900 (talk) 06:36, 27 June 2023 (UTC)[reply]
ok it's fixed now.  Done. and by the way, i didn't mean to have the last word in this colloquy!! Sm8900 (talk) 13:14, 28 June 2023 (UTC)[reply]
I think this could be a good idea, but better if there are multiple (or unlimited) different ways of deriving a score. For example, I would like to have a better way of quantifying work on article improvement, or sometimes in particular my work on article improvement in particular categories or at a particular level of the topical hierarchy. Another editor might want ways to quantify their participation in policy debates or their work on template/module code. -- Visviva (talk) 19:35, 1 July 2023 (UTC)[reply]

Suggestion : New Home for Reddit readers

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.



Reddit editors are having issues with the Reddit editors, which are in turn called by google/

We should create a new wiki or a space within wikipedia that has similar features to reddit. The copyright content should not be owned to WMF as their charter allows for them to be sold, or data to be sold. Wakelamp d[@-@]b (talk) 09:00, 30 June 2023 (UTC)[reply]

If Reddit continues along its current path of pricing out useful API applications then a publicly run alternative will probably emerge, in the same way that Mastodon is replacing some uses of Twitter, but I'm not sure that Wikipedia (or the WMF) is the right organisation to organise it. Certes (talk) 09:19, 30 June 2023 (UTC)[reply]
Agree you can't create and grow communities through central planning, PR, or outreach ...
Maybe just offering server space with a wiki might be enough. The code was open sourced until 2017 )Reddit .We could just support Mastadon ID. Or give then banner time advertising them - most of the year we run stuff for WMF brand awareness. Wakelamp d[@-@]b (talk) 11:17, 30 June 2023 (UTC)[reply]
The servers used by Wikipedia and similar projects are owned by the WMF, so they'd have to be the ones supporting a Reddit clone. If budget for technical development suddenly appears, there's a long queue of MediaWiki enhancement requests I'd like to see fulfilled before expanding into new projects. Certes (talk) 11:28, 30 June 2023 (UTC)[reply]
Bothe Wikipedia and Wikimedia Foundation exist for a specific purpose (the provision of 'free knowledge'. loosely defined). Neither are intended to be providers of social media services, and it would be a highly-questionable use of funds to do so. AndyTheGrump (talk) 11:43, 30 June 2023 (UTC)[reply]
You may want to ask Jimbo about WT Social. I use neither Reddit nor WT Social but Jimbo might be interested in providing a home for former Redditors. —Kusma (talk) 12:54, 30 June 2023 (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.

Page blocks for editors subject to editing restrictions

I've been considering a proposal like this for a while, originally prompted by Lugnuts violating his topic ban on cosmetic edits by edit warring with an editor trying to correct lint errors. At the time the violations went without response, because the editor they were edit warring with was not aware of the restrictions and our current system of enforcement is based on editors who are aware of restrictions noticing them.

I consider this flawed, and to correct this I propose that any editor who is subject to an editing restriction is page blocked from WP:Editing restrictions, with a brief description of what their edit restrictions are. This will allow editors with the option "Strike out usernames that have been blocked" selected to see a dashed line underneath the editors name, and thus increase awareness of any restrictions and prevent violations like the one we saw with Lugnuts.

The exception would be editors who are only subject to interaction bans, as it is impossible to violate those restrictions without at least one editor who is aware of the restriction being present.

If there was a consensus for this then going forward it would be done every time a new topic ban is added to the list; retroactively, I would suggest only doing it for active editors, as doing it for inactive ones could result in them being reminded of their restrictions via an email notification which I would consider unnecessary and harsh. BilledMammal (talk) 05:22, 2 July 2023 (UTC)[reply]

Merging templates

Merging of Template Wikisource and WikisourceLang

We can have a third parameter in Wikisource template for entering the name of language. We don't need Wikisourcelang template as a third parameter to Wikisource template does the same.

Instead of writing

{{Wikisourcelang|hi|T}}

We can write

{{Wikisource|T||hi}}

And get same results

If third parameter not entered, it will automatically select English.

Prinaki (talk) 10:13, 2 July 2023 (UTC)[reply]

@Prinaki make a suggestion at Template talk:Wikisourcelang and Template talk:Wikisource. I can imagine one template using the other as a wrapper, to preserve backward compatibility ~ 🦝 Shushugah (he/him • talk) 19:07, 4 July 2023 (UTC)[reply]

AI add-on for illustration

The advent of image generation, such as with DALL-E 2 and Midjourney, has created an increasingly attractive opportunity for use in illustration. I would like to make (perhaps as a team) or see made a site plugin where a user is shown a generated image for the article that they are currently reading in a non-intrusive way, with the option to add the image to that article in one-click if it improves its understandability. Thoughts?    C M B J   01:50, 4 July 2023 (UTC)[reply]

Do you have examples of articles without images where understandability would be improved by an AI's artistic interpretation of a prompt relating to the article content? What's the copyright status of images created by these AI tools? I'm a little concerned about AI art proliferating outwards from here and misleading people in search results where it's not clearly attributed as AI art. Folly Mox (talk) 02:06, 4 July 2023 (UTC)[reply]
  • 1) I am thinking of all the fringe and bland-er low traffic core topics that we have across the project. Many of them are pretty straightforward conceptually from the opening paragraph.
  • 2) The copyright status is public domain for these images with all the major providers.
  • 3) Such an addon might automatically disclaim with a licensing template that it is AI generated.
  • 4) The quality of depiction is sufficient (on at least two services) to depict almost any non-technical topic at a level of comprehension and visual quality that far exceeds the ability of most artists, and I say this as someone who has professionally created graphics for profit. But a user could be prompted to ensure, and confirm as a human, that the image adequately and correctly represents a reading and interpretation of the article's content in a way that they understand.
Keep in mind that this could be an advanced feature that is enabled in a user's profile, not enabled by default. Most users who reach that point should recognize some level of content integrity.   C M B J   20:13, 5 July 2023 (UTC)[reply]
We've already established that AI -generated art is not appropriate on WP, outside of cases where it is being used to illustrate articles about the use of AI art. Too much of a copyright issue involved there. Masem (t) 02:35, 4 July 2023 (UTC)[reply]
The question is how do you determine if a picture is AI-generated or not. Anyone could claim a picture is "self-created" while it is not. ✠ SunDawn ✠ (contact) 04:08, 4 July 2023 (UTC)[reply]
I see the point. Loads of maths articles would be much more understandable if there were carefully-thought-out visual diagrams illustrating the underlying idea. But creating diagrams like that is really difficult. It requires a good understanding of the maths, and also a good understanding of human nature. There will be other examples; lots of signal-transduction pathways in biology are most easily understood if presented in graphical form. But at the moment, I'm utterly convinced that AI will get more wrong than it gets right. There is nothing wrong with someone experimenting with creating such images, but if we had a tool to create them and accept them in one-click, then I'm afraid we'll end up with a lot of enthusiastic one-clickers adding all sorts of nonsense diagrams. It's better not to encourage this, because those who are capable of creating a good AI-image, and capable of vetting it and understanding what tweaks their creation needs, will do the work anyway, without a tool. Those who need the tool will produce rubbish. Elemimele (talk) 09:11, 4 July 2023 (UTC)[reply]

Reliable source tracking on Talk pages

Checking to see if the reliability of a source has been discussed is a pain. While there are some publication titles that are easy to search the WP:RSN archives for, others are combinations of common words which leave you with a lot to go through. Additionally, many reliability discussions never reach that noticeboard; they are just carries out on the Talk page of whatever article people were trying to use that source on. Many things have a discussion or two, but not enough to end up on the [[WP:RSNP|Reliable Sources - Perennial] list.

Thing is, a lot of the sources (whether publications or self-published possible experts) have articles about them in Wikipedia, and thus have a Talk page as well. If there is a Talk:Jane's Guide to Scooby Doo Fanfic, might it be possible to include a template that says "The use of Jane's Guide to Scooby Doo Fanfic as a source on Wikipedia has been discussed at..." and then list links to discussions? Yes, it would have to be populated by hand, and yes, it's not what the central goal of the Talk page is for as it's not discussing the editing of the article about the source, but it seems like it would be handy in many cases. (I would think we'd avoid listing the results of the discussions, as they can be very contextual, so its better to look at the details.) -- Nat Gertler (talk) 14:45, 4 July 2023 (UTC)[reply]

There are definitely non-reliable sources, but reliability of a source must also be paired with the claim associated. That said, please support meta:WikiCite/Shared Citations which would provide an overview of commentary/usage of citations across different wikipedias/articles. ~ 🦝 Shushugah (he/him • talk) 19:03, 4 July 2023 (UTC)[reply]
That looks like a real good idea with a lot of implementation difficulties that is way far in the future. I liked one of the things they mention towards the top, fr.wiki's Reference: namespace. We could probably repurpose the Portal: namespace without anyone noticing. But something like assessment of reliability for borderline sources might be a little bit outside its scope, as they do need to be assessed in the context of the claim they're supporting.
There was someone at one of these VPs a few months ago, with a similar suggestion to link directly to RSN discussions of a source from its article. While we're waiting for a full solution, a talk page template doesn't seem like a bad idea. If this were treated as a WikiProject, overall source assessment could be wrapped in the talk page banner shell, but since the overall theme here is centralising information, it might still be good to have a separate projectspace subpage for individual sources that links all the relevant discussions, which also gives the option to support sources that have no Wikipedia article (which is the vast majority of them), and we could have a fully built citation template on the page for easy copypasta. Folly Mox (talk) 20:43, 4 July 2023 (UTC)[reply]
There are a couple of gadgets which highlight various types of sources, including those listed as deprecated or unreliable at RSP, such as User:SuperHamster/CiteUnseen and User:Headbomb/unreliable which may be of interest to anyone who isn't already aware of them Caeciliusinhorto-public (talk) 11:13, 5 July 2023 (UTC)[reply]

Rename Wikipedia namespace to Project namespace

I see many users, myself included get confused by the Wikipedia namespace, which contrary to the name, does not mean you're publishing on Wikipedia in the typical sense. I was looking at Wikidata, where their project level discussions are held at d:Wikidata, which made me wonder why don't we have a unified namespace for projects of all Wikimedia projects, e.g. P:Village Pump (idea lab), d:P:Village Pump (idea lab) would be me symmetric, and not repeating itself, because the url already contains prefix to specific Wikimedia project.

There are technical reasons/long conventions to keep existing namespaces, so this is an open starting conversation. WikiProjects are another confusing name, from Wikipedia namespace, but that"s for another idea thread. ~ 🦝 Shushugah (he/him • talk) 18:59, 4 July 2023 (UTC)[reply]

The namespace is already called Project, in the sense that Project:Example is a valid link to Wikipedia:Example, but we rarely use that prefix. Certes (talk) 20:23, 4 July 2023 (UTC)[reply]
This seems like a huge change for a relatively small reward, especially with the millions of links that currently point to the "Wikipedia:" namespace. But if I woke up one morning and Wikipedia: had been replaced by Project: across the board, I wouldn't mind. Thebiguglyalien (talk) 21:32, 4 July 2023 (UTC)[reply]
  • Support, unequivocally, as proposed. I would have proposed this myself long ago if I didn't think there would be a reactionary opposition. I would still keep core policies at Wikipedia: titles, but would move everything relating to support of article construction to a Project: namespace. BD2412 T 21:37, 4 July 2023 (UTC)[reply]
    We wouldn't need to move anything: it's already there. We would just need to refer to it as, for example, Project:VPT rather than Wikipedia:VPT (still a major change), and probably unset $wgMetaNamespace back to its default value. Oh, and add [ 'Wikipedia' => NS_PROJECT ] to $wgNamespaceAliases, if it's not already there, and repeat for the talk namespace. Certes (talk) 22:34, 4 July 2023 (UTC)[reply]
  • Oppose: I think it's just too late for such a major change. Wikipedia's over 20 years old; it's a major change to a lot of links. Would it have been better had it been that? Perhaps. But I'm not sure that "Project" is even all that much clearer. Adam Cuerden (talk)Has about 8.5% of all FPs. 21:54, 4 July 2023 (UTC)[reply]
    When an article is draft namespace and you want to publish it, the Wikipedia namespace seems right and editors say to publish on Wikipedia or main space by which they mean article space, yet they don’t mean it that way and so on. I was pleasantly surprised to learn Project alias already exists though. ~ 🦝 Shushugah (he/him • talk) 22:54, 4 July 2023 (UTC)[reply]
    The very first namespace available about where you would publish your article is literally labeled (Article). If somehow that is still confusing, more help text could be added in MediaWiki:movepage-summary. — xaosflux Talk 02:47, 5 July 2023 (UTC)[reply]
  • This seems problematic - to start with, Shushugah what are you trying to say about Wikidata? Their "project" namespace is called "wikidata" (e.g. see d:Wikidata:Administrators' noticeboard), our project namespace is called "wikipedia". In both cases these are namespaces that house things related to what they are called - "Template" houses templates, "wikipedia" houses meta-things about Wikipedia, etc. — xaosflux Talk 02:44, 5 July 2023 (UTC)[reply]
    The Template, File namespaces make sense, but stuff like Draft or Wikipedia are rather confusing, and on top of it, Article namespace, does NOT have an article prefix, so confusingly when someones tries to find the right namespace to publish on, Wikipedia seemingly appears to be the right one. ~ 🦝 Shushugah (he/him • talk) 07:49, 5 July 2023 (UTC)[reply]
    I think article mainspace lacking any prefix is the most natural approach, matching the URL structure of typical web sites. Given that people generally will first experience Wikipedia by reading an article, they will have exposure to this URL format beforehand. "Draft:" seems intuitive to me. isaacl (talk) 16:08, 5 July 2023 (UTC)[reply]
  • Oppose solution in search of a problem. Headbomb {t · c · p · b} 17:37, 5 July 2023 (UTC)[reply]
  • My comment, since this is the idea lab: If it ain't broke, don't fix it. I don't see a sufficient reason to make the change, and I don't think that there's a way to workshop this to make the proposal any different in a way that would improve acceptability (it's a binary choice). — Red-tailed hawk (nest) 17:47, 5 July 2023 (UTC)[reply]
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy